Análisis heart bleed

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=si
ngle&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:
1879E87ED22A69961A769C09CC7BBD920CD274D26D4856AD21A162DA5B9
754415204E737F3AD6D1C658E486D6F1FDB17
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/00
2_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;)
OpenSSL TLSv1 heartbeat read overrun attempt";
OpenSSL TLSv1.1 heartbeat read overrun attempt";
OpenSSL TLSv1.2 heartbeat read overrun attempt";

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;)
TLSv1 large heartbeat response - possible ssl heartbleed attempt";
TLSv1.1 large heartbeat response - possible ssl heartbleed attempt";
TLSv1.2 large heartbeat response - possible ssl heartbleed attempt";
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/pro
tocols/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/

Análisis heart bleed

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Análisis heart bleed

Similar a Análisis heart bleed (20)

Más de Telefónica Grandes Clientes

Más de Telefónica Grandes Clientes (20)

Último

Último (20)

Análisis heart bleed