Pregunta Heartbleed: ¿Qué es y cuáles son las opciones para mitigarlo?


Esto es un Pregunta canónica sobre entender y remediar el 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 un exploit exitoso?

¿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 hayan sido comprometidos? ¿Qué otros efectos secundarios debo tener en cuenta?


204
2018-04-08 00:26


origen


Mitigación para Heartbleed involucra Más que solo nuevas claves. (Enlace a mi respuesta en Information Security StackExchange) - scuzzy-delta
Te escucho, pero creo que EEAA cubrió bastante ampliamente eso a continuación. - MadHatter
Estoy de acuerdo: es una gran respuesta, pero heartbleed.com hace un gran esfuerzo para señalar que existen consideraciones más allá de los nuevos pares de claves, como forzar cambios de contraseña y la invalidación de sesión. - scuzzy-delta
@ scuzzy-delta - buen punto. He hecho mi respuesta CW ahora, así que siéntase libre de editarla / mejorarla con esa información. - EEAA
El mejor ejemplo de lo que es - (como era de esperar) XKCD: xkcd.com/1354 - Wayne Werner


Respuestas:


primeroAntes de enloquecer, asegúrese de comprender si esta vulnerabilidad se aplica realmente a usted o no. Si tiene un servidor, pero nunca ha tenido aplicaciones que usen TLS, entonces esto no es una cosa de alta prioridad para que lo arregle. Si, por otro lado, tu Alguna vez he tenido Aplicaciones habilitadas para TLS, bueno, entonces te espera una sorpresa. Sigue leyendo

¿Qué es exactamente CVE-2014-0160 alias "Heartbleed"?

Es un gran lío de fricking, eso es lo que es. En resumen, se descubrió una vulnerabilidad de explotación remota en las versiones 1.0.1 a 1.0.1f de OpenSSL a través de las cuales un atacante puede leer ciertas partes de la memoria del sistema. Las partes son aquellas 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 de forma independiente 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í es el compromiso que introdujo la vulnerabilidad, y aquí Es el compromiso que reparó la vulnerabilidad. El error apareció en diciembre de 2011 y fue reparado 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 se implementa para garantizar que el código errante no se introduzca en una base de código y (2) por qué los protocolos y las extensiones son tan complejos y difíciles de probar. El artículo (1) es un problema de gobierno 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 artículo (2) se está discutiendo en el TLS WG del IETF. Ver Heartbleed / protocolo de complejidad.

¿Se insertó maliciosamente el código errante?

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. Ver El hombre que presentó una grave falla de seguridad 'Heartbleed' niega que la insertara 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 contra OpenSSL 1.0.1 a 1.0.1f.

¿Cuáles son los síntomas? ¿Existen métodos para detectar un exploit exitoso?

Esta es la parte de miedo. Por lo que sabemos, no hay forma conocida de detectar si esta vulnerabilidad ha sido explotada o no. En teoría, es posible que las firmas de IDS se publiquen pronto y que puedan detectar esta vulnerabilidad, pero en el momento en que se escriben, no están disponibles.

Existe evidencia de que Heartbleed estaba siendo explotado activamente en la naturaleza a partir de noviembre de 2013. Vea las EFF Wild at Heart: ¿Las agencias de inteligencia utilizaron Heartbleed en noviembre de 2013? Y Bloomberg informa que la NSA había armado la vulnerabilidad poco después de que se introdujera la vulnerabilidad. Ver La NSA dice que explotará el insecto de Heartbleed por 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 está manteniendo OpenSSL en su sistema, entonces simplemente puede emitir openssl version:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Si la distribución mantiene OpenSSL, entonces es probable que no pueda determinar la versión de OpenSSL debido a la aplicación de parches hacia atrás usando openssl comando o la información del paquete (por ejemplo, apt-get, dpkg, yum o rpm). El proceso de actualización de parches usado por la mayoría de las distribuciones (¿todas?) Solo usa el número de versión base (por ejemplo, "1.0.1e"); y lo hace no incluir una versión de seguridad efectiva (por ejemplo, "1.0.1g").

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

Como regla general: si alguna vez ha instalado una de las versiones afectadas y alguna vez ha ejecutado programas o servicios vinculados a OpenSSL para el soporte de 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 publicaron aplicaciones web accesibles al público que supuestamente podrían usarse para verificar la presencia de esta vulnerabilidad en un servidor. En el momento de redactar este documento, no he revisado ninguno, por lo que no daré a conocer 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ñala en la Heartbleed sitio, pasos de respuesta apropiados son ampliamente:

  1. Parches de sistemas vulnerables.
  2. Regenera nuevas claves privadas.
  3. Enviar nuevo CSR a su CA.
  4. Obtener e instalar nuevo certificado firmado.
  5. Invalidar claves de sesión y cookies
  6. Restablecer contraseñas y secretos compartidos
  7. Revocar certificados antiguos.

Para un análisis más detallado y respuesta, ver ¿Qué debe hacer un operador de sitio web sobre la explotación de Heartbleed OpenSSL?en el Security Stack Exchange.

¿Debería preocuparme que mis claves u otros datos privados hayan sido   ¿comprometida? ¿Qué otros efectos secundarios debo tener en cuenta?

Absolutamente. Los administradores de sistemas necesitan asumir que sus servidores que usaban 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 podría recuperarse en la práctica. El desafío fue ganado independientemente por Fedor Indutny e Ilkka Mattila. Ver El desafío de Heartbleed.

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

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


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


Si eres programador y estás interesado en varios trucos de programación, como detectar un ataque de Heartbleed a través de OpenSSL msg_cb devolución de llamada, luego ver OpenSSL's Aviso de Seguridad 2014047.


118
2018-04-08 04:23



+1 para CERRAR. ABAJO. TU. SERVIDORES. * - Si hace ALGO en que SSL sea realmente importante, apáguelo hasta que solucione el problema. Además, no te olvides de instalar nuevos certificados (con nuevas llaves) después de parchear sus servidores, reusar sus llaves antiguas (que pueden haber sido comprometidas) anula todo el propósito de parchear la vulnerabilidad ... - voretaq7
ADEMÁS - reinicie cualquier servicio que enlace a las bibliotecas de OpenSSL. Actualizar OpenSSL sin reiniciar tus demonios es tan bueno como no actualizarlo en absoluto. - EEAA
De hecho, después de cualquier tipo de parche importante (como OpenSSL), considero que es una buena regla reiniciar la máquina para asegurarse de que no se pierda nada. - voretaq7
Uno de los evaluadores ha sido de código abierto: github.com/FiloSottile/Heartbleed - Riking
@EEAA, "apagar sus servidores" no significa que tenga que desconectar la alimentación. Significa apagar (o reconfigurar para deshabilitar apache ssl / tls), o cualquier servicio que esté haciendo el servicio. - psusi


Una explicación simple del error, por XKCD:

XKCD 1354


42
2018-04-08 07:28





Ubuntu 12.04, 12.10 y 13.10

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

sudo apt-get update
sudo apt-get upgrade

Ubuntu 14.04

He cargado un paquete Debian que contiene la nueva versión (1.0.1g) en 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 usar las versiones parcheadas en los archivos.

Ubuntu 10.04

Esta es una versión LTS, la versión del servidor todavía es compatible y recibe actualizaciones de seguridad. Pero la vulnerabilidad del corazón no afectó al 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 tal vez no esperes. Ya ha llegado al final de su vida útil y ya no recibe actualizaciones de seguridad. Debería haber sido actualizado por mucho tiempo. Si todavía alguien lo está utilizando, actualícelo ahora, ya sea desde cero o se puede actualizar 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 de Heartbleed de 13.10.

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

Verifique que el parche fue aplicado

Esencialmente correr openssl version -a y asegúrese de que la fecha de construcció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 reinician es reiniciar.


36
2018-04-08 10:37



No puedo hablar por otras versiones, pero parece que hay un parche disponible (12.04). Si bien no puedo decir con certeza que esto solucione la vulnerabilidad, al menos se compiló después de la confirmación relevante (Mon Apr 7 20:31:55 UTC 2014). - Calrion
@Calrion: ¿Un parche para OpenSSL o el paquete Debian para OpenSSL? OpenSSL ya se ha corregido y se ha publicado una nueva versión. - Nathan Osman
¿Qué pasará con las conexiones existentes mientras se está actualizando openssl? serán dejados caer? - pdeva
Eso depende del servidor web que esté utilizando y de cómo se actualice. Dicho esto, no me preocuparía por eliminar las conexiones existentes, ya que están utilizando la versión vulnerable. - Nathan Osman
14.04 ha recibido un parche. - Seth


RedHat 6.5 y CentOS 6.5

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

Al momento de escribir este artículo, CentOS aún no tenía una versión fija, pero Publicación de Karanbir Singh a CentOS-anuncio dice que han producido una versión actualizada de openssl (openssl-1.0.1e-16.el6_5.4.0.1, tenga en cuenta los últimos cuatro dígitos que son importantes) que tienen deshabilitado el comando TLS explotable, y que se pueden aplicar de manera segura ya que se sobrescribirá con una versión fija cuando finalmente se libere.

La versión temporalmente arreglada 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 que se ha empujado alrededor de los espejos a toda prisa. Una recta yum update lo tengo para mis servidores; sus openssl-1.0.1e-16.el6_5.7.

Versiones de RH6 y C6 anteriores a 6.5

Estos no son vulnerables. De acuerdo a este aviso de Red Hat,

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

Publicación de Karanbir Singh a CentOS-anuncio Es igualmente claro sobre el versionado:

A primera hora de hoy, nos informaron de una grave   problema en openssl como enviado en CentOS-6.5


14
2018-04-08 13:07



No es lists.centos.org/pipermail/centos-announce/2014-April/… ¿El lanzamiento de la corrección? - Iain


Debian Wheezy

Debian ha emitido DSA-2896-1 y las bibliotecas parcheadas son disponible aquí. Un script de shell es disponible aquí.

1. parche

Apt-get repositorio 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 pueden actualizarse 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. Reiniciar servidor / servicios

Para una mejor protección, reinicie todo el servidor o si el servidor no puede estar desconectado, reinicie los servicios necesarios.

3. Comprobar 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

13
2018-04-08 11:23



Si está recibiendo actualizaciones de wheezy/security entonces serás bueno con apt-get update && apt-get upgrade. O, use un administrador de paquetes interactivo para actualizar solo los paquetes openssl, libssl1.0.0, libssl1.0.0-dbg y libssl-dev (como instalado en su sistema). - α CVn
el uso de apt-get no soluciona el problema por mí, aún muestra OpenSSL 1.0.1e 11 de febrero de 2013 - user568829
Gracias @ michael-kjorling, no estaba disponible cuando hice esto, pero es la forma más segura y correcta de actualizar. - jacksoncage
@ user568829 después de aplicar el parche, la versión openssl aún se mostrará OpenSSL 1.0.1e 11 Feb 2013 Como el parche se llama 1.0.1e-2. Puedes consultar con dpkg -l openssl y debería mostrar la versión 1.0.1e-2+deb7u6 - jacksoncage
Yo sugeriría reiniciar el host después de actualizar OpenSSL, no porque sea estrictamente necesario sino por la tranquilidad de que al menos todo lo que carga dinámicamente las bibliotecas OpenSSL está usando la nueva versión. (Otro enlace estático es otro asunto). Dicho esto, reconozco que algunos servidores no pueden reiniciarse fácilmente en todas las situaciones en las que el reinicio de un servicio sea aceptable. - α CVn


Me gustaría señalar que las claves privadas no son los únicos activos que deben considerarse comprometidos. El error tiene el potencial de fugas alguna memoria que se ejecuta 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 de forma estática o dinámica, Cualquier información que ese proceso haya manejado alguna vez., incluyendo contraseñas, números de tarjetas de crédito y otros datos personales, deben considerarse potencialmente comprometidos.


9
2018-04-08 20:23





FreeBSD 10.0 o openssl de los puertos

los 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

    • Actualizando FreeBSD a través de un parche binario

      Sistemas que ejecutan un Versión de lanzamiento de FreeBSD en el i386 o amd64 Las plataformas se pueden actualizar a través de la utilidad freebsd-update (8):

      # freebsd-update fetch
      # freebsd-update install
      
    • Actualizando FreeBSD desde las fuentes

      1. Descargue el parche relevante de la ubicación a continuación y verifique la Desprenda la firma PGP 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. Ejecuta los siguientes comandos como root:

        # cd /usr/src
        # patch < /path/to/patch
        
      3. Recompila el sistema operativo.

        utilizando mundo de construcción y mundo de instalación como se describe en el Manual de FreeBSD.

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

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

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

FreeBSD 9.xy FreeBSD 8.x

Estos sistemas son No vulnerable al Heartbleed emitir de forma predeterminada, ya que se basa en la versión 0.9.x más antigua del openssl biblioteca, a no ser que tu instalaste openssl  desde los puertos (ver arriba).

Si estos sistemas no son vulnerables a la Heartbleed problema, puede ser conveniente actualizar su sistema más pronto que tarde debido a otro local vulnerabilidad (ver FreeBSD-SA-14: 06.openssl y la sección "FreeBSD 10.0" arriba):

Un atacante local podría detener un proceso de firma y recuperarse   La clave de firma de ella. [CVE-2014-0076]

Nota:

El original Heartbleed La lista de recomendaciones de FreeBSD 8.4 y 9.1 es potencialmente vulnerable. Esto no es cierto debido a la falta de Extensión del latido del corazón (la biblioteca por defecto de FreeBSD openssl es la versión 0.9.x).


9
2018-04-11 08:03





Encontré casi imposible determinar las versiones de SSL en uso en varios de los dispositivos con los que trabajo. Aunque técnicamente no es una mitigación, el hecho de poder identificar a los hosts actualmente vulnerables se encontraba en la parte superior de mi lista.

Preparé una máquina virtual pequeña que realizará comprobaciones contra hosts y puertos arbitrarios utilizando Módulo de prueba de FiloSottile.. A primera vista el código parece correcto.

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

Palabras de advertencia

Este script y VM solamente Muestra el estado actual de tus sistemas. Es totalmente posible que en algún momento en el pasado, sus sistemas estuvieran en un estado vulnerable y pudieran haber sido objeto de abuso.

Algo que aparece aquí es definitivamente una alta prioridad para arreglar, pero lo hace no Descárguese para aplicar actualizaciones y cambiar todas las claves.


3



Acabo de recibir un correo electrónico de Snapt, el suyo. BOLO (Estar en la búsqueda) ! - Jacob


Amazon Linux (distro de Linux usado en Amazon EC2)

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

Resumen de la cuestión: Se encontró una verificación de los límites faltantes en la forma en que OpenSSL maneja los paquetes de extensión de latido de 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 la que se instale 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 de problemas: 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 están usando openssl o que reinicie su instancia. Si bien el nuevo paquete aún 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

2