El pasado lunes 7 de Abril salió a la luz una gravísima vulnerabilidad en una librería SSL, hasta ahora desconocida, que permitiría a un atacante acceder a información sensible en los servidores vulnerables.
El fallo se encontraba en la función encargada de gestionar los mensajes heartbeat de la librería OpenSSL, ampliamente utilizada por los desarrolladores para implementar SSL/TLS en servicios de correo, chat, VPN, etc.
¿Dónde estaba el fallo?
Como mencionamos al inicio de este post, el fallo se encontraba en una función encargada de gestionar los mensajes heartbeat. Estos mensajes son los denominados keep-alive; que se utilizan para informar al servidor de que seguimos 'vivos' para que no cierre la conexión.
La vulnerabilidad se encontraba en una función encargada de gestionar los paquetes heartbeat
Dichos paquetes pueden o no contener información, como por ejemplo la fecha y hora del envío. Esta información puede ser útil para medir la latencia de la conexión ya que el servidor devolverá la misma información que recibió. Como es habitual, en la cabecera del paquete se informa al receptor del tamaño del mismo, de modo que éste conozca cuándo acaba la recepción.
Veámoslo con un ejemplo de funcionamiento: El usuario envía un paquete keep-alive al servidor con 5 Bytes de datos. Por lo tanto, construye un paquete cuyo campo "longitud" es igual a 5 y lo envía. Cuando el servidor lo recibe, almacena los datos de la cabecera y los datos en memoria. Cuando lo va a devolver monta la cabecera, se posiciona en el lugar de memoria donde están los datos, recupera 5 Bytes y envía el paquete.
Pero ¿qué pasa si le mentimos?, ¿qué pasa si decimos que tiene un tamaño que no es el correcto?.
El usuario envía un paquete keep-alive modificado al servidor con 5 Bytes de datos, pero en esta ocasión le diremos que la longitud es 1000 Bytes. El usuario construye el paquete igual que antes utilizando el campo longitud falseado. El servidor lo recibe, almacena los datos de la cabecera y los datos en memoria. Cuando lo va a devolver monta la cabecera, se posiciona en el lugar de la memoria donde están los datos, recupera 1000 Bytes y envía el paquete.
Como habréis podido ver, se ha devuelto más información de la que se envió. Esto es debido a que no existía ningún mecanismo de comprobación, de modo que la librería leería el campo longitud y enviaría al emisor los 1000 Bytes siguientes a la cabecera. En los lenguajes de programación de alto nivel se devolvería un error dado que el proceso intenta acceder a información que no le corresponde, pero en lenguaje C esto no sucede.
Dado que la reserva dinámica de memoria es prácticamente aleatoria, no se conoce qué datos están a continuación, pero podríamos encontrar desde datos sin sentido hasta la propia clave privada del servidor, pasando por usuarios y contraseñas de los usuarios que estuvieran en ese momento accediendo al servidor.
@yahoo your login servers are vulnerable for the OpenSSL #heartbleed attack, exposing usernames and plain passwords pic.twitter.com/v8kddiP0Yo
— Mark Loman (@markloman) abril 8, 2014Qué lo hace más grave, aún si cabe, que este ataque es indetectable ya que en teoría solo estamos manteniendo la conexión activa.
¿Qué podemos hacer los usuarios?
Realmente nada, el trabajo recae sobre los administradores de los servidores, que han trabajado estos últimos días a marchas forzadas para solucionar el problema lo antes posible y rezar para que nadie conociera el fallo antes de ser reportado.
Los grandes de Internet fueron informados de la existencia del fallo con una semana de antelación a la publicación del mismo para que tuvieran tiempo para corregirlo, aunque no se lo tomaran muy en serio; como el caso de Yahoo, que fue vulnerable durante horas después de hacerse público, como hemos podido ver en el tweet anterior. Por este motivo sería interesante cambiar las contraseñas de nuestras cuentas, sobre todo si hemos accedido durante la última semana.
Actualmente, la mayoría de sitios ya han actualizado sus sistemas, aunque todavía quedan algunos vulnerables.
¿Cómo sé si un servicio está comprometido?
Para comprobar si un servidor está comprometido, para saberlo han habilitado un sitio web que realiza una serie de pruebas para saber si el servidor introducido es vulnerable.
En Genbeta | Heartbleed, otro fallo extremadamente grave en una librería SSL
