Heartbleed (español: hemorragia de corazón) es un agujero de seguridad en la biblioteca de código abierto OpenSSL, solo vulnerable en s versión 1.0.1f, que permite a un atacante leer la memoria de un servidor o un cliente, permitiéndole por ejemplo, conseguir las claves privadas SSL de un servidor. Investigaciones de auditorías en un principio creyeron que algunos atacantes podrían haber explotado este error desde al menos cinco meses antes de que fuera descubierto y publicado, pero más tarde se mostraron neutrales con respecto a sus afirmaciones y concluyeron que no podían demostrar este hecho, ya que se observó que otras herramientas podían generar los mismos registros (logs). Sin embargo, tampoco podían negar que no hubiesen sido intentos de ataque.
La extensión Heartbeat para los protocolos Transport Layer Security (TLS) y Datagram Transport Layer Security (DTLS) se propuso como un estándar en febrero del 2012 por el RFC 6520. Esto provee una forma de probar y mantener viva un enlace de comunicación segura sin la necesidad de renegociar la conexión cada vez.
En 2011, uno de los autores del RFC, Robin Seggelmann, en ese tiempo un estudiante de doctorado en la Universidad de Duisburg-Essen, implementó la extensión Heartbeat para OpenSSL. Siguiendo la petición de poner su trabajo en OpenSSL, su cambio fue revisado por Stephen N. Henson, uno de los cuatro desarrolladores del núcleo de OpenSSL. Henson aparentemente no se dio cuenta del error en la implementación de Seggelmann, e introdujo el código con falla en el repositorio de OpenSSL el 31 de diciembre de 2011. El código vulnerable fue adoptado y usado ampliamente con el lanzamiento de la versión 1.0.1 de OpenSSL el 14 de marzo de 2012. El soporte de Heartbeat estaba habilitado de forma predeterminada, causando que las versiones afectadas fueran vulnerables por defecto.
De acuerdo con Mark J. Cox de OpenSSL, Neel Mehta (Del equipo de seguridad de Google) reportó un Heartbleed en el 1 de abril de 2014. El bug implicó un severo error en el manejo de memoria en la implementación de la "Transport Layer Security Heartbeat Extension". Este defecto pudo ser usado para revelar más de 64 kilobytes de la memoria de la aplicación con cada heartbeat.
El bug fue nombrado por un ingeniero en la firma Codenomicon, una empresa finlandesa de ciber seguridad, quien aparte creó el logo y lanzó el dominio Heartbleed.com para explicar el bug al público en general. De acuerdo con la propia empresa, Neel Mehta primero reportó el bug a OpenSSL, pero ambos, Google y Codenomicon, lo descubrieron independientemente. Codenomicon reporta al 3 de abril como su fecha de descubrimiento del bug y su fecha de notificación de NCSC-FI (formalmente conocido como CERT-FI) para coordinación de vulnerabilidades. Mehta además felicitó a Codenomicon, sin ir a detalles.
The Sydney Morning Herald publicó una línea del tiempo del descubrimiento el 15 de abril, la cual mostraba que algunas organizaciones podrían ser capaces de reparar el bug antes de su publicación. En algunos casos, no está tan claro cómo lo encontraron.
Bodo Moeller y Adam Langley de Google prepararon la corrección para Heartbleed. El parche resultante, que se añadió al seguimiento de incidencias de Red Hat, con fecha 21 de marzo de 2014. La fecha cronológica siguiente disponible en la evidencia pública es la afirmación de CloudFlare de que ellos solucionaron el defecto en sus sistemas el 31 de marzo de 2014. Stephen N. Henson aplica la corrección al sistema de control de versiones de OpenSSL, el 7 de abril. La primera versión corregida, 1.0.1g, fue lanzada el mismo día.
Al 8 de mayo de 2014, 318 239 servidores web públicos eran todavía vulnerables.
Renovación y revocación de certificados
Según Netcraft, alrededor de 30 000 de los más de 500 000 certificados X.509 que podrían haber sido comprometidos debido a Heartbleed habían sido reemitidos al 11 de abril de 2014, aunque menos habían sido revocados.
El 9 de mayo de 2014, sólo el 43 % de los sitios web afectados habían reemitido sus certificados de seguridad. Además, el 7 % de los certificados de seguridad reemitidos utilizaron las claves potencialmente comprometidos. «Mediante la reutilización de la misma clave privada, un sitio que se vio afectado por el fallo Heartbleed aún enfrenta exactamente los mismos riesgos que los que aún no lo han reemplazado sus certificados SSL», dijo Netcraft. eWeek dijo, por su parte, Heartbleed «es probable que se mantenga un riesgo durante meses, si no años, por venir».
La Agencia de Ingresos de Canadá reportó el robo de números de Seguro Social que pertenecen a 900 contribuyentes, y declaró que fueron accedidos a través de un exploit del fallo durante un período de seis horas el 8 de abril de 2014. Cuando el ataque se descubrió, la agencia cerró su sitio web y amplió el plazo de presentación de los contribuyentes 30 de abril al 5 de mayo. La agencia dijo que ofrecerá a todos los afectados con servicios de protección al crédito sin costo alguno. El 16 de abril, la Policía Montada anunció que habían acusado a un estudiante de ingeniería en relación con el robo con "uso no autorizado de una computadora" y de "mal uso en relación a datos".
En otro incidente, el sitio de crianza de los hijos del Reino Unido Mumsnet tuvo varias cuentas de usuario secuestradas, y se hicieron pasar por su director general. El sitio publicó una explicación de los hechos.
A su vez, investigadores anti-malware explotaron Heartbleed para acceder a foros secretos utilizadas por ciberdelincuentes.
El 12 de abril de 2014, al menos dos investigadores independientes fueron capaces de robar claves privadas usando este ataque desde un servidor experimental intencionalmente creado a tal fin por CloudFlare.
Se informó por un profesor de la Universidad de Míchigan que una computadora en China se había utilizado para la piratería y otras actividades maliciosas intentó el 8 de abril de 2014 para explotar Heartbleed para atacar a un servidor de la universidad, que en realidad era un honeypot dejado intencionadamente vulnerable, diseñado para atraer a los ataques que podrían entonces ser estudiados.
Posible conocimiento y explotación antes de la divulgación
Muchos sitios web importantes parcharon o desactivaron el fallo en cuestión de días de su anuncio, pero no está claro si los atacantes potenciales sabían de él antes que eso y en qué medida lo fue explotado.