Incidentes y vulnerabilidades
Heartbleed (CVE-2014-0160) — cuando se filtró memoria desde los cimientos del tráfico cifrado
En 2014, OpenSSL (que sustenta HTTPS) tuvo Heartbleed: filtraba la memoria del servidor, incluso claves privadas y sesiones. Cómo funcionaba el fallo de «devuelve más de lo pedido» y las lecciones: asume que todo se filtró, reemite certificados, rota todos los secretos.
Revisitamos un evento histórico por las lecciones que aún se aplican a tu operación —de forma defensiva, no como reproducción.
Qué ocurrió — «devuelve más de lo pedido»
TLS (el cifrado tras HTTPS) tiene un intercambio de mantenimiento llamado «heartbeat». El cliente envía un poco de datos más una longitud («devuélveme esto»), y el servidor lo repite: simple por diseño.
La implementación de OpenSSL no validaba la longitud declarada. Envía unos pocos bytes pero declara «devuelve 64KB», y el servidor lee más allá de tus datos, en la memoria adyacente, y la devuelve. Si ahí había una clave privada o una sesión, también se filtraba.
Normal: longitud enviada = longitud devuelta
«devuelve 'bird' (4 caracteres), longitud 4» → servidor: "bird"
Heartbleed: payload diminuto + longitud declarada enorme
«devuelve 'bird' (4 caracteres), longitud 64KB» → servidor: "bird + 64KB de memoria vecina (puede incluir claves, sesiones)"
No hacían falta privilegios especiales; repetirlo cosechaba fragmentos de memoria poco a poco. Un diminuto fallo en la más fundacional de las capas sacudió la confianza del tráfico del mundo.
El temor de una filtración «sin rastro»
Heartbleed dejaba pocos rastros en los registros de acceso normales, así que «¿se filtró?» y «¿qué se filtró?» eran difíciles de afirmar. Ante la duda, actúa sobre el peor caso.
Cronología
2014-04-07
Se divulga el fallo y se lanza una versión corregida de OpenSSL el mismo día.justo después
Los servidores de todo el mundo parchean en masa; la amplitud del impacto causa alarma.después
Muchos servicios revocan y reemiten certificados «asumiendo que la clave se filtró», y piden a los usuarios cambiar contraseñas.
Por qué «parchear por sí solo» no es el final
Si la clave privada pudo haberse filtrado, entonces incluso tras parchear, la clave antigua sigue siendo válida. Así que la respuesta tiene dos partes: cerrar el agujero (parchear) más rotar los activos como si se hubieran filtrado (claves, certificados, secretos).
Respuesta insuficiente
- Actualizar OpenSSL y darlo por «corregido»
- Rotar solo el único secreto cuyo abuso confirmaste
- Seguir usando el mismo certificado
Respuesta correcta
- Actualizar y revocar/reemitir los certificados (regenerar la clave privada)
- Rotar todos los secretos, claves y contraseñas que tenga el servidor
- Pedir a los usuarios cambiar sus contraseñas
Lecciones que aún se aplican
Actúa como si todo se hubiera filtrado
Rota todos los secretos, claves y contraseñas, no solo el que confirmaste. Con una filtración sin rastro, asume lo peor.
Revoca y reemite los certificados
Si la clave privada pudo haberse filtrado, reconstruye también el certificado. Hasta que rotes la clave, la filtración pasada sigue viva.
Monitoriza también el software fundacional
Rastrea los CVE de los «cimientos» como OpenSSL, no solo los de tu aplicación. Cuanto más profunda la capa, más amplio el impacto.
Valora la seguridad de memoria
Los fallos de «leer más de lo pedido» se reducen estructuralmente con un diseño y lenguajes con seguridad de memoria. Tenlo en cuenta en aquello sobre lo que construyes.
Lee a continuación
- Glosario: Qué es un CVE
- Incidente: Cuando .env expuso todos los secretos
- Conceptos básicos: Proteger secretos, para principiantes
FAQ
Q¿Qué podía filtrarse en Heartbleed?
La memoria del servidor: en el peor caso, la clave privada TLS, el contenido de sesiones y datos de inicio de sesión. Y dejaba pocos rastros, así que «cuánto se filtró» era difícil de determinar después.
Q¿Por qué «devolvía más de lo pedido»?
En el intercambio de mantenimiento (heartbeat), el servidor confiaba en la longitud que declaraba el otro extremo en vez de comprobarla. Envía unos pocos bytes pero declara «devuelve 64KB», y el servidor leía más allá de tus datos, en la memoria adyacente, y la devolvía. Confiar en la entrada (la longitud) era el agujero.
Q¿Qué importó más en la respuesta?
Tras parchear, actuar como si todo se hubiera filtrado: revocar y reemitir los certificados TLS, y rotar todos los secretos y contraseñas que tuviera el servidor. Parchear la aplicación por sí solo no bastaba.