El bug llamado Heartbleed es una vulnerabilidad importante en la popular librería criptográfica OpenSSL. Esta debilidad permite robar información protegida por el cifrado SSL/TLS usada en buena parte de la seguridad en Internet. SSL/TLS permite conexiones seguras y privadas en servicios web (https Apache y ngnix), de correo electrónico, mensajería instantánea y redes virtuales privadas (VPN) como OpenVPN.





Las versiones OpenSSL afectadas son  la 1.0.1 hasta 1.0.1f (incluída) y la 1.0.2-beta.

Las ramas anteriores

• OpenSSL 1.0.1g  NO es vulnerable
• OpenSSL 1.0.0 rama NO es vulnerable
• OpenSSL 0.9.8 rama NO es vulnerable 

Nota: Los servicios como OpenSSH no están afectados.

Aparece una vulnerabilidad muy grave en OpenSSL que amenaza la seguridad de la mayoría de las conexiones de internet y permite acceder al tráfico cifrado. Un ejemplo de la envergadura del error es que el servidor Apache es utilizado por casi la mitad de las páginas web y usa OpenSSL,lo que puede provocar que todo ese tráfico generado por Apache sea vulnerable a ataques. Una encuesta reciente revela , por ejemplo, que los servidores web de código abierto, Apache y Nginx, que funcionan en un 66% de los sitios web utilizan OpenSSL por defecto.

Para aquellos que no conozcan OpenSSL, es una biblioteca criptográfica utilizada para cifrar gran parte del tráfico que se envía a través de internet de una manera segura y eficiente. OpenSSL es un proyecto basado en software libre que a su vez se utiliza en un gran número de aplicaciones conocidas como OpenSSH y la mayoría de navegadores web a la hora de cifrar el tráfico.

Heartbeat (literalmente "Corazón Sangrante") es una funcionalidad añadida a TLS/DTLS que básicamente permite refrescar una sesión segura sin necesidad de efectuar una renegociación. Entre cliente y servidor se envían mensajes en forma de estructuras muy básicas para asegurarse que el cliente va a seguir enviando peticiones o el servidor sigue ahí para seguir respondiéndolas.

Cuando OpenSSL sedecidió a implementar el RFC correspondiente (RFC 6520), introdujo un bug en la implementación. Dicho fallo permite leer partes de la memoria del proceso, hasta 64k, tanto en el cliente como en el servidor, dependiendo del punto de vista del atacante. Ese es el motivo del apodo con el que han bautizado la vulnerabilidad.

typedef struct ssl3_record_st
    {
        int type;               /* type of record */
        unsigned int length;    /* How many bytes available */
        unsigned int off;       /* read/write offset into 'buf' */
        unsigned char *data;    /* pointer to the record data */
        unsigned char *input;   /* where the decode bytes are */
        unsigned char *comp;    /* only used with decompression - malloc()ed */
        unsigned long epoch;    /* epoch number, needed by DTLS1 */
        unsigned char seq_num[8]; /* sequence number, needed by DTLS1 */
    } SSL3_RECORD;

 Los registros tienen tipo (type), longitud (lenght) y datos (data)

/* Read type and payload length first */
hbtype = *p++;
n2s(p, payload);
pl = p;

 El primer byte del registro SSLv3 es el "heartbeat type". El macro n2s toma 2 bytes de p, y los pone en en el payload. Esto es actualmente la longitud (lenght) del payload. Date cuenta que la actual longitud del registro SSLv3 no es comprobada.

unsigned char *buffer, *bp;
int r;

/* Allocate memory for the response, size is 1 byte
 * message type, plus 2 bytes payload length, plus
 * payload, plus padding
 */
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;

/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);

En linux hay dos maneras de asignar dinámicamente la memoria con malloc(), una es usando sbrk (2) y la otra es usando mmap (2).





Esta vulnerabilidad ha sido denominada por los investigadores como Heartbleed. En resumen, con ella se puede engañar a cualquier sistema que utilice una versión de OpenSSL de hasta 2 años de antigüedad a que revele fragmentos de datos que se encuentren alojados en la memoria del sistema. Esto puede permitir que en un intento de recuperar dicha información se consigan las claves privadas utilizadas para cifrar los datos y, con ellas, se consiga tener acceso completo a los datos que, aparentemente, habían sido cifrados y enviados de forma segura.

Esta vulnerabilidad lleva presente desde diciembre de 2011, es decir, desde la versión 1.0.1 de OpenSSL hasta la actual 1.0.1f publicada en enero de este mismo año, aunque no ha sido hasta hoy cuando ha sido descubierta y publicada.

Recordemos que OpenSSL es una librería usada en multitud de proyectos y es distribuida en múltiples versiones de Linux, etc. Es decir, actualmente existe un número enorme de equipos y servidores que podrían estar expuestos a esta vulnerabilidad. Hay que actualizar la librería OpenSSL a la última versión no vulnerable o compilar las fuentes descartando el soporte Heartbeat definiendo la opción -DOPENSSL_NO_HEARTBEATS.

Un ejemplo de la posible envergadura de esta vulnerabilidad es, por ejemplo, que el servidor web Apache, utilizado por aproximadamente el 50% de las páginas web a nivel mundial, utiliza OpenSSL, por lo que todo el tráfico que se genere en ellos quedará vulnerable. También es vulnerable ngnix ya que por defecto usa las librerías de OpenSSL.

Podemos tener un seguimiento actualizado sobre el avance de esta vulnerabilidad desde la página web oficial de Heartbleed. Estaremos pendientes para informar sobre los avances de esta vulnerabilidad y anunciar tan pronto como sea posible la solución a esta vulnerabilidad que ha afectado a la mayoría de las conexiones de internet “seguras”.

Esta vulnerabilidad está presente desde la versión de OpenSSL que introdujo la implementación con el bug, desde la versión 1.0.1. El fallo fue descubierto por investigadores de la empresa Codenomicon en colaboración con Neel Mehta del equipo de seguridad de Google. Tiene asignado el CVE-2014-0160. Podemos leer un análisis técnico (en inglés) aquí y el commit al repositorio Git de OpenSSL del parche en este enlace . El parche se encuentra incluido en la última versión de OpenSSL, la 1.0.1g.

Los usuarios (clientes) no deben hacer nada (ni actualizar el navegador, ni nada por el estilo), es una vulnerabilidad que afecta y debe ser corregida por los administradores de sistemas de los sitios web y demás servicios que usen SSL.

Heramienta on-line para comprobar si un sitio web es vulnerable:  

• Test en: filippo.io/Heartbleed/
• Test en SSL Labs

Ejemplos:

http://filippo.io/Heartbleed/#meneame.net:443
http://filippo.io/Heartbleed/#foro.elhacker.net:443

All good, foro.elhacker.net:443 seems not affected!

Por cierto, Report en SSL Labs del certificado del foro:

Grado A



https://www.ssllabs.com/ssltest/analyze.html?d=foro.elhacker.net

This server is not vulnerable to the Heartbleed attack. (Experimental)         

 Por ejemplo el popular servicio de Yahoo era vulnerable durante horas:

http://filippo.io/Heartbleed/#yahoo.com

• https://gist.github.com/takeshixx/10107280

Módulo Metasploit Framework:

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

Algunas de las versiones afectadas son:

• Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
• Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
• CentOS 6.5, OpenSSL 1.0.1e-15
• Fedora 18, OpenSSL 1.0.1e-4
• OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
• FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013
• NetBSD 5.0.2 (OpenSSL 1.0.1e)
• OpenSUSE 12.2 (OpenSSL 1.0.1c)

Versiones no afectadas:

• Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14
• SUSE Linux Enterprise Server
• FreeBSD 8.4 - OpenSSL 0.9.8y 5 Feb 2013
• FreeBSD 9.2 - OpenSSL 0.9.8y 5 Feb 2013
• FreeBSD Ports - OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)

 Parches, Soluciones

Es necesario que los administradores de servicios que empleen OpenSSL, se aseguren de actualizarse a la última versión,

/* Read type and payload length first */
if (1 + 2 + 16 > s->s3->rrec.length)
    return 0; /* silently discard */
hbtype = *p++;
n2s(p, payload);
if (1 + 2 + payload + 16 > s->s3->rrec.length)
    return 0; /* silently discard per RFC 6520 sec. 4 */
pl = p;

 

Comando para comprobar servicios que usan SSL y deben ser reiniciados:

lsof -n | grep ssl | grep DEL

o bien

ls -l /proc/*/fd | grep 'ssl.*(deleted)'

En Ubuntu y variantes apt-get:

sudo apt-get update
sudo apt-get upgrade

apt-get update && apt-get upgrade
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho

Se actualizarán los siguientes paquetes:
libssl1.0.0 openssh-client openssl

En Centos/RHE (RedHat 6.5 and CentOS 6.5 son vulnerables) pero se puede actualizar usando yum

yum -y update

Resultado:

Loaded plugins: fastestmirror
Cleaning repos: base extras updates
Cleaning up Everything
Cleaning up list of fastest mirrors
Loaded plugins: fastestmirror
Determining fastest mirrors
 * base: ftp.hosteurope.de
 * extras: mirror.softaculous.com
 * updates: centos.mirror.linuxwerk.com
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package openssl.x86_64 0:1.0.1e-16.el6_5.4 will be updated
---> Package openssl.x86_64 0:1.0.1e-16.el6_5.7 will be an update
---> Package openssl-devel.x86_64 0:1.0.1e-16.el6_5.4 will be updated
---> Package openssl-devel.x86_64 0:1.0.1e-16.el6_5.7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package             Arch         Version                   Repository     Size
================================================================================
Updating:
 openssl             x86_64       1.0.1e-16.el6_5.7         updates       1.5 M
 openssl-devel       x86_64       1.0.1e-16.el6_5.7         updates       1.2 M

Transaction Summary
================================================================================
Upgrade       2 Package(s)

Total download size: 2.7 M
Downloading Packages:
--------------------------------------------------------------------------------
Total                                            40 MB/s | 2.7 MB     00:00   
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction

  Updating   : openssl-1.0.1e-16.el6_5.7.x86_64                             1/4

  Updating   : openssl-devel-1.0.1e-16.el6_5.7.x86_64                       2/4

  Cleanup    : openssl-devel-1.0.1e-16.el6_5.4.x86_64                       3/4

  Cleanup    : openssl-1.0.1e-16.el6_5.4.x86_64                             4/4

  Verifying  : openssl-1.0.1e-16.el6_5.7.x86_64                             1/4

  Verifying  : openssl-devel-1.0.1e-16.el6_5.7.x86_64                       2/4

  Verifying  : openssl-1.0.1e-16.el6_5.4.x86_64                             3/4

  Verifying  : openssl-devel-1.0.1e-16.el6_5.4.x86_64                       4/4

Updated:
  openssl.x86_64 0:1.0.1e-16.el6_5.7  openssl-devel.x86_64 0:1.0.1e-16.el6_5.7

Complete!

.. upgrade complete.

En  Debian Wheezy:

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb

Y es completamente necesario reiniciar los servicios afectados que dependen de ssl, como por ejemplo el servidor web Apache si usamos https o nginx.

Reglas Iptables

iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT"
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j DROP  

Reglas Wireshark 

tshark -i interface port 443 -R 'frame[68:1] == 18'
tshark -i interface port 443 -R 'ssl.record.content_type == 24'

Pero el problema no acaba aquí, es necesario regenerar otra  vez las llaves privadas, ya que durante las horas, días que la vulnerabilidad ha estado presente un atacante haya podido leer la memoria del servidor.

 Las recomendaciones son:

1. Parchear / actualizar
2. Regenerar las nuevas llaves privada
3. Enviar la nueva CSR a tu entidad certificador CA.
4. Obtener e instalar el nuevo certificado firmado
5. Revocar los viejos certificados.

• Apagar el servidor
• Actualizar
• Regenerar los certificados Y ENCIENDE.
  

Y el problema no es tanto el buffer overflow de la memoria, que se puede explotar pero es relativamente complicado, el problema es que con un simple script  puedes dumpear parte de la ram y ver los datos de la sesión (token), ponerlos en una cookie y acceder como otro usuario: es decir hacer un hijacking de una sesión.

https://gist.github.com/takeshixx/10107280

Por ejemplo sitios como Prezi.com (presentaciones dinámicas tipo PowerPoint) recomiendan a todos sus usuarios cambiar contraseñas:

http://engineering.prezi.com/blog/2014/04/12/heartbleet/

O la Wikipedia:

Le recomendamos cambiar su contraseña como medida de precaución estándar, pero no tenemos la intención actualmente de hacerlo obligatorio para todos los usuarios. Reiteramos que no hay evidencia de que los usuarios de la Fundación Wikimedia fueran el blanco de este ataque, pero queremos que todos nuestros usuarios estén lo más seguros posible.

https://blog.wikimedia.org/2014/04/10/wikimedias-response-to-the-heartbleed-security-vulnerability/

Wordpress

Was WordPress.com vulnerable to Heartbleed?
Yes. WordPress.com servers were running the latest version of OpenSSL, which was vulnerable. We generally run the latest version of OpenSSL to enable performance enhancements, such as SPDY, for our users. The non-vulnerable versions of OpenSSL were over two years old.

http://en.blog.wordpress.com/2014/04/15/security-update/

GitHub

We've patched all our systems using the newer, protected versions of OpenSSL. We started upgrading yesterday after the vulnerability became public and completed the roll out today. We've recreated and redeployed new SSL keys and reset internal credentials.We've forcibly reset all browser sessions that were active prior to the vulnerability being addressed on our servers. 

Change your GitHub password. Be sure your password is strong; for more information, see What is a strong password?

https://github.com/blog/1818-security-heartbleed-vulnerability

Fuentes:
http://unaaldia.hispasec.com/2014/04/openssl-afectada-por-una-vulnerabilidad.html
http://www.redeszone.net/2014/04/08/un-error-muy-grave-en-la-seguridad-de-openssl-amenaza-internet/

Análisis técnico del bug:
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html