Heartbleed

Heartbleed es un fallo de seguridad en algunas versiones obsoletas de la biblioteca de criptografía OpenSSL , una implementación ampliamente utilizada del protocolo Transport Layer Security (TLS). Se introdujo en el software en 2012 y se hizo público en abril de 2014. Heartbleed podía explotarse independientemente de si la instancia vulnerable de OpenSSL se ejecutaba como servidor o cliente TLS. Se debía a una validación de entrada incorrecta (debido a la falta de una comprobación de límites ) en la implementación de la extensión TLS Heartbeat . ^{[ 5 ]} De ahí que el nombre del fallo derivara de Heartbeat . ^{[ 6 ]} La vulnerabilidad se clasificó como una sobrelectura de búfer , ^{[ 7 ]} una situación en la que se pueden leer más datos de los que deberían permitirse. ^{[ 8 ]}

Heartbleed se registró en la base de datos Common Vulnerabilities and Exposures como CVE - 2014-0160 . ^{[ 7 ]} Se publicó una versión corregida de OpenSSL el 7 de abril de 2014, el mismo día en que se hizo pública la vulnerabilidad Heartbleed. ^{[ 9 ]}

Las implementaciones de TLS distintas de OpenSSL, como GnuTLS , los Servicios de Seguridad de Red de Mozilla y la implementación de TLS de la plataforma Windows , no se vieron afectadas porque el defecto existía en la implementación de TLS de OpenSSL y no en el protocolo en sí. ^{[ 10 ]}

Los administradores de sistemas a menudo tardaban en actualizar sus sistemas. A fecha de 20 de mayo de 2014  , el 1,5% de los 800.000 sitios web más populares habilitados para TLS seguían siendo vulnerables al error, ^{[ 11 ]} y para el 21 de junio de 2014  , 309.197 servidores web públicos permanecieron vulnerables. ^{[ 12 ]} Según un informe del 23 de enero de 2017  Según el informe ^{[ 13 ]} de Shodan , casi 180.000 dispositivos conectados a Internet seguían siendo vulnerables al fallo, ^{[ 14 ] [ 15 ]} pero para el 6 de julio de 2017  , el número había descendido a 144.000 según una búsqueda realizada en shodan.io sobre la vulnerabilidad. ^{[ 16 ]} Aproximadamente dos años después, 11 de julio de 2019  Shodan informó ^{[ 17 ]} que 91.063 dispositivos eran vulnerables. Estados Unidos tenía la mayor cantidad de dispositivos vulnerables, con 21.258 (23%), y los 10 países con la mayor cantidad de dispositivos vulnerables tenían un total de 56.537 dispositivos vulnerables (62%). Los países restantes sumaban 34.526 dispositivos (38%). El informe también desglosó los dispositivos por otras 10 categorías, como organización (las 3 principales eran compañías de telecomunicaciones inalámbricas), producto ( Apache httpd , Nginx ) y servicio ( HTTPS , 81%).

La extensión Heartbeat para los protocolos Transport Layer Security (TLS) y Datagram Transport Layer Security ⁽ DTLS) fue propuesta como estándar en febrero de 2012 por RFC 6520. ^{[ 18} ] Proporciona una forma de probar y mantener activos los enlaces de comunicación seguros sin necesidad de renegociar la conexión cada vez. En 2011, uno de los autores de RFC, Robin Seggelmann, entonces estudiante de doctorado en la Fachhochschule Münster , implementó la extensión Heartbeat para OpenSSL. Tras la solicitud de Seggelmann de incorporar el resultado de su trabajo a OpenSSL, ^{[ 19 ] [ 20 ] [ 21 ]} su cambio fue revisado por Stephen N. Henson, uno de los cuatro desarrolladores principales de OpenSSL. Henson no detectó un error en la implementación de Seggelmann e introdujo el código defectuoso en el repositorio de código fuente de OpenSSL el 31 de diciembre de 2011. El defecto se propagó con el lanzamiento de la versión 1.0.1 de OpenSSL el 14 de marzo de 2012. La compatibilidad con Heartbeat se habilitó por defecto, lo que provocó que las versiones afectadas fueran vulnerables. ^{[ 3 ] [ 22 ]} 

La extensión Heartbeat del RFC 6520 prueba los enlaces de comunicación segura TLS/DTLS permitiendo que un equipo en un extremo de la conexión envíe un mensaje de solicitud de Heartbeat , que consiste en una carga útil, generalmente una cadena de texto, junto con la longitud de dicha carga útil como un entero de 16 bits . El equipo receptor debe entonces enviar exactamente la misma carga útil al remitente.

Las versiones afectadas de OpenSSL asignan un búfer de memoria para el mensaje que se va a devolver basándose en el campo de longitud del mensaje solicitante, sin tener en cuenta el tamaño real de la carga útil de dicho mensaje. Debido a esta omisión en la comprobación de límites adecuada , el mensaje devuelto consiste en la carga útil, posiblemente seguida de cualquier otro dato que se encuentre en el búfer de memoria asignado.

Heartbleed se explota enviando una solicitud de latido mal formada con una carga útil pequeña y un campo de longitud grande a la parte vulnerable (generalmente un servidor) para obtener la respuesta de la víctima, lo que permite a los atacantes leer hasta 64 kibibytes de la memoria de la víctima que probablemente haya sido utilizada previamente por OpenSSL. ^{[ 68 ]} Mientras que una solicitud de latido podría pedir a una parte que "envíe de vuelta la palabra de cuatro letras 'bird ' " , lo que resulta en una respuesta de "bird", una "solicitud Heartbleed" maliciosa de "envíe de vuelta la palabra de 500 letras 'bird ' " haría que la víctima devolviera "bird" seguido de los 496 caracteres subsiguientes que la víctima tuviera en la memoria activa. De esta manera, los atacantes podrían recibir datos sensibles, comprometiendo la confidencialidad de las comunicaciones de la víctima. Aunque un atacante tiene cierto control sobre el tamaño del bloque de memoria revelado, no tiene control sobre su ubicación y, por lo tanto, no puede elegir qué contenido se revela.

if ( 1 + 2 + payload + 16 > s -> s3 -> rrec . length ) return 0 ; /* descartar silenciosamente según RFC 6520 sec. 4 */

Los datos obtenidos mediante un ataque Heartbleed pueden incluir intercambios no cifrados entre partes TLS que probablemente sean confidenciales, incluidos los datos de formularios enviados en las solicitudes de los usuarios. Además, los datos confidenciales expuestos podrían incluir secretos de autenticación, como cookies de sesión y contraseñas, lo que podría permitir a los atacantes suplantar la identidad de un usuario del servicio. ^{[ 75 ]}

Un ataque también puede revelar claves privadas de las partes comprometidas, ^{[ 3 ] [ 76 ]} lo que permitiría a los atacantes descifrar las comunicaciones (tráfico almacenado futuro o pasado capturado mediante escucha pasiva, a menos que se utilice el secreto perfecto hacia adelante , en cuyo caso solo se puede descifrar el tráfico futuro si se intercepta mediante ataques de intermediario ).

Un atacante que haya obtenido material de autenticación puede suplantar la identidad del propietario del material después de que la víctima haya corregido Heartbleed, siempre y cuando el material sea aceptado (por ejemplo, hasta que se cambie la contraseña o se revoque la clave privada). Por lo tanto, Heartbleed constituye una amenaza crítica para la confidencialidad. Sin embargo, un atacante que suplante la identidad de una víctima también puede alterar los datos. Indirectamente, las consecuencias de Heartbleed pueden ir mucho más allá de una simple violación de la confidencialidad para muchos sistemas. ^{[ 77 ]}

Una encuesta realizada en abril de 2014 a adultos estadounidenses reveló que el 60 por ciento había oído hablar de Heartbleed. Entre los usuarios de internet, el 39 por ciento había protegido sus cuentas en línea, por ejemplo, cambiando contraseñas o cancelando cuentas; el 29 por ciento creía que su información personal corría peligro debido al fallo Heartbleed; y el 6 por ciento creía que su información personal había sido robada. ^{[ 78 ]}

La vulnerabilidad Heartbleed se resuelve actualizando OpenSSL a una versión parcheada (1.0.1g o posterior). OpenSSL puede utilizarse como programa independiente, objeto compartido dinámico o biblioteca de enlace estático ; por lo tanto, el proceso de actualización puede requerir reiniciar los procesos cargados con una versión vulnerable de OpenSSL, así como volver a enlazar los programas y bibliotecas que lo enlazaban estáticamente. En la práctica, esto implica actualizar los paquetes que enlazan OpenSSL estáticamente y reiniciar los programas en ejecución para eliminar la copia en memoria del código OpenSSL antiguo y vulnerable.

Una vez corregida la vulnerabilidad, los administradores de servidores deben abordar la posible violación de la confidencialidad. Dado que Heartbleed permitía a los atacantes revelar claves privadas , estas deben considerarse comprometidas; los pares de claves deben regenerarse y los certificados que las utilizan deben reemitirse; los certificados antiguos deben revocarse . Heartbleed también tenía el potencial de permitir la divulgación de otros secretos en memoria; por lo tanto, otro material de autenticación (como contraseñas ) también debe regenerarse. Rara vez es posible confirmar que un sistema afectado no haya sido comprometido, o determinar si se filtró una información específica. ^{[ 175 ]}

Dado que es difícil o imposible determinar cuándo se pudo haber comprometido una credencial y cómo la pudo haber utilizado un atacante, ciertos sistemas pueden requerir trabajos de remediación adicionales incluso después de corregir la vulnerabilidad y reemplazar las credenciales. Por ejemplo, las firmas realizadas con claves utilizadas en una versión vulnerable de OpenSSL podrían haber sido creadas por un atacante; esto aumenta la posibilidad de que se haya violado la integridad y expone las firmas al rechazo . La validación de las firmas y la legitimidad de otras autenticaciones realizadas con una clave potencialmente comprometida (como el uso de certificados de cliente ) deben realizarse considerando el sistema específico involucrado.

Aunque evaluar el costo total de Heartbleed es difícil, eWeek estimó US$500 millones como punto de partida. ^{[ 178 ]}

El artículo de David A. Wheeler, « Cómo prevenir el próximo Heartbleed», analiza por qué Heartbleed no se descubrió antes y sugiere varias técnicas que podrían haber llevado a una identificación más rápida, así como técnicas que podrían haber reducido su impacto. Según Wheeler, la técnica más eficiente que podría haber prevenido Heartbleed es un conjunto de pruebas que realice exhaustivamente pruebas de robustez , es decir, pruebas que demuestren que las entradas no válidas provocan fallos en lugar de éxitos. Wheeler destaca que un único conjunto de pruebas de propósito general podría servir de base para todas las implementaciones de TLS. ^{[ 179 ]}

Según un artículo de Robert Merkel en The Conversation , Heartbleed reveló una grave deficiencia en el análisis de riesgos . Merkel opina que OpenSSL prioriza el rendimiento sobre la seguridad, lo cual, en su opinión, ya no tiene sentido. Sin embargo, Merkel considera que la culpa no recae tanto en OpenSSL como en sus usuarios, quienes optaron por utilizarlo sin invertir en mejores auditorías y pruebas. Merkel explica que dos aspectos determinan el riesgo de que otros errores similares generen vulnerabilidades. Primero, el código fuente de la biblioteca influye en el riesgo de escribir errores con tal impacto. Segundo, los procesos de OpenSSL afectan la rapidez con la que se detectan los errores. Respecto al primer aspecto, Merkel menciona el uso del lenguaje de programación C como un factor de riesgo que favoreció la aparición de Heartbleed, haciéndose eco del análisis de Wheeler. ^{[ 179 ] [ 180 ]}

En el mismo aspecto, Theo de Raadt , fundador y líder de los proyectos OpenBSD y OpenSSH , ha criticado a los desarrolladores de OpenSSL por escribir sus propias rutinas de gestión de memoria y, por lo tanto, según afirma, eludir las contramedidas de explotación de la biblioteca estándar C de OpenBSD , diciendo: "OpenSSL no está siendo desarrollado por un equipo responsable". ^{[ 181 ] [ 182 ]} Tras la divulgación de Heartbleed, miembros del proyecto OpenBSD bifurcaron OpenSSL en LibreSSL . ^{[ 183 ]} LibreSSL realizó una gran limpieza de código, eliminando más de 90 000 líneas de código C solo en su primera semana. ^{[ 184 ]}

El autor del cambio que introdujo Heartbleed, Robin Seggelmann, ^{[ 185 ]} declaró que omitió validar una variable que contenía una longitud y negó cualquier intención de enviar una implementación defectuosa. ^{[ 19 ]} Tras la divulgación de Heartbleed, Seggelmann sugirió centrarse en el segundo aspecto, afirmando que OpenSSL no es revisado por suficientes personas. ^{[ 186 ]} Si bien el trabajo de Seggelmann fue revisado por un desarrollador principal de OpenSSL, la revisión también tenía como objetivo verificar mejoras funcionales, una situación que hace que las vulnerabilidades sean mucho más fáciles de pasar por alto. ^{[ 179 ]}

El desarrollador principal de OpenSSL, Ben Laurie, afirmó que una auditoría de seguridad de OpenSSL habría detectado Heartbleed. ^{[ 187 ]} El ingeniero de software John Walsh comentó:

Piénsalo, OpenSSL solo tiene dos personas [a tiempo completo] para escribir, mantener, probar y revisar 500.000 líneas de código crítico para el negocio. ^{[ 188 ]}

El presidente de la fundación OpenSSL, Steve Marquess, dijo: «El misterio no es que unos pocos voluntarios sobrecargados de trabajo pasaran por alto este error; el misterio es por qué no ha ocurrido con más frecuencia». ^{[ 188 ]} David A. Wheeler describió las auditorías como una excelente manera de encontrar vulnerabilidades en casos típicos, pero señaló que «OpenSSL utiliza estructuras innecesariamente complejas, lo que dificulta la revisión tanto para humanos como para máquinas». Escribió:

Debe haber un esfuerzo continuo por simplificar el código, ya que de lo contrario, añadir funcionalidades aumentará gradualmente la complejidad del software. El código debe refactorizarse periódicamente para hacerlo simple y claro, en lugar de añadir constantemente nuevas características. El objetivo debe ser un código que sea "obviamente correcto", en contraposición a un código tan complicado que "no vea ningún problema". ^{[ 179 ]}

Según el investigador de seguridad Dan Kaminsky , Heartbleed es un indicio de un problema económico que debe solucionarse. Al ver el tiempo que se tardó en detectar este simple error en una función simple de una dependencia "crítica", Kaminsky teme que surjan numerosas vulnerabilidades futuras si no se toman medidas. Cuando se descubrió Heartbleed, OpenSSL era mantenido por un puñado de voluntarios, de los cuales solo uno trabajaba a tiempo completo. ^{[ 189 ]} Las donaciones anuales al proyecto OpenSSL eran de unos 2000 dólares estadounidenses. ^{[ 190 ]} El sitio web de Heartbleed de Codenomicon recomendaba donaciones monetarias al proyecto OpenSSL. ^{[ 3 ]} Tras enterarse de que las donaciones de los 2 o 3 días posteriores a la divulgación de Heartbleed ascendían a 841 dólares estadounidenses, Kaminsky comentó: "Estamos construyendo las tecnologías más importantes para la economía global sobre una infraestructura con una financiación sorprendentemente insuficiente". ^{[ 191 ]} El desarrollador principal Ben Laurie ha calificado el proyecto como "completamente sin financiación". ^{[ 190 ]} Aunque la OpenSSL Software Foundation no tiene un programa de recompensas por errores , la iniciativa Internet Bug Bounty otorgó US$15,000 a Neel Mehta de Google, quien descubrió Heartbleed, por su divulgación responsable. ^{[ 190 ]} Posteriormente, Mehta donó su recompensa a una recaudación de fondos de la Freedom of the Press Foundation . ^{[ 192 ]}

Paul Chiusano sugirió que Heartbleed pudo haber sido resultado de una economía de software fallida. ^{[ 193 ]}

La respuesta colectiva de la industria a la crisis fue la Iniciativa de Infraestructura Central , un proyecto multimillonario anunciado por la Fundación Linux el 24 de abril de 2014 para proporcionar fondos a elementos críticos de la infraestructura global de información. ^{[ 194 ]} La iniciativa pretende permitir que los desarrolladores principales trabajen a tiempo completo en sus proyectos y sufragar auditorías de seguridad, infraestructura de hardware y software, viajes y otros gastos. ^{[ 195 ]} OpenSSL es candidato a convertirse en el primer beneficiario de la financiación de la iniciativa. ^{[ 194 ]}

Tras el descubrimiento, Google estableció el Proyecto Zero , cuya misión es encontrar vulnerabilidades de día cero para ayudar a proteger la web y la sociedad. ^{[ 196 ] [ 197 ]}