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.
