HeartBleed, una explicación y su solución

Publicado por Diego Córdoba en

Muchos ya estarán enterados de esta gran falla de seguridad en OpenSSL, cuyo nombre común es «HeartBleed«.

Hoy ya se encuentra corregida dicha vulnerabilidad en el software, y por parte de los desarrolladores del proyecto, pero esta falla puede seguir teniendo repercusiones negativas (más de las que ya tuvo) en la medida en que los administradores de sistemas no actualicen sus servicios de seguridad.

Cómo nos enteramos de HeartBleed?heartbleed

Muchos de nosotros nos dimos cuenta de esta vulnerabilidad al estar en contacto con feeds, mailing-lists y redes sociales cuya temática es la seguridad y el hacking ético.

A muchos también nos llegó a nuestras casillas de correo un mail cuyo contenido informaba la falla, y nos remitía a sitios oficiales sobre su explicación técnica, lo cual también nos dio una idea de la magnitud de la gravedad.

Algunos datos técnicos sobre OpenSSL

Heartbleed es un juego de palabras que traducido al castellano sería algo similar a «corazón desangrado«. Es un juego de palabras que hace referencia a la funcionalidad Heartbeat de TLS, cuyo objetivo es refrescar sesiones de SSL/TLS sin necesidad de re-negociar los datos de cifrado y autenticación.

SSL/TLS se utiliza para muchas comunicaciones seguras dentro de Internet. Es una capa de seguridad añadida al stack de protocolos TCP/IP justo debajo de la capa de Aplicación, lo que permite que varias aplicaciones que originalmente enviaban datos en texto plano, ahora pudieran hacerlo de manera cifrada, y autenticada mediante criptografía asimétrica y certificados digitales x509.

Básicamente, https o smtps, o pops, o ftps, son todos protocolos de aplicación que hacen uso de SSL/TLS, y que fueron afectados por esta vulnerabilidad.

Los algoritmos asimétricos que usan estas impelentaciones les permiten autenticarse, o validar su identidad, contra otros nodos de la red. Esta autenticación se basa en que cada nodo disponga de una clave privada que no debe ser comprometida, ya que quien tenga la clave privada de un nodo, podrá «hacerse pasar» por él en cualquier transacción segura.

Datos técnicos de la vulnerabilidad

Una de las funciones escritas en el código fuente de OpenSSL, la función dtls1_process_heartbeat(), cuya definición se encuentra en el archivo fuente ssl/di_both.c del raíz de Openssl, no valida correctamente la longitud de la estructura que administra el registro de conexión de SSL, llamada ssl3_record_st.

Cuando un cliente realiza una solicitud de algún valor, también setea la longitud de la respuesta que espera recibir.

Openssl reserva memoria dinámica para armar la respuesta al cliente, y esa cantidad de memoria se toma de la solicitud efectuada por el cliente, para poder almacenar en ella el dato a entregar.

Si bien esta reserva de memoria puede contener hasta 65535 bytes (64KiB), al ser reservada por el cliente, y el ssl copiar los datos a la respuesta mediante la función memcpy(), no valida el ancho del dato real a entregar.

Esto le da la posibilidad a un cliente de solicitar una cadena corta de información, de pocos bytes, o incluso, de ninguno en una cadena nula, y pedir 64 KiB de información para almacenarlos. Al llevar a cabo esta solicitud, la función dtls1_process_heartbeat() copia 64 KiB de información de la memoria en la respuesta al cliente.

Estos 64 KiB de datos corresponden con información contigua en memoria de la aplicación, que pueden contener datos sensibles, como información de claves privadas de servidores y clientes.

Los atacantes que tuvieron éxito lograron realizar consultas sucesivas al proceso renegociando la conexión, y obtener de esta forma diferentes bloques de datos de la memoria, lo que les permitió obtener las claves privadas de servidores y clientes.

Una buena explicación gráfica podemos encontrarla en esta imagen obtenida de http://xkcd.com/1354 heartbleed_explanation

Tiempo de soluciones…

La vulnerabilidad se encuentra resuelta en versiones de OpenSSL posteriores a la 1.0.1g del 7/abril/2014.

Esto nos dice que si disponemos de servidores que utilicen estas bibiliotecas (la mayoría), es más que recomendable actualizar la versión del openssl por medio del gestor de paquetes y actualizaciones de la distribución (apt-get, aptitude, yum, pacman, …) y asegurarnos de que la versión es la que corresponde.

Aquí un ejemplo de actualización en Debian testing «Jessie»:

La versión actual del openssl es:

Luego de actualizar utilizando:

Obtenemos la siguiente salida:

En donde podemos ver que se trata de la versión de openssl 1.0.1g del 7/abril, la versión corregida.

Y… por supuesto, si consideramos que nuestras claves privadas fueron comprometidas, sería más que recomendable regenerarlas 🙂

¡Espero que les haya resultado interesante!

Algunos links interesantes

Podemos encontrar información de primera mano sobre la vulnerabilidad visitando el sitio creado para tal fin:
http://heartbleed.com/

También disponemos de una discusión técnica sobre heartbleed aquí:
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

O el commit de la línea de desarrollo de la versión corregida:
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3

Y por supuesto, el sitio de vanguardia de newsletters de seguridad, Hispasec:
http://unaaldia.hispasec.com/2014/04/openssl-afectada-por-una-vulnerabilidad.html


Diego Córdoba

- Ingeniero en Informática - Mg. Teleinformática - Tesis pendiente - Docente universitario - Investigador