El estilo de esta traducción aún no ha sido revisado por terceros.Si eres hispanohablante nativo y no has participado en esta traducción puedes colaborar revisando y adaptando el estilo de esta u otras traducciones ya acabadas.
Heartbleed (español: hemorragia de corazón) es un agujero de seguridad de software en la biblioteca de código abierto OpenSSL, solo vulnerable en su 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[1]. 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[2].
Historia
Aparición
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.[3] 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,[4][5][6] 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,[7] 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.[8][9][10]
Descubrimiento
Explicación simplificada de "Heartbleed"
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.[11] El bug implicó un severo error en el manejo de memoria en la implementación de la "Transport Layer Security Heartbeat Extension".[3][12] Este defecto pudo ser usado para revelar más de 64 kilobytes de la memoria de la aplicación con cada heartbeat.[12]
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.[13] De acuerdo con la propia empresa, Neel Mehta primero reportó el bug a OpenSSL, pero ambos, Google y Codenomicon, lo descubrieron independientemente.[8] 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.[8][14] Mehta además felicitó a Codenomicon, sin ir a detalles.[15]
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.[16]
Resolución
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.[17] 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.[18] 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.
Despliegue
Al 8 de mayo de 2014, 318 239 servidores web públicos eran todavía vulnerables.[19]
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.[20]
El 9 de mayo de 2014, sólo el 43 % de los sitios web afectados habían reemitido sus certificados de seguridad.[21] 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.[21] eWeek dijo, por su parte, Heartbleed «es probable que se mantenga un riesgo durante meses, si no años, por venir».[21]
Explotación
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.[22] 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.[23] 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".[24][25]
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.[26] El sitio publicó una explicación de los hechos.[27]
A su vez, investigadores anti-malware explotaron Heartbleed para acceder a foros secretos utilizadas por ciberdelincuentes.[28]
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.[29][30]
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.[31]
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,[32] pero no está claro si los atacantes potenciales sabían de él antes que eso y en qué medida lo fue explotado.
Sobre la base de los exámenes de los registros de auditoría por investigadores, se ha reportado que algunos atacantes podrían haber explotado el defecto durante al menos cinco meses antes del descubrimiento y anuncio.[33][34] Errata Security señaló que un programa no malicioso muy utilizado llamado "Masscan", liberada seis meses antes de la divulgación de Heartbleed, termina abruptamente la conexión en el medio de la negociación de inicio de la misma manera como Heartbleed, generando los mismos mensajes de registro del servidor, y agregó que "Dos cosas nuevas que producen los mismos mensajes de error que puede parecer que los dos están correlacionados, pero por supuesto, no lo están".[35]
Según Bloomberg News, dos fuentes de información privilegiada sin nombre le informaron que la Agencia de Seguridad Nacional (NSA) de los Estados Unidos estaba al tanto de la falla desde poco después de su introducción, pero decidieron mantenerlo en secreto, en lugar de informarlo, con el fin de explotarla para sus propios fines.[36][37][38] La NSA ha negado esta afirmación,[39] al igual que Richard A. Clarke, que fue miembro de un grupo consultivo que examinó la política de vigilancia electrónica de los Estados Unidos; le dijo a Reuters el 11 de abril de 2014 que la NSA no había sabido de Heartbleed.[40]
Comportamiento
La RFC 6520 Heartbeat Extension prueba los enlaces de comunicación segura TLS/DTLS al permitir que un ordenador en un extremo de una conexión envíe un mensaje de "solicitud de latido de corazón" ("Heartbeat Request"), que consiste en una carga útil, típicamente una cadena de texto, junto con la longitud de dicha carga útil como un entero de 16-bits. El equipo receptor debe entonces enviar la misma carga exacta de vuelta al remitente.
Las versiones afectadas de OpenSSL asignan un búfer de memoria para el mensaje a devolver basado en el campo de longitud en el mensaje de solicitud, sin tener en cuenta el tamaño real de la carga útil de ese mensaje. Debido a esta falla de revisión de los límites apropiados, el mensaje devuelto consta de la carga útil, posiblemente seguido de cualquier otra cosa que sea que esté asignada en el buffer de memoria.
Impacto
Al leer un bloque de memoria arbitrario del servidor web, los atacantes pueden recibir datos importantes, comprometiendo la seguridad del servidor y sus usuarios. Los datos que podrían ser robados incluyen la clave maestra del propio servidor, que puede permitir a los atacantes descifrar el tráfico actual o el almacenado, mediante un ataque pasivo man-in-the-middle (si el servidor y el cliente no usan perfect forward secrecy), o activo si perfect forward secrecy está en uso. El atacante no puede controlar qué datos le son devueltos, aunque por la naturaleza del bug, existe cierta probabilidad de que sean datos usados por la misma biblioteca OpenSSL.
Por lo anterior, el bug puede revelar partes descifradas de las peticiones y respuestas del usuario, incluyendo cualquier tipo de información subida por el usuario a través de la conexión "segura", cookies de sesión y contraseñas, etc., lo que permitiría al atacante suplantar la identidad de otro usuario del servicio. Al hacerse público, cerca del 17 % o medio millón de servidores de seguridad web de Internet certificados por autoridades confiables se creían vulnerables a ser atacados.[cita requerida] La Electronic Frontier Foundation,[41] Ars Technica,[42] y Bruce Schneier[43] catalogaron al bug Heartbleed como "catastrófico".[cita requerida] El columnista de Forbes, Joseph Steinberg, describió al bug como potencialmente "la peor vulnerabilidad encontrada (al menos en términos de su impacto potencial) desde que Internet comenzó a tener tráfico comercial".[44]
Sitios web y servicios web
Un analista publicó en GitHub que de los mil sitios más visitados el 8 de abril del 2014, los siguientes presentaban vulnerabilidades: Yahoo!, Imgur, Stack Overflow, Slate, y DuckDuckGo.[45] Los siguientes sitios tienen servicios afectados o hicieron anuncios recomendando a sus usuarios cambiar sus contraseñas en respuesta a este fallo:
IPCop 2.1.4 fue liberado el 8 de abril de 2014, con una solución para "la biblioteca OpenSSL de la que todo el mundo está hablando".[69]
Según el blog LastPass Password Manager, una prueba estándar lo mostró como vulnerables hasta que fue parchado el 8 de abril[cita requerida], pero debido a su uso de encriptación adicional y perfect forward security, potenciales ataques no fueron capaces de explotar este error. Aun así, LastPass recomendó a sus usuarios cambiar las contraseñas que LastPass almacena para los sitios web vulnerables.[70]
LibreOffice 4.2.3 se lanzó el 10 de abril de 2014, con un arreglo para CVE 2014-0160.[71]
LogMeIn afirmó haber "actualizado muchos productos y partes de nuestros servicios que se basan en OpenSSL".[72]
Varias aplicaciones de servidor de HP, tales como: HP System Management Homepage (SMH) para Linux y Windows[73]
Además, la base de datos Common Vulnerabilities and Exposures, asociada con el Departamento de Seguridad Nacional de EE.UU., informa que las siguientes empresas han tenido su software/productos afectados por Heartbleed:
McAfee y en especial algunas versiones de software que proporciona una cobertura antivirus para Microsoft Exchange, cortafuegos de software, y McAfee Email and Web Gateway[74]
Productos de la Serie VMware Horizon, emuladores y suites de cloud computing.[75]
Varios servicios se han puesto a disposición para probar si Heartbleed afecta a un sitio determinado. Sin embargo, muchos servicios se han afirmado ser ineficaces para detectar el error. [134] Las herramientas disponibles incluyen:
Detector Heartbleed de Lookout Mobile Security, una aplicación para dispositivos Android que determina la versión OpenSSL del dispositivo e indica si es el heartbeat vulnerable está habilitado[94][1]
Pruebas de servidor SSL de Qualys SSL Labs[98] la cual no solo revisa por el error Heartbleed, sino que también encuentra otros errores de implementación de SSL/TLS.
Extensiones de navegador, como Chromebleed[99] y FoxBleed[100]
CrowdStrike Heartbleed Scanner[102] - revisa routers, impresoras y otros dispositivos conectados dentro de una red incluyendo sitios web en intranets.[103]
Reporte de Sitios Netcraft[104] - indica si la confidencialidad de un sitio podría estar en riesgo debido a la explotación previa de Heartbleed al revisar datos de la encuesta SSL de Netcraft para saber si el sitio ofrecía la extensión TLS Heartbeat antes del descubrimiento de Heartbleed. La extensión Netcraft para Chrome, Firefox y Opera[105] también hace esta revisión, mientras revisa por certificados potencialmente comprometidos.[106]
Vulnerabilidad de OpenSSL
Vulnerabilidad según los descubridores del fallo:
OpenSSL 1.0.1g - No vulnerable (Corrección del fallo)
OpenSSL 1.0.1 a 1.0.1f - Vulnerable
OpenSSL 1.0.0 - No vulnerable
OpenSSL 0.9.8 - No vulnerable
Reacción
En el día que se dio a conocer, el Tor Project aconsejó en su blog a todo el que busque "fuerte anonimato y privacidad en Internet" debería "alejarse de Internet por completo por los próximos días mientras se arreglan las cosas".[107]
Heartbleed está registrado en el sistema Common Vulnerabilities and Exposures como CVE-2014-0160.[108] La Agencia de Impuestos Canadiense (Canada Revenue Agency) cerró su sitio web de servicios electrónicos debido a preocupaciones por el agujero de seguridad Heartbleed.
Quienes mantienen la plataforma de la Fundación Wikimedia aconsejaron a sus usuarios cambiar sus contraseñas.[109]
Medidas y acciones preventivas
Las medidas que se recomendaron tomar, por parte de administradores de sistemas, eran:[cita requerida]
Aplicar el parche a OpenSSL y pasar a una versión que no estuviera afectada
Reemitir el certificado de seguridad del sitio para eliminar la posibilidad de que estuviera comprometido
revocar el certificado anterior
A los usuarios de los sitios afectados, por su parte, se les recomendó:[110]
No entrar en los sitios que estaban afectados hasta que no se corrigiera el fallo de seguridad
Una vez corregido, cambiar sus contraseñas para eliminar la posibilidad de que hubiera sido comprometida
Causa raíz, posibles lecciones y reacciones
Atendiendo a este problema las mayores compañías de tecnología del mundo acordaron donar millones de dólares para la creación de un grupo que financiará mejoras en programas de código abierto tipo OpenSSL. Amazon.com, Cisco Systems, Facebook, Google, IBM, Intel y Microsoft están entre la docena de compañías que han acordado financiar el grupo, llamado Core Infrastructure Initiative.[111] Cada una donará 300 000 dólares a este programa. La Fundación Linux, sin fines de lucro, anunció la formación del grupo el 24 de abril de 2014. El proyecto respaldará el desarrollo de software de código abierto, que constituye una parte crítica de la infraestructura tecnológica mundial pero cuyos desarrolladores no tienen necesariamente una financiación adecuada para su trabajo, dijo Jim Zemlin, director ejecutivo de la Fundación Linux.[112] La fundación OpenSSL es candidata a ser una de las primeras beneficiadas con este financiamiento.[111]
↑«Tripwire SecureScan». Tripwire - Take Control of IT Security and Regulatory Compliance with Tripwire Software. Archivado desde el original el 16 de abril de 2014. Consultado el 7 de octubre de 2014.
