'Heartbleed': el nombre del fallo de seguridad más impresionante en la historia de Internet

Un gravísimo error que afecta a los servidores más seguros de internet, del que se puede haber extraído toda la información y que nadie garantiza que no se hayan aprovechado del mismo.

Será indispensable cambiar las contraseñas, al menos las más importantes que no tengan verificación en dos pasos.

Artículo de RTVE:

"Administradores de redes de todo el mundo llevan unos días incómodamente ajetreados tras haberse hecho pública una vulnerabilidad que afecta a cientos de miles de servidores de Internet y que -tal vez un poco irónicamente- pone en peligro todos los datos almacenados en los servidores web 'seguros'.

Tan grave es la situación, que en diversas publicaciones técnicas se ha calificado de devastador, catastrófico e incluso -como si fuera una especie de "Apocalipsis digital"- con un 11 sobre 10 en una hipotética escala de gravedad. Y cuando esto lo dice Bruce Schneier, uno de los más reputados expertos en seguridad y criptografía de la era Internet es que el asunto no es precisamente baladí.

Hay servicios que incluso jocosamente se plantean pedir a la gente que se tome un día libre a título individual, bajo el lema "podría ser un buen día para cambiar todas tus contraseñas".

Según Netcraft, la empresa especializada en análisis de servidores a nivel mundial, el cálculo es que hay un millón de sitios web vulnerables, algo que confirma la ICANN, una de las organizaciones que vela por el desarrollo de Internet.

El bug en cuestión se llama Heartbleed y ya cuenta hasta con un dominio y una sección informativa especial creada por la empresa de seguridad Codenomicon para difundir su estado, soluciones y resolver preguntas al respecto.

Gigantes como Google, Yahoo, Amazon o Akamai han procedido a arreglar sus servidores; sitios populares como GitHub también han tomado medidas; gigantescos proveedores de hosting como MediaTemple han informado a sus clientes de la situación respecto a los servidores.

¿Qué es el bug Heartbleed exactamente?

Es difícil de explicar sin algunos tecnicismos, así que lo que hay a continuación es una versión simplificada más fácil de entender.

Su nombre real es poco sugerente: CVE-2014-0160, un número de catálogo. El apodo de Heartbleed ('el corazón que se desangra') hace referencia a que el fallo en cuestión es una filtración de datos inesperada -cual desangramiento- en el corazón de un servidor de Internet, las máquinas a las que nos conectamos mientras navegamos.

Fue descubierto hace poco por Neel Mehta del departamento de seguridad de Google, quien -como hacker bueno y tal y como se recomienda en estos casos- avisó a los responsables para que prepararan una solución antes de darlo a conocer al público en general.

El problema en cuestión es un bug, un comportamiento imprevisto debido a un error en el código. ¿En qué parte del código exactamente? En una zona o librería llamada OpenSSL presente en algunos servidores web que es la que se encarga de las comunicaciones confidenciales y seguras, el famoso "candadito" que puede verse en la barra de navegación y que se activa cuando se visitan tiendas, bancos o redes sociales.
OpenSSL también sirve para garantizar (mediante algo llamado "certificado") que cada web es quien dice ser y otras cuestiones importantes, especialmente para los negocios en la red. Y otro detalle importante es que aunque no todos los servidores de Internet utilizan OpenSSL -pues existe software alternativo- se han cifrado en cientos de miles de servidores los afectados, entre ellos muchos de los más populares.

El bug en cuestión se produce debido a cómo se gestiona algo llamado 'extensión Heartbeat', una especie de señal en forma de 'latido' que se emplea para sincronizar procesos, servidores y asegurarse de que todo funciona correctamente.

Aprovechando el fallo alguien puede hacer una especie de 'llamada desde el exterior al servidor' como si solicitara algo parecido a una página y extraer 64 KB de contenidos de la memoria de esa máquina en la que está funcionando OpenSSL. Esto -normalmente no permitido por las aplicaciones ni el sistema operativo- es la clave del grave problema.

Los efectos de este 'desangramiento de la memoria' son varios. Por un lado, no se refiere solo a la información sobre la navegación web, sino también a todo lo que está almacenado en la memoria ese servidor que usa OpenSSL: correos, mensajería, datos sobre cuentas...

Para mayor desgracia también incluye los certificados de seguridad y las llamadas 'claves maestras' que permitirían a quien las poseyera acceder (o quizá suplantar) al servidor más fácilmente, aunque según afirman otros expertos no sería tan trivial como hacerse con una contraseña cualquiera.

Además no es fácil -si acaso es posible- asegurar que alguien haya accedido a esos datos, porque no queda constancia. Peor escenario es difícil imaginar para el responsable de la seguridad de un servidor.

¿Casual o intencionado?

Debido a que OpenSLL es 'abierto', el código de su programación es público y lo mantienen voluntarios y expertos de todas partes del mundo. Muchos de ellos proceden de compañías especializadas en seguridad que utilizan las ideas del software libre y una de sus grandes ventajas a este respecto: que como cualquiera puede examinar el código del software puede comprobar también si hay algún fallo.

Si lo hay, se arregla y se lanza una nueva versión. Si no lo hay, todos contentos usando esa versión.

Pero la mala suerte (o no: ver más adelante) ha querido que suceda el efecto más temido: que uno de los desarrolladores introdujera un fallo grave y nadie se diera cuenta. De modo que el código ha permanecido casi dos años tal cual, utilizándose en servidores de todo el mundo, con la "puerta abierta hasta la cocina" como suele decirse.

El fallo parece a todas luces un error sin intención -y de hecho una especie de 'investigación informal' sobre el autor que subió a la web de desarrollo el código con el bug no ha revelado nada demasiado extraño que haga pensar en rebuscadas conspiraciones.

Pero hay quien no cree en las casualidades y tampoco ayuda que a hoy en día se sepa gracias al caso Snowden que la NSA entre otras agencias gubernamentales de diversos países han colaborado o introducido a sabiendas código espía en software de todo tipo, lo que se llaman 'puertas traseras' para obtener acceso a 'información delicada' sin que nadie se de cuenta.

Así que quienes temen esta teoría sugieren que el Heartbleed pudo haber sido insertado en su día con esa misma intención. Esto significaría que alguien habría tenido la posibilidad de rastrear -durante unos dos años- una parte relevante de la Web, la zona más íntima, confidencial y supuestamente segura de los servidores de la Web, copiando todo lo que encontraba a su paso sin que nadie siquiera detectara lo que estaba sucediendo.

¿Qué deben hacer los usuarios?

El problema, por desgracia, no es algo que puedan resolver los usuarios a nivel personal. Son los administradores de sistemas de las empresas, especialmente los de los servicios de alojamientos de webs, quienes deben actualizar los sistemas para parchear el bug y eliminar el problema en el futuro.

De hecho, hay cierto debate sobre si el hecho de que si en un servidor web se haya aplicado ya el parche se pueda considerar seguro o no.

El porqué es sencillo: el verdadero problema viene del pasado. Aunque hoy se solucione con un simple parche –algo que están haciendo todos los implicados tan rápido como pueden– las versiones de OpenSSL afectadas llevan casi dos años usándose. Así que quizá en otro momento el servidor web era vulnerable y aunque ahora ya no esté desprotegido la información ya fuera "robada˝.

Es difícil afirmar cuánta gente conocía este bug y quién se puede haber aprovechado de ello, especialmente desde que se ha hecho público – y para colmo hay servidores que no se han actualizado todavía. Cualquier persona con un poco de experiencia recomendaría ponerse en el "peor caso" y suponer que los datos que se podían robar fácilmente desde hace unos pocos días –cuando no años– deberían considerarse como efectivamente robados. Esto incluiría todo tipo de contenidos de esos servidores: cuentas, contraseñas, certificados seguros, datos bancarios y mensajes personales de correo y mensajería instantánea.

Lo mejor que puede hacer un usuario final es mejorar su seguridad actual:

• Cambiar todas las contraseñas personales cuanto antes.
• No usar nunca la misma contraseña en dos sitios/servicios distintos.
• Comprobar en Heartbleed Test si un servidor web propio (si acaso tenemos una web de empresa o personal) es seguro. Si aparece como 'no seguro', avisar a quien lo administre técnicamente para que lo arregle.
• Pedir a los administradores de la red y de informática que consideran qué puede haber sucedido con los certificados digitales que se están utilizando a nivel corporativo y personal y valorar seriamente renovarlos/cambiarlos si fuera necesario.
• Comprobar los avisos de accesos no autorizados a las diversas cuentas. Facebook por ejemplo avisa si alguien accede desde un dispositivo nuevo no conocido; las tiendas y sitios de donaciones guardan una lista de las descargas, pagos y compras de material digital.
• Activar la verificación en dos pasos en los sitios que lo permitan — por ejemplo Google, Microsoft, Yahoo, Twitter y otros.
• Revisar las cuentas del banco en busca de 'transacciones extrañas' – sería una señal de que podrían estar produciéndose abusos usando las contraseñas originales.

La historia del Heartbleed dará probablemente que hablar mucho todavía: y es que no todos los días aparece un fallo que bata el récord de despropósitos dejando vulnerables tantos servidores de Internet.

Con un poco de suerte, todo el fallo no estará tan extendido como se ha pensado en un primer momento, habrá surgido de forma no intencionada y todo acabará tras unas cuantas semanas de actualizaciones de software, cambios de contraseñas personales y bastantes horas de consultoría informática para revisar y arreglar el desaguisado. Y a cruzar los dedos para que no se repita."