Seria vulnerabilidad en biblioteca OpenSSL #Heartbleed compromete muchos servicios

En las últimas horas se han disparado las alertas por las implicancias de seguridad que provoca una vulnerabilidad que tiene tenía la librería criptografica OpenSSL, apodada #Heartbleed. Esta vulnerabilidad ha sido descubierta por Neel Mehta del equipo de Google Security, y el CVE reservado (CVE-2014-0160) fue creado el 3 de Diciembre de 2013.

El sitio web http://heartbleed.com/ creado a tal efecto por la empresa finesa Codenomicon defensic reune valiosa información respecto de esta vulnerabilidad.

El bug Heartbleed

Schneier dice que el bug Heartbleed es catastrófico. El motivo de su nombre es que el fallo se encuentra en una extensión denominada "Heartbeat" y obviamente los que la han descubierto no han dejado pasar el juego de palabras, veremos la razón. Heartbeat es una funcionalidad (documentada en la RFC 652) 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.

Esta es una vulnerabilidad crítica en la popular librería de software criptográfico OpenSSL. Esta debilidad permite robar información protegida, en condiciones normales, por el cifrado SSL/TLS utilizado para asegurar Internet. SSL/TLS proveen seguridad a las comunicaciones y privacidad en Internet para las aplicaciones como la web, correo electrónico, la mensajería instantánea y algunas redes privadas virtuales (VPNs).

Cuando OpenSSL se decidió a implementar el RFC correspondiente, 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.

El bug Heartbleed le permite a cualquiera en Internet leer la memoria de los sistemas protegidos por las versiones vulnerables del software OpenSSL. Esto compromete las claves privadas usadas para identificar a los proveedores de servicios y para cifrar el tráfico, los nombres y contraseñas de usuarios y el contenido. Esto permite a los atacantes fisgonear las comunicaciones, robar datos directamente de los servicios y usuarios, y suplantar a los servicios y a los usuarios.

En la práctica ¿qué permite?

Hemos probado algunos de nuestros propios servicios desde la perpectiva del atacante. No atacamos a nosotros mismos desde el exterior, sin dejar rastros. Sin utilizar ninguna información privilegiada ni credenciales, fuimos capaces de robarnos las claves privadas usadas para nuestros certificados X.509, nombres de usuarios y contraseñas, mensajes instantáneos, correos electrónicos e información crítica de negocios y comunicaciones.

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 Neel Mehta del equipo de seguridad de Google e
independientemente por el equipo de seguridad de la empresa Codenomicon. El commit al repositorio Git de OpenSSL del parche. El parche se encuentra incluido en la última versión de OpenSSL, la 1.0.1g.

• OpenSSL 1.0.1 a 1.0.1f (inclusive), son vulnerables
• OpenSSL 1.0.2-beta1, es vulnerable
• OpenSSL 1.0.0, NO es vulnerable
• OpenSSL 0.9.8, NO es vulnerable
• OpenSSL 1.0.1g, NO es vulnerable (última versión estable)
• OpenSSL 1.0.2-beta2, NO es vulnerable (última versión de testing)

¿Cómo detener la fuga(de información)?

En tanto se use la versión vulnerable de OpenSSL, ésta puede ser abusada. La versión reparada de OpenSSL ha sido publicada y ahora debe ser instalada. Los proveedores y distribuidores de sistemas operativos, proveedores de appliances, proveedores de software independientes deben adoptar el arreglo y notificar a sus usuarios. Los proveedores de servicio y usuarios deben instalar el arreglo en cuanto esté disponible para sus sistemas operativos, equipos de red y software que utilicen. Los profesionales de seguridad están alertando de las implicancias prácticas mencionando por ejemplo que muchos sitios web protegidos con SSL "esos con direcciones https://" padecen de esta vulnerabilidad. Indican que a los efectos prácticos uno debiera considerar que su usuario y contraseña ha sido comprometido. También conexiones VPN que usen SSL, mensajería instantanea que utilicen la librería OpenSSL están afectados hasta tanto se actualice el software con la versión reparada de OpenSSL. Lo mismo dice que pasa con Tor:

Aunque más tarde anunciaron que fue reparado pero indican tomar medidas:

Otros ven tan grande el problema que proponen un cambio de vida:

Los sistemas operativos empiezan a anunciar las versiones reparadas:

Es mucha la información que se puede encontrar en Twitter y en http://heartbleed.com/ sobre esta vulnerabilidad y las soluciones que van llegando.

Comprobando un sitio web

Un consultor independiente de criptografía, italiano, Filippo Valsorda, preparó una página para comprobar si un servicio web es vulnerable a esta falla de seguridad #heartbleed, y asi entonces uno puede saber si puede o no confiar en que el tráfico (nuestro usuario y contraseña y otros datos) está protegido de forma apropiada, o no. Durante esta mañana en Segu-Info comprobabamos varios sitios web bancarios, de tarjetas de crédito, de registro de dominio y algún otro de Argentina con estos resultados:

• wsec01.bancogalicia.com.ar no afectado
• www.pcbanking2g.hsbc.com.ar no afectado
• www.bbvafrances.com.ar no se pudo analizar por otro inconveniente
• www.accessbanking.com.ar no se pudo analizar por otro inconveniente
• inetserv.visa.com.ar no afectado
• global.americanexpress.com no afectado
• www1.masterconsultas.com.ar no afectado
• www.bancoprovincia.bancainternet.com.ar no afectado
• hb.redlink.com.ar no afectado
• personas.supervielle.com.ar no afectado
• www.personas.santanderrio.com.ar no afectado
• ihb1.itau.com.ar no afectado
• nic.ar no afectado
• webmail.ec.gba.gov.ar no afectado
• mecontuc.gov.ar no afectado

Afortunadamente todos son seguros de acuerdo a el test de la página http://filippo.io/Heartbleed/.
No fue inicialmente así el caso para el correo Yahoo! y de Hotmail / Outlook que aparecían vulnerables, aunque al mediodía ya se reportaban como no afectados:

• All good, mail.yahoo.com seems not affected!
• All good, login.live.com seems not affected!
• Otros sitio populares como Gmail, Facebook, Twitter, Linkedin también son seguros.

Una de las cuestiones que plantea esta vulnerabilidad es la necesidad de asegurarse que las claves privadas de los certificados SSL no hayan sido comprometidas. En ese caso si no se regenera el certificado, cabe la posibilidad que un atacante pueda continuar leyendo el trafico cifrado SSL, si hubiera obtenido las claves privadas mientras la vulnerabilidad estuvo activa.

Impacto tras explotación

La información que se podría obtener sería la siguiente:

1. Claves privadas
2. Usuarios y contraseñas utilizadas en servicios vulnerables
3. Información sensible utilizada por servicios vulnerables
4. Direcciones de memoria y su contenido que podría permitir evadir mecanismos de mitigación ante exploits.

¿Qué páginas se encuentran afectadas?

Unas cuantas... y muchas.

Se ha puesto a disposición de todos un listado del TOP 1000 portales web según el ranking de ALEXA, mostrando si son vulnerables o no. El listado corresponde con el estado de dichas webs durante la tarde de ayer cuando fue confeccionada tras la ejecución de la herramienta de comprobación de manera masiva. Shodan también han publicado una lista de dispositivos vulnerables.

¿Mi servidor es vulnerable?

Rápidamente, comenzaron a publicarse herramientas que permitían tanto comprobar si un servidor es vulnerable, tanto como para obtener la información tras su explotación (aplicación en Python) o de forma masiva. Si se ejecuta esta aplicación se verá una salida como muestra la imagen, demostrando que el servidor es vulnerable. Se puede conocer qué versión se tiene instalada y si la misma es vulnerable, con el siguiente: openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe

¿Cómo lo soluciono?

Los servidores deberían ser actualizados a la versión OpenSSL 1.0.1g lanzado el 7 de abril de 2014. Se puede actualizar desde aquí: https://www.openssl.org/ En el caso que no se pueda actualizar inmediatamente, se puede recompilar OpenSSL con la opción DOPENSSL_NO_HEARTBEATS. Además, si se dispone de información sensible o crítica, se recomienda revocar todos los certificados digitales y volver a generarlos. A los clientes se recomienda cambiar todas las contraseñas de cualquier sistema o servicio crítico que suela utilizar. También debe considerar habilitar autenticación en 2 factores, que le ayudará a proteger tu cuenta incluso si su contraseña se vió comprometida.

¿Cómo se explota la vulnerabilidad?

El miércoles se implementó el módulo openssl_heartbleedde esta vulnerabilidad para Metasploit. En GitHub se encuentra el módulo preparado para descargarse y probarse.

Hay otras entradas que muestran más códigos que se pueden utilizar:

• http://filippo.io/Heartbleed/ (un test online para comprobar si se es vulnerable Heartbleed) y https://github.com/FiloSottile/Heartbleed
• http://pastebin.com/WmxzjkXJ (ssltest.py)
• https://www.ssllabs.com/ssltest/index.html (un test online para comprobar si se es vulnerable Heartblee)
• https://github.com/rapid7/metasploit-framework/pull/3206/files (módulo Metasploit)
• https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse (Nmap NSE script)
• https://github.com/titanous/heartbleeder?files=1 (POC en Go)
• https://github.com/mothran/tlslite/tree/master/scripts
• https://gist.github.com/rcvalle/10223042 (Una versión en C de @rcvalle)
• https://bitbucket.org/fb1h2s/cve-2014-0160/src (Escáner en python) y http://www.garage4hackers.com/entry.php?b=2551 (Writeup)
• https://gist.github.com/RealRancor/10140249 (Otro Nmap NSE script)
• https://www.nth-dimension.org.uk/pub/s_client-vs-cve-2014-0160.diff.txt (Parche que permite la explotación usando el cliente OpenSSL)
• https://gist.github.com/anantshri/10238615 (Modificado para facilitar la lectura)
• http://1337day.com/exploit/22114 (Exploit POC)
• https://play.google.com/store/apps/details?id=com.bblabs.heartbleedscanner (test para móviles)
• https://github.com/HackerFantastic/Public/blob/master/exploits/heartbleed.c (Exploit POC)
• https://github.com/sensepost/heartbleed-poc (Exploit POC)
• https://gist.github.com/eelsivart/10174134 (Mejora de ssltest.py)
• http://www.tenable.com/plugins/index.php?view=single&id=73404 (Plugin NASL oficial de Tenable)
• https://chrome.google.com/webstore/detail/chromebleed/eeoekjnjgppnaegdjbcafdggilajhpic (plugin Chrome de Filippo Valsorda)
• https://nextsuite.websecurify.com/apps/heartbleed/ (comprueba múltiples objetivos)
• https://lastpass.com/heartbleed/ (Prueba de exposición con características adicionales para los usuarios de LastPass)
• https://github.com/Lekensteyn/pacemaker (Explota clientes OpenSSL. Compatible con Python 2 y 3)

NMap también ha publicado un módulo para el análisis de múltiples servidores y rangos completos de direcciones IP.

1.  Instalar la última version de Nmap
2. Descarga el script https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse  a la carpeta "scripts" de Nmap (generalmente usr/local/share/nmap/scripts/)
3. Descargar la libreria https://svn.nmap.org/nmap/nselib/tls.lua a la carpeta "nselib" de Nmap (generalmente usr/local/share/nmap/nselib/)
4. Ejecutar: nmap --script-updatedb

Para comprobarlo en una URL determinada: nmap -vv -p 443 --script ssl-heartbleed dominio.com -oN resultado.txt Para comprobar un rango: nmap -vv -p 443 --script ssl-heartbleed 000.000.000-000.* -oN rango.txt

Raúl Batista de la Redacción de Segu-Info

Suscríbete a nuestro Boletín