Una de las vulnerabilidades más conocidas de mediados de 2010 se llamó "Heartbleed". Heartbleed fue particularmente grave porque el software que afectaba a “OpenSSL”, la principal biblioteca criptográfica para conexiones HTTPS, que son muy utilizadas. Para empeorar las cosas, la vulnerabilidad había estado presente en OpenSSL durante más de dos años antes. fue descubierto, publicitado y parcheado, lo que significaba que mucha gente estaba usando un sistema vulnerable versión.
Heartbleed era una vulnerabilidad de fuga de datos en la extensión de latido que, cuando se explotaba, filtraba datos de la RAM del servidor al cliente. La extensión de latido se utiliza para mantener una conexión entre el servidor web y el cliente sin realizar una solicitud de página normal.
En el caso de OpenSSL, el cliente envía un mensaje al servidor e informa al servidor de la longitud del mensaje, hasta 64KB. Se supone que el servidor debe repetir el mismo mensaje. Sin embargo, lo que es más importante, el servidor en realidad no verificó que el mensaje fuera tan largo como el cliente afirmó que era. Esto significaba que un cliente podía enviar un mensaje de 10 KB, afirmar que era de 64 KB y obtener una respuesta de 64 KB, y los 54 KB adicionales se componían de los siguientes 54 KB de RAM, sin importar qué datos estuvieran almacenados allí. Este proceso está bien visualizado por el
Imagen cortesía de xkcd.com.
Al realizar muchas solicitudes de pequeños latidos y afirmar que eran grandes, un atacante podría crear una imagen de la mayor parte de la RAM del servidor juntando las respuestas. Los datos almacenados en la RAM que podrían filtrarse incluyen claves de cifrado, certificados HTTPS y datos POST no cifrados, como nombres de usuario y contraseñas.
Nota: Es menos conocido, pero el protocolo de latidos y el exploit también funcionaron en la otra dirección. Se podría haber configurado un servidor malintencionado para leer hasta 64 KB de memoria de usuario por solicitud de latido.
El problema fue descubierto por varios investigadores de seguridad de forma independiente el primero de abril de 2014 y se reveló de forma privada a OpenSSL para que se pudiera crear un parche. El error se publicó cuando se lanzó el parche el siete de abril de 2014. La mejor solución para resolver el problema era aplicar el parche, pero también era posible solucionar el problema desactivando la extensión de latido si el parche no era una opción.
Desafortunadamente, a pesar de que el exploit era público y generalmente bien conocido, muchos sitios web todavía no se actualizaban de inmediato, y la vulnerabilidad se seguía encontrando ocasionalmente incluso años después. Esto llevó a que se utilizaran varios casos del exploit para obtener acceso a cuentas o filtrar datos.