“Heartbleed” miles de usuarios expuestos en este fallo.

“Catastrófico es la palabra correcta. En una escala del 1 al 10, esto merece un 11”, declaró Bruce Schneier, blogger especializado en seguridad.

Hace un par de horas se ha descubierto una vulnerabilidad que tiene por nombre Heartbleed, este virus afecta a un tecnología muy usada para la encriptación en las páginas web, ha permitido que datos de muchas páginas de internet mundiales importantes quedaran vulnerables al robo por parte de hackers.

Heartbleed fue descubierto gracias a parte de investigadores de google y la pequeña firma de seguridad Codenomicion, se informó al Departamento de Seguridad del Gobierno de Estados Unidos para informar a las empresas el martes que revisaran sus servidores para comprobar si estaban usando versiones vulnerables de un software conocido como OpenSSL.

¿Cuál es el problema?

El fallo está en una función que se encarga de gestionar mensajes Heartbeat. Estos mensajes son llamados keep-alive: es una forma de decirle al servidor que sigues conectado y que no cierre la conexión. El mensaje que mandes puede tener una carga o contenidos (payload), como pueda ser la fecha en la que se ha enviado. El servidor recibe ese mensaje y responde al cliente con esa misma carga. Este tipo de esquema “te paso algo y me respondes con lo mismo” no es exclusivo de TLS: en los paquetes de ping, por ejemplo, también se pueden incluir datos para así calcular cuánto tarda el servidor en responder.

 El cliente tiene que decir también qué longitud tiene esa carga, para que el servidor la pueda leer sin tener que adivinar dónde acaba. Y aquí es donde vienen los problemas. ¿Qué pasa si le digo al servidor que le estoy enviando mil bytes y en realidad sólo le estoy enviando uno?

Si habéis programado alguna vez en lenguajes de alto nivel, como Java, C# o JavaScript, pensaréis que eso fallará. Al fin y al cabo, estamos intentando acceder a cosas que no están ahí. Si mi paquete es una lista de bytes de longitud 10 y quiero leer el 20978, no tengo de dónde sacarlo y el programa debería pararse y reportar un fallo.

Pero OpenSSL está escrito en C, y en C las cosas no son tan felices. En este lenguaje, la variable “paquete” no es más que una dirección en la memoria RAM; por ejemplo, la 1076. El primer byte del paquete está en la posición 1076, el segundo en la 1077, el tercero en la 1078 y así sucesivamente.

Cuando se esté ejecutando un ataque, OpenSSL recibe un mensaje de longitud 10 (por ejemplo), que dice que tiene 200 bytes de carga y que almacena en la posición 1076. Cuando tenga que responder, empezará a copiar el byte 1076, el 1077, el 1078… así hasta el 1086. ¿Qué ocurre después? Fácil: OpenSSL sigue. A él le han dicho que hay 200 bytes (el código no verifica si la longitud que aparece en el paquete es incorrecta) y va a copiar sus 200 bytes. Es decir, seguirá leyendo y copiando hasta que llegue a la posición 1276.

¿Y qué hay en esas posiciones? Pues sorpresas. La reserva de memoria no es determinista así que puede haber absolutamente de todo. Quizás sólo hay basura, restos del paquete anterior – así es como se comprueba si un servidor es vulnerable – o la clave privada del servidor.

Repitiendo muchas veces el ataque – cada vez se pueden recuperar hasta 64 KB de la memoria del servidor – es probable que se acaben encontrando cosas de valor. Además, las estructuras más valiosas, como las claves privadas que comentábamos, son relativamente fáciles de encontrar cuando están guardadas en memoria. En resumen, es un fallo muy grave, una ventana abierta a los entresijos confidenciales de OpenSSL.

¿Cómo solucionar este problema?

Como ya sabemos cuál es el problema es fácil solucionarlo, pero el verdadero problema es que esta falla ya tiene alrededor de 2 años y no sabemos si durante este tiempo alguien estuvo sacando frutos de este problema, por el momento todo lo que nos queda es verificar si tus servidores presentan el problema y solucionarlo.  

La corrección en OpenSSL ya está lista, y varias distribuciones de Linux tienen los paquetes listos para actualizar. La versión con el fallo corregido es OpenSSL 1.0.1g. Las versiones vulnerables van desde la 1.0.1 hasta la 1.0.1f (versiones anteriores no tenían Heartbeat implementado).

Algunos sitios importantes afectados, Amazon, Heroku y Yahoo.  Un portavoz de Yahoo confirmó que el correo de Yahoo era vulnerable a un ataque, pero dijo que había sido emparchado junto con otros sitios principales de Yahoo, como los de Búsqueda, Finanzas, Deportes, Flickr y Tumblr.

Puedes probar si tus servidores son vulnerables con un simple test ; http://filippo.io/Heartbleed/

Fuentes: www.elfinanciero.com , www.genbeta.com , www.bbc.com