Ya todos conocen la afamada vulnerabilidad que dieron a conocer como Heartbleed. Afortunadamente, tuve la suerte de poder brindar una pequeña charla en el OWASP Latam Tour 2014, en su capítulo de Argentina (Buenos Aires), sobre esta interesante vulnerabilidad.
Preparando esta charla, pude indagar un poco más profundo sobre la naturaleza de Heartbleed y dónde radicaba la falla. Esta vulnerabilidad fue descrita en detalle en muchos otros medios, por lo que intentaré darle un enfoque técnico pero distinto, además de contar algunas curiosidades durante el camino de la pequeña investigación.
El exploit que surgió al poco tiempo de publicada la vulnerabilidad tuvo gran repercusión. Es por eso que creo que vale la pena explicarlo un poco más en detalle con el fin de poder comprender mejor su funcionamiento.
En primera instancia, el protocolo de HeartBeat es utilizado principalmente para prolongar la vida de una sesión HTTPS. Esta funcionalidad permite comprobar que el servidor está vivo y como parte de su funcionalidad, devuelve el payload que envió el cliente durante la petición.
La estructura de Heartbeat según el RFC 6520 puede observarse en la siguiente imagen:
El primer campo corresponde al tipo del mensaje. Existen dos tipos válidos, request (1) y response (2). El segundo campo corresponde al tamaño del payload, y el tipo es un entero no signado de 16 bits. De allí se deduce que el máximo valor en memoria que se puede obtener es de 64 kb o 2^64.
El tercer registro corresponde al propio payload. Este mismo payload es el que vuelve como parte de la respuesta. Finalmente, el cuarto registro corresponde al padding, que son bytes que se utilizan a modo de relleno y son ignorados por el servidor.
El exploit no hace más que aprovechar el diseño de esta funcionalidad. Básicamente, envía una petición con un payload muy corto pero indicando un tamaño muy largo en el campo length. Y es aquí donde radica la falla. El servidor no calcula el tamaño del payload enviado por el cliente, y de alguna manera "confía" en el tamaño que se le indica. De esta forma, retorna el propio payload más el contenido correspondiente al tamaño indicado por el cliente.
En ese espacio de memoria puede encontrase información en texto plano, cómo por ejemplo, cookies de sesión o credenciales, entre otras alternativas.
Existen varias versiones vulnerables de a Heartbleed que se encuentran muy bien detalladas en el propio sitio de Heartbleed Bug.
Análisis
Preparando la charla, comencé a indagar un poco más profundo sobre aquellos servidores con versiones vulnerables. Realmente se encontraron cosas muy interesantes. Por ejemplo, utilizando Shodan, se pueden listar servidores indexados con distintas versiones de openssl.
En el ejemplo anterior, puede observarse que existen más de 100.000 servidores con la versión 1.0.1e. En otras palabras, una gran cantidad de servidores vulnerables a Heartbleed y solo sobre una de las versiones. Sobre la derecha de la imagen, se aplicó un filtro a aquellos servidores indexados que se encuentran en Argentina.
Asimismo, también se encontraron cosas interesantes en la memoria de algunos servidores vulnerables. Específicamente, existían rastros de exploits que habían sido lanzados sobre los propios servidores. Incluso algunos de estos exploits intentaron infectar al servidor para que formara parte de una botnet.
Si bien el pico de atención sobre esta vulnerabilidad ya ha pasado, aún existe un gran número de servidores vulnerables. Esto mismo puede demostrarse a través de una simple búsqueda por Internet. Asimismo, es importante que se realicen revisiones sobre todos aquellos servidores que utilizan este protocolo para así evitar una posible fuga de información tal como se ha visto sobre sitios de gran reputación e importancia.
No hay comentarios.:
Publicar un comentario