Vulnerabilidad OpenSSL CVE 2014-0160  

A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server ...  

       

     

 

 

INTRODUCCIÓN  Y  OBJETIVOS  Este informe presenta los resultados obtenidos tras un proceso de investigación y análisis sobre la vulnerabilidad encontrada en la librería OpenSSL, descubierta por uno de los expertos en seguridad de Google y la compañía Codenomicon, que ha sido catalogada con el código CVE-2014-0160 y bautizada como Heartbleed, al estar vinculada con un error en la funcionalidad heartbeat de dicha libería. El objetivo del presente documento es recopilar toda la información disponible sobre la vulnerabilidad en el paquete de seguridad.

RESUMEN  EJECUTIVO  • OpenSSL Consiste en un robusto paquete de herramientas de

administración y bibliotecas relacionadas con la criptografía, que suministran funciones criptográficas a varios protocolos .

• La vulnerabilidad permitiría a un atacante obtener 64Kb de

memoria, que aunque pudiera parecer una cantidad mínima, podría comprometer información crítica del sistema afectado.

• Además del foco sobre HTTPS/SSL, no debemos olvidarnos de

que existen muchos otros protocolos que puedieran estar afectados por esta vulnerabilidad, como XMPP, SMTP / POP3 / IMAP, STARTTLS, SSL VPNs, VoIP etc.

• Lo realmente preocupante es la extensión que ha podido y

puede tener esta vulnerabilidad, ya que OpenSSL es utilizado, entre otros muchos protocolos y servicios, por servidores web como Apache o nginx, que de forma conjunta abarcan el 66% de los sitios activos en Internet (de acuerdo con la Encuesta de Netcraft sobre Servidores Web para Abril de 2014):

 

 

VERSIONES  DEL  OPENSSL  VULNERABLES  No todas las versiones de OpenSSL se han visto afectadas por la vunerabilidad, sino que sólamente una parte de la rama 1.0.1, como:

• 1.0.1 • 1.0.1a • 1.0.1b • 1.0.1c • 1.0.1d • 1.0.1e • 1.0.1f

Las versiones anteriores de OpenSSL no son vulnerables, y la versión 1.0.1g ha solucionado finalmente el problema.

SISTEMAS  OPERATIVOS  AFECTADOS  Muchos sistemas operativos Unix/Linux distribuyen por defecto entre sus componentes las bibliotecas de OpenSSL que se han visto afectadas por la vulnerabilidad. Algunos de los sistemas operativos afectados son:

• Debian Wheezy (estable) y OpenSSL 1.0.1e-2 + deb7u4 • Ubuntu 12.04.4 LTS y OpenSSL 1.0.1-4ubuntu5.11 • CentOS 6.5 y OpenSSL 1.0.1e-15 • Fedora 18 y OpenSSL 1.0.1e-4 • OpenBSD 5.3. y 5.4. y OpenSSL 1.0.1c del 10 de mayo 2012 • FreeBSD: y OpenSSL 10.0 – 1.0.1e del 11 de febrero 2013 • NetBSD 5.0.2. y OpenSSL 1.0.1e • OpenSUSE 12.2 y OpenSSL 1.0.1c

Las siguientes versiones no están afectadas, ya que no incluyen una versión vulnerable:

• Debian Squeeze y OpenSSL 0.9.8o-4squeeze14. • SUSE Linux Enterprise Server. • FreeBSD 8.4 y OpenSSL 0.9.8y • FreeBSD 9.2 y OpenSSL 0.9.8y • FreeBSD Ports y OpenSSL 1.0.1g

Además de estos sistemas operativos, debemos tener en cuenta que si hemos realizado algún tipo de actualización a una versión vulnerable, estaremos afectados por el problema. También lo estará cualquier dispositivo embebido que haga uso de código fuente de estas versiones de OpenSSL.

 

 

ANÁLISIS  DE  LA  VULNERABILIDAD  Es muy importante recalcar que ha sido una de las vulnerabilidades que más ha preocupado a la comunidad de seguridad informático por la sencillez de su explotación ya que existen herramientas con una complejidad mínima que podría utilizarse para obtener usuarios y contraseñas de los servidores afectados. Dentro de la sección de memoria afectada puede encontrarse información crítica como:

• Claves privadas • Usuarios y contraseñas de acceso al dispositivo • Información sensible sobre servicios de terceros • Direcciones de memoria y contenido que podría permitir evadir

mecanismos de mitigación de exploits La vulnerabilidad radica en la implementación de la extensión TLS Heartbeat, de la cual la vulnerabilidad toma el nombre. Esta extensión de TLS es habitualmente necesaria para establecer una sesión y mantenerla durante un periodo largo de tiempo. Podemos consultar y obtener más información en la propia RFC6520 de la extensión, aunque simplificando mucho el protocolo de heartbeat, se basa fundamentalmente en una petición y una respuestá. El siguiente pseudocódigo muestra la estructura de esta petición:

El primer campo del mensaje, HeartbeatMessageType, muestra el tipo del mensaje, que puede tener el valor de 1 o 2, depndiente de si el mensaje es una petición o una respuesta. A continuación, payload_length, se indica el tamaño del payload enviado en el mensaje. Al tratarse de un entero sin signo de 16 bits, su valor máximo es: 216-1=65535 Si estamos familiarizados con la vulnerabilidad, esta cifra nos será familiar, ya que se trata de los famosos 64k de memoria que el atacante será capaz de obtener de memoria cada vez.

 

 

Después nos encontramos el payload del mensaje, que tendrá contenido arbitrario con una longitud correspondiente al tamaño indicado anteriormente. Finalmente, nos encontramos el padding. Se trata de contenido aleatorio, de al menos 16 bytes de longitud, tal y como está definido en la RFC6520, y debe ser ignorado:

Para entender aún mejor esta estructura, se presenta el siguiente gráfico donde se puede obtener una representación gráfica:

MessageType Payload_Length Payload Padding Resaltaremos una condición más del RFC6520, que especifica que si se recibe una petición válida, el recepto deberá responder al mensaje con una copia idéntica del payload recibido, lo cual nos ayudará a entender la razón del envío de bloques de memoria arbitrarios:

A partir de este momento, nos centraremos en parte del código de las funciones encargadas de gestionar los Heartbeat en la versión de OpenSSL 1.0.1f, dentro del fichero d1_both.c. La primera parte del código responsable:

Podemos un puntero p que apunta a la petición de heartbeat que hemos recibido, hbtype contendrá el valor del tipo de mensaje (pregunta o respuesta) que hemos visto anteriormente, y el campo payload que contendrá la longitud del payload que recibamos (no debemos confundir el campo con los datos de payload recibidos), y el padding del mensaje, que conocemos que al menos debe ser de 16 bytes.

 

 

A continuación comienza a procesarse el mensaje:

El primer byte, tipo de mensaje, es copiado a la variable hbtype y el el campo que define la longitud del payload se copia a la variable definida anteriormente como payload, utilizando la función n2s, y dejamos el puntero pl apuntando a la parte del payload recibido. Ahora es momento de comprobar si hemos recibido una solicitud de heartbeat y preparar el contenido en memoria para la respuesta:

Como vemos en el código, crearemos y asignaremos una nueva variable, llamada buffer, que tendrá el tamaño en memoria del paquete de respuesta que vamos a crear. Se asignará como tipo de mensaje una respuesta de heartbeat, y tal como indica el RFC6520, a continuación se copiará campo del tamaño del payload y el payload enviado originalmente. Aquí es donde se encuentra la vulnerabilidad, ya que el campo payload contiene la longitud del campo, y se utilizará para determinar exactamente cuantos bytes de memoria deberían ser copiados en el buffer que utilizaremos para la respuesta, sin comprobar que en el paquete original: payload_length < payload Esto implica que una vez que el atacante modifique estos campos, puede indicar que la longitud del payload es superior a la del mensaje enviado, por lo que los datos a continuación en la memoria del servidor, serán copiados en la respuesta. Por ejemplo, si el atacante define el campo payload_length a un valor de 255 bytes y el payload enviado contiene 5 bytes, el resto del

 

 

contenido de respuesta pertenecerá a zonas de memoria que pueden incluir mensajes sin cifrar, credenciales, claves privadas etc. En el momento actual, los exploits que se encuentran en circulación tratan de capturar el máximo contenido de memoria para optimizar el ataque, indicando que la longitud del payload es el máximo permitido: 216-1=65535 En atacante enviaría el siguiente paquete a la víctima, indicando una longitud de payload diferente al introducido finalmente:

La victima procesará el mensaje de acuerdo al código vulnerable, respondiento con un mensaje en el que volcará el byte recibido, más los datos localizados en la memoria en el momento del ataque, hasta generar los 65535 bytes:

Es importante recalcar que los datos a los que puede tener acceso un atacante corresponden y dependen exclusivamente del contenido de la memoria en el momento del ataque, no siendo posible su determinación. Para corregir este fallo, en la última actualización de OpenSSL (1.0.1f en el momento de publicación de este informe), se ha introducido un cheque para la longitud de escritura en la respuesta:

 

 

COMPROBACIÓN  DE  LA  VULNERABILIDAD  Para comprobar de forma online si un servidor puede estar afectado por la vulnerabilidad CVE-2014-0160, existen posibilidades para realizar el chequeo en diferentes páginas de Internet, con sólo introducir el nombre de dominio correspondiente, como:

• http://filippo.io/Heartbleed/ Portal original para la comprobación de la vulnerabilidad, que también permite descargarnos el código fuente desde el sitio de GitHub, pudiendo adaptarlo a nuestras necesidades o implantarlo como herramienta en nuestra Intranet

• http://www.ssllabs.com/ssltest/ Debemos prestar atención en activar la opción "Do not show the results on the boards" y no mostrar el resultado de forma pública en la página.

Dentro de las diferentes pruebas de concepto y herramientas publicadas para detectar y explotar la vulnerabilidad, destacaremos:

• Prueba de concepto original http://s3.jspenguin.org/ssltest.py

• Metasploit https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb

• Prueba de concepto que permite tunelizar los datos filtrados a través de SSL para evadir IDS/IPS y forenses http://pastebay.net/1422064

 

 

• Script NSE para nmap https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse

• Plugin oficial NASL de Tenable http://www.tenable.com/plugins/index.php?view=single&id=73404

Si no disponemos de conexión a Internet para realizar el chequeo de forma online o descargar la herramienta adecuada, podemos comprobarlo desde la propia línea de comandos haciendo uso del cliente de OpenSSL: $ openssl s_client -connect <ip>:<puerto> Y desde la interfaz, pulsar B. Si recibimos un error, el servicio no es vulnerable. En otro caso, el servicio es potencialmente vulnerable. Veamos como ejemplo una salida real de un servicio vulnerable:

New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : AES256-GCM-SHA384 Session-ID: 1907E866C9EA711CBCC79990A42A3397F42C18187E134C1D45F127D2892D Session-ID-ctx: Master-Key: 1879E87ED22A69961A769C09CC7BBD920CD274D26D4856AD21A162DA5B9754415204E737F3AD6D1C658E486D6F1FDB17 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - db cb 01 bb d5 55 70 90-0a 23 3e 5c 21 e1 f1 f6 .....Up..#>\!... 0010 - 7f 84 fe b3 1a f3 6f f7-82 ea b3 be ff b2 8d 14 ......o......... 0020 - dc 9c e6 d4 fc ed 8a 0d-f9 64 59 1d 2e e3 5b 25 .........dY...[% 0030 - a0 cb 45 c7 bd fd 74 8e-a3 1d 4e 9f 03 2f 30 b9 ..E...t...N../0. 0040 - 1e fa 84 36 bd ba 36 21-5c cc 18 00 18 bb 0a 1a ...6..6!\....... 0050 - b2 01 87 d1 bc cd 11 cb-2e 64 62 36 50 51 89 57 .........db6PQ.W 0060 - e6 d3 19 a8 5e 01 2e 3d-6d ec bc 13 ce fb ee 52 ....^..=m......R 0070 - bc b4 5c 16 92 93 8a a5-bd d7 01 9d 5e a9 84 1e ..\.........^... 0080 - 37 d2 15 93 bf 9d 22 93-06 fb e6 b9 16 18 61 f8 7.....".......a. 0090 - 3b b8 df 77 f9 2e 8c 81-e4 10 e2 3c 07 40 c7 81 ;..w.......<.@.. 00a0 - 13 e2 91 1f 69 a6 7e 64-93 28 30 78 55 34 6b 5e ....i.~d.(0xU4k^ 00b0 - f6 99 78 ba 7c 9f 13 51-d8 2b b3 1f bc e5 7e b1 ..x.|..Q.+....~. Start Time: 1396986311 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- B HEARTBEATING read R BLOCK

 

 

ACTUALIZACIÓN  DE  PAQUETES  AFECTADOS  Para solucionar la vulnerabilidad, es necesario actualizar los paquetes de OpenSSL siguiendo las indicaciones y recomendaciones del fabricante. Como normal general, será necesario actualizar la versión de OpenSSL a una versión que no sea vulnerable (en este momento la 1.0.1f) utilizando el gestor de paquetes correspondiente de nuestro sistema operativo. Es importante reiniciar los servicios correspondientes que utilicen las librerias vulnerables para asegurarnos de que la actualización produce el efecto deseado de inmediato. Por ejemplo, en el caso de Ubuntu, el procedimiento sería el siguiente: $ sudo apt-get update $ sudo apt-get install -y libssl1.0.0 openssl Ahora confirmaremos la versión instalada: $ openssl version -a

OpenSSL 1.0.1 14 Mar 2012 built on: Mon Apr 7 20:33:29 UTC 2014 platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/usr/lib/ssl"

Procedemos a reiniciar todos los servicios que lo utilicen: $ lsof -n | grep ssl | grep DEL A continuación se presenta una lista con los enlaces a las recomendaciones de las principales plataformas: Ubuntu

http://www.ubuntu.com/usn/usn-2165-1/ Redhat https://rhn.redhat.com/errata/RHSA-2014-0376.html CentOS http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html

 

 

Fedora https://lists.fedoraproject.org/pipermail/announce/2014-April/003205.html OpenSUSE http://lists.opensuse.org/opensuse-security-announce/2014-04/msg00005.html OpenBSD http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/002_openssl.patch.sig Gentoo http://www.gentoo.org/security/en/glsa/glsa-201404-07.xml

Si no nos es posible utilizar las fuentes y procedimientos oficiales de actualización, tenemos como alternativa recompilarlo desde cero, deshabilitando el soporte de Heartbeat con la opción: -DOPENSSL_NO_HEARTBEATS

REGLAS  DE  DETECCIÓN  DE  LA  AMENAZA  PARA  IDS/IPS  Para poder además detectar posibles ataques que exploten la vulnerabilidad descrita en este reporte, se recomiendan una serie de reglas para incluir en los diferentes sistemas de IPS/IDS, que nos alertaran cuando un posible atacante realice algún intento malicioso. A continuación se detallan una serie de reglas oficiales dentro del paquete oficial de suscripción para clientes del Sourcefire Vulnerability Research Team:

alert tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"SERVER-OTHER OpenSSL SSLv3 heartbeat read overrun attempt"; flow:to_server,established; content:"|18 03 00|"; depth:3; dsize:>40; detection_filter:track by_src, count 3, seconds 1; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30510; rev:2;) alert tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"SERVER-OTHER OpenSSL TLSv1 heartbeat read overrun attempt"; flow:to_server,established; content:"|18 03 01|"; depth:3; dsize:>40; detection_filter:track by_src, count 3, seconds 1; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30511; rev:2;) alert tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"SERVER-OTHER OpenSSL TLSv1.1 heartbeat read overrun attempt"; flow:to_server,established; content:"|18 03 02|"; depth:3; dsize:>40; detection_filter:track by_src, count 3, seconds 1; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30512; rev:2;) alert tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"SERVER-OTHER OpenSSL TLSv1.2 heartbeat read overrun attempt"; flow:to_server,established; content:"|18 03 03|"; depth:3; dsize:>40;

 

 

detection_filter:track by_src, count 3, seconds 1; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30513; rev:2;) alert tcp $HOME_NET 443 -> $EXTERNAL_NET any (msg:"SERVER-OTHER SSLv3 large heartbeat response - possible ssl heartbleed attempt"; flow:to_client,established; content:"|18 03 00|"; depth:3; byte_test:2,>,128,0,relative; detection_filter:track by_dst, count 5, seconds 60; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted- recon; sid:30514; rev:3;) alert tcp $HOME_NET 443 -> $EXTERNAL_NET any (msg:"SERVER-OTHER TLSv1 large heartbeat response - possible ssl heartbleed attempt"; flow:to_client,established; content:"|18 03 01|"; depth:3; byte_test:2,>,128,0,relative; detection_filter:track by_dst, count 5, seconds 60; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted- recon; sid:30515; rev:3;) alert tcp $HOME_NET 443 -> $EXTERNAL_NET any (msg:"SERVER-OTHER TLSv1.1 large heartbeat response - possible ssl heartbleed attempt"; flow:to_client,established; content:"|18 03 02|"; depth:3; byte_test:2,>,128,0,relative; detection_filter:track by_dst, count 5, seconds 60; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted- recon; sid:30516; rev:3;) alert tcp $HOME_NET 443 -> $EXTERNAL_NET any (msg:"SERVER-OTHER TLSv1.2 large heartbeat response - possible ssl heartbleed attempt"; flow:to_client,established; content:"|18 03 03|"; depth:3; byte_test:2,>,128,0,relative; detection_filter:track by_dst, count 5, seconds 60; metadata:policy balanced-ips drop, policy security-ips drop, service ssl; reference:cve,2014-0160; classtype:attempted- recon; sid:30517; rev:3;)

También se ha publicado un módulo de detección para Bro, disponible en la URL oficial:

https://github.com/bro/bro/blob/topic/bernhard/heartbeat/scripts/policy/protocols/ssl/heartbleed.bro

La correspondiente regla para Suricata:

alert tls any any -> any any ( msg:"TLS HEARTBLEED malformed heartbeat record"; flow:established,to_server; dsize:>7; content:"|18 03|"; depth:2; lua:tls-heartbleed.lua; classtype:misc-attack; sid:3000001; rev:1;)

Y el script necesario:

function init (args) local needs = {} needs["payload"] = tostring(true) return needs end function match(args) local p = args['payload'] if p == nil then --print ("no payload") return 0 end

 

 

if #p < 8 then --print ("payload too small") end if (p:byte(1) ~= 24) then --print ("not a heartbeat") return 0 end -- message length len = 256 * p:byte(4) + p:byte(5) --print (len) -- heartbeat length hb_len = 256 * p:byte(7) + p:byte(8) -- 1+2+16 if (1+2+16) >= len then print ("invalid length heartbeat") return 1 end -- 1 + 2 + payload + 16 if (1 + 2 + hb_len + 16) > len then print ("heartbleed attack detected: " .. (1 + 2 + hb_len + 16) .. " > " .. len) return 1 end --print ("no problems") return 0 end return 0

MITIGAR  LOS  EFECTOS  DE  LA  AMENAZA  En última instancia, además de actualizar los paquetes afectados por la vulnerabilidad, será necesario gestionar los datos que hayan podido ser comprometidos por terceras personas, para evitar ataques posteriores. Debido a que la vulnerabilidad permite acceder a bloques de memoria en los servidores afectados, es posible que información como la detallada a continuación, se haya visto comprometida:

• Credenciales (login y password) de usuarios del sistema • Claves privadas de los certificados TLS/SSL • Información sensible sobre servicios de terceros • Direcciones de memoria y contenido que podría permitir

evadir mecanismos de mitigación de exploits  Solamente una vez actualizado y corregido el problema, se recomendará comenzar con el proceso de mitigación, que pueden afectar tanto a la seguridad de los usuarios, como a la del servidor y los certificados instalados.

 

 

CLAVES  PRIVADAS  DE  LOS  CERTIFICADOS  SSL  En la siguiente captura, podremos demostrar que es posible bajo ciertas condiciones, acceder a la clave privada SSL de forma parcial o total de un sistema vulnerable:

Será necesario actuar de la siguiente manera en relación las claves privadas SSL del servidor afectado:

1. Revocar los certificados instalados, ya que un atacante podría haber podido acceder a ellas, y por tanto estar comprometidas

2. Generar nuevas claves y nuevos certificados para los servicios que que hayan estado expuestos

3. Mantener una copia de los certificados y claves antiguas, por si fuera necesario en un futuro acceder a información protegida por los mismos

 

 

CLAVES  Y  DATOS  DE  USUARIOS En lo referente a las claves y datos de los usuarios, y con el objetivo claro de salvaguardar la información, así como de generar confianza en los clientes, se recomienda regenerar las contraseñas de los usuarios o comunicarles que será necesario un cambio en la contraseña, forzándolo en el siguiente acceso a la plataforma. Esta acción es de vital importancia, ya que el acceso a todas estas credenciales es más factible en su totalidad en los fragmentos de memoria devueltos por el servidor afectado:

 

OTROS  SERVICIOS  Finalmente, deberemos tener en cuenta que la posible afectación de plataformas intermedias, como los VPN SSLs, han podido exponer a un atacante el tráfico en claro que se encontrara cursando durante la explotación del ataque, revelando credenciales de servicios de terceros, cookies, así como otra información sensible:

 

REFERENCIAS  Puede  encontrarse  más  información  de  utilidad  sobre  esta  vulnerabilidad  en  los  siguientes  enlaces  proporcionados:  

• http://cert.inteco.es/securityAdvice/Actualidad/Avisos_seguridad_tecnicos/grave_vulnerabilidad_funcionalidad_heartbeat_openssl_20140  408  

• https://cve.mitre.org/cgi-­‐bin/cvename.cgi?name=CVE-­‐2014-­‐0160  http://heartbleed.com  

• http://www.openssl.org/news/secadv_20140407.txt  

 

 

• http://vrt-­‐blog.snort.org/2014/04/heartbleed-­‐memory-­‐disclosure-­‐upgrade.html  

• http://doc.emergingthreats.net/bin/search/Main/?search=heartbleed  http://www.blackploit.com/2014/04/vulnerabilidad-­‐critica-­‐en-­‐openssl-­‐cve.html  

• http://www.kb.cert.org/vuls/id/720951  • https://github.com/musalbas/heartbleed-­‐

masstest/blob/master/top1000.txt  • http://www.circl.lu/pub/tr-­‐21/