Esta es una pregunta canónica sobre la comprensión y la solución del problema de seguridad de Heartbleed.

¿Qué es exactamente CVE-2014-0160 AKA "Heartbleed"? ¿Cuál es la causa, qué sistemas operativos y versiones de OpenSSL son vulnerables, cuáles son los síntomas, hay algún método para detectar una explotación exitosa?

¿Cómo puedo verificar si mi sistema está afectado? ¿Cómo se puede mitigar esta vulnerabilidad? ¿Debería preocuparme que mis claves u otros datos privados se hayan visto comprometidos? ¿De qué otros efectos secundarios debería preocuparme?

Primero , antes de enloquecer, asegúrese de comprender si esta vulnerabilidad realmente se aplica a usted o no. Si tiene un servidor, pero en realidad nunca ha tenido ninguna aplicación que use TLS, entonces esto no es una cuestión de alta prioridad para que lo arregle. Si, por otro lado, alguna vez ha tenido aplicaciones habilitadas para TLS, entonces le espera un regalo. Sigue leyendo:

¿Qué es exactamente CVE-2014-0160, también conocido como "Heartbleed"?

Es un gran desastre, eso es lo que es. En resumen, se descubrió una vulnerabilidad explotable de forma remota en las versiones de OpenSSL 1.0.1 a 1.0.1f a través de las cuales un atacante puede leer ciertas partes de la memoria del sistema. Esas partes son las que contienen datos confidenciales, como claves privadas, claves previamente compartidas, contraseñas y datos corporativos de alto valor, entre otras cosas.

El error fue descubierto independientemente por Neel Mehta de Google Security (21 de marzo de 2014) y la firma finlandesa de pruebas de seguridad de TI Codenomicon (2 de abril de 2014).

¿Cual es la causa?

Bueno, código errante en OpenSSL. Aquí está el commit que introdujo la vulnerabilidad, y aquí está el commit que solucionó la vulnerabilidad. El error apareció en diciembre de 2011 y fue parcheado hoy, 7 de abril de 2014.

El error también puede verse como un síntoma de un problema mayor. Los dos problemas relacionados son (1) qué proceso existen para garantizar que el código errante no se introduzca en una base de código, y (2) por qué los protocolos y extensiones son tan complejos y difíciles de probar. El ítem (1) es un problema de gobernanza y proceso con OpenSSL y muchos otros proyectos. Muchos desarrolladores simplemente se resisten a prácticas tales como revisiones de código, análisis y escaneo. El ítem (2) se está discutiendo en el TLS WG del IETF. Ver Heartbleed / complejidad del protocolo .

¿Se insertó el código erróneo de forma maliciosa?

No especularé si esto fue realmente un error o posiblemente un poco de código introducido en nombre de un mal actor. Sin embargo, la persona que desarrolló el código para OpenSSL afirma que fue inadvertido. Vea que el hombre que introdujo una falla de seguridad grave de 'Heartbleed' niega haberlo insertado deliberadamente .

¿Qué sistemas operativos y versiones de OpenSSL son vulnerables?

Como se mencionó anteriormente, cualquier sistema operativo que esté usando, o una aplicación que esté vinculada con OpenSSL 1.0.1 a 1.0.1f.

¿Cuáles son los síntomas? ¿Hay algún método para detectar una explotación exitosa?

Esta es la parte que da miedo. Hasta donde sabemos, no hay una forma conocida de detectar si esta vulnerabilidad ha sido explotada o no. Es teóricamente posible que pronto se publiquen firmas IDS que puedan detectar este exploit, pero a partir de este escrito, no están disponibles.

Existe evidencia de que Heartbleed estaba siendo explotado activamente en la naturaleza ya en noviembre de 2013. Vea el EFF's Wild at Heart: ¿Las agencias de inteligencia utilizaron Heartbleed en noviembre de 2013? Y Bloomberg informa que la NSA había armado el exploit poco después de que se introdujera la vulnerabilidad. Ver NSA dijo para explotar Heartbleed Bug para inteligencia durante años . Sin embargo, la Comunidad de Inteligencia de los Estados Unidos niega las afirmaciones de Bloomberg. Ver IC EN EL REGISTRO .

¿Cómo puedo verificar si mi sistema está afectado?

Si mantiene OpenSSL en su sistema, simplemente puede emitir openssl version:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Si la distribución es el mantenimiento de OpenSSL, entonces es probable que no se puede determinar la versión de OpenSSL debido al regreso de parches utilizando opensslcomandos o la información del paquete (por ejemplo, apt-get, dpkg, yumo rpm). El proceso de revisión de parches utilizado por la mayoría de las distribuciones (¿todas?) Solo usa el número de versión base (por ejemplo, "1.0.1e"); y no incluye una versión de seguridad efectiva (por ejemplo, "1.0.1g").

Hay una pregunta abierta sobre Superusuario para determinar la versión de seguridad efectiva para OpenSSL y otros paquetes cuando los paquetes se remontan. Desafortunadamente, no hay respuestas útiles (aparte de consultar el sitio web de la distribución). Consulte ¿ Determinar la versión de seguridad efectiva cuando se enfrenta a Backpatching ?

Como regla general: si alguna vez instaló una de las versiones afectadas y alguna vez ejecutó programas o servicios que se vinculaban con OpenSSL para el soporte TLS, entonces es vulnerable.

¿Dónde puedo encontrar un programa para probar la vulnerabilidad?

A las pocas horas del anuncio de Heartbleed, varias personas en Internet habían publicado aplicaciones web de acceso público que supuestamente podrían usarse para verificar la presencia de esta vulnerabilidad en un servidor. Al momento de escribir este artículo, no he revisado ninguno, por lo que no publicaré más sus aplicaciones. Se pueden encontrar con relativa facilidad con la ayuda de su motor de búsqueda preferido.

¿Cómo se mitiga esta vulnerabilidad?

Actualice a una versión no vulnerable y restablezca o vuelva a proteger los datos vulnerables. Como se señaló en el sitio de Heartbleed , los pasos de respuesta apropiados son en general:

1. Parchear sistemas vulnerables.
2. Regenerar nuevas claves privadas.
3. Envíe una nueva CSR a su CA.
4. Obtenga e instale un nuevo certificado firmado.
5. Invalidar claves de sesión y cookies
6. Restablecer contraseñas y secretos compartidos
7. Revocar certificados antiguos.

Para obtener un análisis y una respuesta más detallados, consulte ¿Qué debe hacer un operador de sitio web sobre el exploit Heartbleed OpenSSL? en el intercambio de pila de seguridad.

¿Debería preocuparme que mis claves u otros datos privados se hayan visto comprometidos? ¿De qué otros efectos secundarios debería preocuparme?

Absolutamente. Los administradores de sistemas deben asumir que sus servidores que utilizan versiones vulnerables de OpenSSL están realmente comprometidos y responden en consecuencia.

Poco después de que se revelara la vulnerabilidad, Cloudfare ofreció un desafío para ver si la clave privada de un servidor podía recuperarse en la práctica. El desafío fue ganado independientemente por Fedor Indutny e Ilkka Mattila. Ver el desafío Heartbleed .

¿Dónde puedo encontrar más información?

Enlace de volcado, para aquellos que buscan más detalles:

• OpenSSL SECADV 2014047
• CVE-2014-0160
• Heartbleed
• Anuncio de Ubuntu
• Anuncio de RHEL
• Anuncio oficial de OpenSSL

Se puede encontrar una línea de tiempo bastante detallada de los eventos de divulgación en la línea de tiempo de divulgación de Heartbleed: quién sabía qué y cuándo .

Si es un programador y está interesado en varios trucos de programación, como detectar un ataque Heartbleed a través de la msg_cbdevolución de llamada de OpenSSL , consulte el Aviso de seguridad 2014047 de OpenSSL .

Una explicación simple del error, por XKCD:

Ubuntu 12.04, 12.10 y 13.10

Ubuntu ha emitido USN-2165-1 , que establece que los paquetes actualizados ahora están disponibles en los archivos. Ejecute los siguientes dos comandos para obtener la solución.

sudo apt-get update
sudo apt-get upgrade

Ubuntu 14.04

He cargado un paquete de Debian que contiene la nueva versión (1.0.1g) a un PPA que he configurado para este propósito. Estos tres comandos agregarán mi PPA a su sistema, actualizarán la lista de paquetes disponibles y actualizarán todo:

sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
sudo apt-get update
sudo apt-get upgrade

_{Nota: el PPA también proporciona paquetes para Ubuntu 12.04 y 13.10, en caso de que prefiera ejecutar la nueva versión (1.0.1g) en lugar de simplemente usar las versiones parcheadas en los archivos.}

Ubuntu 10.04

Esta es una versión LTS, la versión del servidor aún es compatible y recibe actualizaciones de seguridad. Pero la vulnerabilidad de heartbleed no afectó el paquete openssl de una instalación estándar de ubuntu 10.04, porque la versión está por debajo de 1.0.1.

La versión de escritorio ha llegado al final de su vida útil y debe actualizarse / reinstalarse.

Ubuntu 13.04 y otras versiones desactualizadas

Ubuntu 13.04 tuvo un ciclo de soporte muy corto que no puede esperar. Ya ha llegado al final de su vida útil y ya no recibe actualizaciones de seguridad. Debería haber sido actualizado durante mucho tiempo. Si todavía alguien lo está utilizando, actualícelo ahora, ya sea desde cero o puede actualizarse de forma no destructiva a 13.10 siguiendo este sencillo procedimiento: http://www.tecmint.com/upgrade-ubuntu-13-04-raring-ringtail -to-ubuntu-13-10-saucy-salamander / Después de la actualización, el sistema recibe el parche heartbleed de 13.10.

Para todas las demás versiones obsoletas de ubuntu, significa que básicamente es necesaria una nueva instalación.

Verifique que se haya aplicado el parche

Esencialmente, ejecute openssl version -ay asegúrese de que la fecha de compilación sea el 7 de abril de 2014 o posterior, pero vea más aquí .

Reiniciar

La mejor manera de asegurarse de que todos los servicios que dependen de OpenSSL se reinicien es reiniciar .

RedHat 6.5 y CentOS 6.5

Estos son vulnerables. La errata RHSA-2014-0376 de RedHat dice que hay bibliotecas parcheadas disponibles, y que cualquier persona afectada debería actualizarse lo antes posible.

En el momento de escribir este artículo, CentOS aún no tenía una versión fija, pero la publicación de Karanbir Singh en CentOS-anuncie dice que han producido una versión actualizada de openssl ( openssl-1.0.1e-16.el6_5.4.0.1tenga en cuenta los últimos cuatro dígitos que son importantes) que tiene el TLS explotable comando deshabilitado, y eso se puede aplicar de forma segura, ya que será sobrescrito por una versión fija cuando finalmente se lance.

La versión fija temporalmente no parece haber llegado a todos los espejos todavía, pero está en el repositorio principal en http://mirror.centos.org/centos/6/updates/x86_64/Packages/ (y de manera similar para i686).

Editar : como dice Iain, ahora parece haber una versión completamente parcheada para C6.5, y parece haber sido empujada alrededor de los espejos a toda prisa. Un derecho lo yum updateconsiguió para mis servidores; es openssl-1.0.1e-16.el6_5.7.

Versiones de RH6 y C6 anteriores a 6.5

Estos no son vulnerables. Según este aviso de Red Hat ,

Este problema no afectó a las versiones de openssl que se incluyen con Red Hat Enterprise Linux 5 y Red Hat Enterprise Linux 6.4 y versiones anteriores.

La publicación de Karanbir Singh en CentOS -nounce es igualmente clara sobre las versiones:

Más temprano en el día de hoy, nos enteramos de un problema grave en openssl como se envió en CentOS-6.5

Debian Wheezy

Debian ha emitido DSA-2896-1 y las bibliotecas parcheadas están disponibles aquí . Un script de shell está disponible aquí .

1. parche

El repositorio Apt-get se actualizó, por lo que ahora las bibliotecas parcheadas están disponibles a través de apt-get update && apt-get upgrade

apt-get upgrade libssl1.0.0 openssl

Alternativamente (no recomendado) los paquetes se pueden actualizar manualmente:

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

2. Reinicie el servidor / servicios

Para una mejor protección, reinicie todo el servidor o, si el servidor no puede estar fuera de línea, reinicie los servicios necesarios.

3. Verifique la versión de OpenSSL

love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  amd64            SSL shared libraries

Me gustaría señalar que las claves privadas no son los únicos activos que deben considerarse comprometidos. El error tiene el potencial de perder cualquier memoria que se ejecute en el mismo espacio de direcciones (es decir, el mismo proceso) que OpenSSL. Por lo tanto, si está ejecutando un proceso de servidor donde una versión vulnerable de OpenSSL está vinculada estática o dinámicamente, cualquier información que ese proceso haya manejado , incluidas las contraseñas, los números de tarjetas de crédito y otros datos personales, debe considerarse potencialmente comprometida.

FreeBSD 10.0 o openssl desde puertos

El equipo de seguridad de FreeBSD ha emitido un aviso sobre CVE-2014-0160 (también conocido como "Heartbleed") y: FreeBSD-SA-14: 06.openssl

1. Actualizando FreeBSD

   • Actualización de FreeBSD a través de un parche binario

     Los sistemas que ejecutan una versión de LIBERACIÓN de FreeBSD en las plataformas i386 o amd64 se pueden actualizar a través de la utilidad freebsd-update (8):

     # freebsd-update fetch
     # freebsd-update install
     

   • Actualización de FreeBSD desde las fuentes

     1. Descargue el parche relevante de la ubicación a continuación y verifique la firma PGP separada utilizando su utilidad PGP.

        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
        # gpg --verify openssl-10.patch.asc
        

     2. Ejecute los siguientes comandos como root:

        # cd /usr/src
        # patch < /path/to/patch
        

     3. Recompilar el sistema operativo

        usando buildworld e installworld como se describe en el manual de FreeBSD .

2. Actualice el puerto openssl con la versión mínima 1.0.1_10

3. Reinicie todos los demonios utilizando la biblioteca o reinicie el sistema.

4. Actúe como si su sistema se hubiera visto comprometido, vuelva a emitir todas sus claves y / o certificados SSL y la información potencialmente filtrada (consulte la respuesta más general de EEAA ).

FreeBSD 9.xy FreeBSD 8.x

Estos sistemas no son vulnerables al problema Heartbleed de forma predeterminada, ya que dependen de la versión anterior 0.9.x de la biblioteca openssl , a menos que haya instalado openssl desde los puertos (ver arriba).

Si estos sistemas no son vulnerables al problema de Heartbleed , podría ser conveniente actualizar su sistema más pronto que tarde debido a otra vulnerabilidad local (consulte FreeBSD-SA-14: 06.openssl y la sección "FreeBSD 10.0" en la parte superior):

Un atacante local podría espiar un proceso de firma y recuperar la clave de firma. [CVE-2014-0076]

Nota :

El aviso original de Heartbleed enumera FreeBSD 8.4 y 9.1 como potencialmente vulnerable. Esto no es cierto debido a la falta de Heartbeat Extension (la biblioteca de OpenBSD de FreeBSD predeterminada es la versión 0.9.x).

Me resultó casi imposible determinar las versiones de SSL en uso en varios de los dispositivos con los que trabajo. Aunque técnicamente no es mitigación, la identificación de hosts actualmente vulnerables estaba en la parte superior de mi lista.

Creé una pequeña máquina virtual que realizará comprobaciones contra hosts y puertos arbitrarios utilizando el módulo de prueba de FiloSottile . A primera vista, el código se ve bien.

El lanzamiento de la VM completada está aquí . Está en formato VMX.

Palabras de advertencia

Este script y VM solo mostrarán el estado actual de sus sistemas. Es completamente posible que en algún momento en el pasado sus sistemas estuvieran en un estado vulnerable y pudieran haber sido abusados.

Algo que aparece aquí es definitivamente una alta prioridad para solucionarlo, pero no lo libera de la aplicación de actualizaciones y el cambio de todas sus claves.

Amazon Linux (distribución de Linux utilizada en Amazon EC2)

https://aws.amazon.com/amazon-linux-ami/security-bulletins/ALAS-2014-320/

Descripción general del problema: se encontró una comprobación de límites faltantes en la forma en que OpenSSL manejó los paquetes de extensión de latido TLS. Esta falla podría usarse para revelar hasta 64k de memoria de un cliente o servidor conectado.

Versiones afectadas: Cualquier AMI de Amazon Linux en el que está instalado openssl 1.0.1, que es cualquier AMI de Amazon Linux 2013.03 o posterior, y cualquier AMI de Amazon Linux que se haya actualizado a 2013.03 o posterior. OpenSSL se instala de forma predeterminada en la AMI de Amazon Linux.

Paquetes afectados: openssl

Corrección del problema: Ejecute yum update openssl para actualizar su sistema. Una vez que se instala el nuevo paquete, es necesario que reinicie manualmente todos los servicios que utilizan openssl o que reinicie su instancia. Si bien el nuevo paquete todavía se llama openssl-1.0.1e, contiene la solución para CVE-2014-0160.

Nuevos paquetes: i686:

openssl-1.0.1e-37.66.amzn1.i686

openssl-static-1.0.1e-37.66.amzn1.i686

openssl-perl-1.0.1e-37.66.amzn1.i686

openssl-devel-1.0.1e-37.66.amzn1.i686

openssl-debuginfo-1.0.1e-37.66.amzn1.i686

x86_64:

openssl-devel-1.0.1e-37.66.amzn1.x86_64

openssl-1.0.1e-37.66.amzn1.x86_64

openssl-debuginfo-1.0.1e-37.66.amzn1.x86_64

openssl-perl-1.0.1e-37.66.amzn1.x86_64

openssl-static-1.0.1e-37.66.amzn1.x86_64