¿Cómo parchear el error Heartbleed (CVE-2014-0160) en OpenSSL?

152

A partir de hoy, se ha encontrado un error en OpenSSL que afecta a las versiones a 1.0.1través de 1.0.1f(inclusive) y 1.0.2-beta.

Desde Ubuntu 12.04, todos somos vulnerables a este error. Para parchear esta vulnerabilidad, los usuarios afectados deben actualizar a OpenSSL 1.0.1g.

¿Cómo puede cada usuario afectado aplicar esta actualización ahora ?

security openssl Lucio
fuente
¿Tienes una versión afectada de openssl?
Braiam
Tengo la versión parcheada 1.0.1-4ubuntu5.12 y reinicié el servicio apache, pero las pruebas filippo.io/Heartbleed en mi sitio todavía dicen que soy vulnerable ¿Alguna idea de por qué?
1
@ Mat No sé qué prueba ese sitio, pero tal vez detecta que estás usando una clave antigua. Como la clave puede haberse filtrado, debe regenerarla.
Gilles
1
Realmente no desea actualizar OpenSSL a nuevas versiones mayoristas, eso es un dolor increíble. Mucho más fácil es simplemente instalar el paquete actualizado que parchea el tema: ubuntu.com/usn/usn-2165-1
sarnold
¿Has reiniciado tus servicios después de actualizar?
Axel

Respuestas:

141

Las actualizaciones de seguridad están disponibles para 12.04, 12.10, 13.10 y 14.04, consulte el Aviso de seguridad de Ubuntu USN-2165-1 .

Primero, debe aplicar las actualizaciones de seguridad disponibles, por ejemplo ejecutando

sudo apt-get update
sudo apt-get upgrade

desde la línea de comando.

No olvide reiniciar los servicios (HTTP, SMTP, etc.) que usan la versión de OpenSSL afectada, de lo contrario aún es vulnerable. Ver también Heartbleed: ¿Qué es y cuáles son las opciones para mitigarlo? en Serverfault.com.

El siguiente comando muestra (después de una actualización) todos los servicios que deben reiniciarse:

sudo find /proc -maxdepth 2 -name maps -exec grep -HE '/libssl\.so.* \(deleted\)' {} \; | cut -d/ -f3 | sort -u | xargs --no-run-if-empty ps uwwp

Después de eso, debe regenerar todas las claves SSL del servidor , luego evaluar si sus claves pueden haberse filtrado, en cuyo caso los atacantes pueden haber recuperado información confidencial de sus servidores.

Florian Diesch
fuente
23
No estoy seguro de que esto funcione en Ubuntu 12.04.4 LTS. Después de la actualización completa, openssl versionda OpenSSL 1.0.1 14 Mar 2012. Esa no es la versión parcheada, ¿verdad? ¿O lo estoy leyendo mal?
Paul Cantrell
77
¿Qué hacer con Ubuntu 13.04? No hay openssl actualizado disponible :-(
Frodik
20
En Ubuntu 12.04 incluso la versión fija de OpenSSL muestra la versión 1.0.1 14 Mar 2012. Lea la respuesta de crimi para averiguar si su instalación incluye la solución.
dan
77
Gracias @dan! Resumiendo la respuesta de @ crimi aquí: si corres dpkg -l | grep ' openssl 'y obtienes, 1.0.1-4ubuntu5.12entonces estás listo para irte.
Paul Cantrell
20
Parchear y reiniciar no es suficiente. Necesita regenerar claves y evaluar si sus claves se han filtrado, así como otro material confidencial. Consulte, por ejemplo, ¿Heartbleed significa nuevos certificados para cada servidor SSL?
Gilles
71

El error se conoce como Heartbleed .

¿Soy vulnerable?

En general, se ve afectado si ejecuta algún servidor para el que generó una clave SSL en algún momento. La mayoría de los usuarios finales no se ven afectados (directamente); al menos Firefox y Chrome no usan OpenSSL. SSH no se ve afectado. La distribución de los paquetes de Ubuntu no se ve afectada (se basa en firmas GPG).

Usted es vulnerable si ejecuta cualquier tipo de servidor que utiliza las versiones de OpenSSL 1.0–1.0.1f (excepto, por supuesto, las versiones que se han parcheado desde que se descubrió el error). Las versiones de Ubuntu afectadas son 11.10 oneiric hasta 14.04 versiones preliminares de confianza. Es un error de implementación, no una falla en el protocolo, por lo que solo los programas que usan la biblioteca OpenSSL se ven afectados. Si tiene un programa vinculado con la versión anterior 0.9.x de OpenSSL, no se ve afectado. Solo se ven afectados los programas que usan la biblioteca OpenSSL para implementar el protocolo SSL; los programas que usan OpenSSL para otras cosas no se ven afectados.

Si ejecutó un servidor vulnerable expuesto a Internet, considérelo comprometido a menos que sus registros no muestren conexión desde el anuncio del 07/04/2014. (Esto supone que la vulnerabilidad no fue explotada antes de su anuncio). Si su servidor solo estuvo expuesto internamente, si necesita cambiar las claves dependerá de qué otras medidas de seguridad estén implementadas.

¿Cuál es el impacto?

El error permite que cualquier cliente que pueda conectarse a su servidor SSL recupere aproximadamente 64kB de memoria del servidor. El cliente no necesita ser autenticado de ninguna manera. Al repetir el ataque, el cliente puede volcar diferentes partes de la memoria en intentos sucesivos.

Una de las piezas críticas de datos que el atacante puede recuperar es la clave privada SSL del servidor. Con estos datos, el atacante puede hacerse pasar por su servidor.

¿Cómo me recupero en un servidor?

  1. Ponga todos los servidores afectados fuera de línea. Mientras se estén ejecutando, están potencialmente filtrando datos críticos.

  2. Actualice el libssl1.0.0paquete y asegúrese de reiniciar todos los servidores afectados.
    Puede verificar si los procesos afectados todavía se están ejecutando con `` grep '' libssl. (eliminado) '/ proc / / maps`

  3. Generar nuevas claves . Esto es necesario porque el error podría haber permitido que un atacante obtuviera la antigua clave privada. Siga el mismo procedimiento que usó inicialmente.

    • Si utiliza certificados firmados por una autoridad de certificación, envíe sus nuevas claves públicas a su CA. Cuando obtenga el nuevo certificado, instálelo en su servidor.
    • Si utiliza certificados autofirmados, instálelo en su servidor.
    • De cualquier manera, retire las claves y los certificados antiguos (pero no los elimine, solo asegúrese de que ya no se usen).

  4. Ahora que tiene nuevas claves no comprometidas, puede volver a poner su servidor en línea .

  5. Revocar los viejos certificados.

  6. Evaluación de daños : cualquier información que haya estado en la memoria de un proceso que sirve conexiones SSL puede haberse filtrado. Esto puede incluir contraseñas de usuario y otros datos confidenciales. Debe evaluar cuáles pueden haber sido estos datos.

    • Si está ejecutando un servicio que permite la autenticación con contraseña, las contraseñas de los usuarios que se conectaron desde un poco antes de que se anunciara la vulnerabilidad deberían considerarse comprometidas. (Un poco antes, porque la contraseña puede haber permanecido sin usar en la memoria por un tiempo). Revise sus registros y cambie las contraseñas de cualquier usuario afectado.
    • También invalide todas las cookies de sesión, ya que pueden haber sido comprometidas.
    • Los certificados de cliente no están comprometidos.
    • Cualquier información que se haya intercambiado desde un poco antes de la vulnerabilidad puede haber permanecido en la memoria del servidor y, por lo tanto, puede haberse filtrado a un atacante.
    • Si alguien ha grabado una conexión SSL antigua y ha recuperado las claves de su servidor, ahora puede descifrar su transcripción. (A menos que se asegure PFS , si no lo sabe, no lo fue).

¿Cómo me recupero en un cliente?

Solo hay algunas situaciones en las que las aplicaciones cliente se ven afectadas. El problema en el lado del servidor es que cualquiera puede conectarse a un servidor y explotar el error. Para explotar a un cliente, se deben cumplir tres condiciones:

  • El programa cliente utilizó una versión con errores de la biblioteca OpenSSL para implementar el protocolo SSL.
  • El cliente conectado a un servidor malicioso. (Por ejemplo, si se conectó a un proveedor de correo electrónico, esto no es una preocupación). Esto tuvo que suceder después de que el propietario del servidor se dio cuenta de la vulnerabilidad, por lo que presumiblemente después del 2014-04-07.
  • El proceso del cliente tenía datos confidenciales en la memoria que no se compartían con el servidor. (Entonces, si solo corrió wgetpara descargar un archivo, no había datos que filtrar).

Si lo hizo entre la noche UTC 2014-04-07 y la actualización de su biblioteca OpenSSL, considere que los datos que estaban en la memoria del proceso del cliente están en peligro.

Referencias

Gilles
fuente
44
No creo que "solo el lado del servidor de las conexiones SSL / TLS se vea afectado" es cierto. openssl.org/news/secadv_20140407.txt dice que puede revelar secretos del cliente o del servidor. ubuntu.com/usn/usn-2165-1 está de acuerdo. Las posibilidades de que esté utilizando certificados de cliente mientras se conecta a un servidor malicioso son pequeñas, pero existe la posibilidad.
brazalete
@armb Haces un buen punto. Ni siquiera importa si se utilizan certificados de cliente, la pérdida de datos no está relacionada con el uso de certificados. He solicitado la ayuda de profesionales .
Gilles
Los certificados de cliente son el caso en el que se filtrarían las claves privadas, pero sí, las contraseñas, las cookies de autorización, etc. podrían filtrarse de todos modos. Sin embargo, con un cliente basado en OpenSSL como curl o wget en el uso típico, no tendría secretos para otros sitios en la memoria mientras se conecta a un servidor malicioso, por lo que en ese caso creo que la única fuga sería si le proporcionara secretos al cliente anticipando darlos a un sitio legítimo, y Heartbleed los filtró durante el apretón de manos antes de que la verificación del certificado revele que no está conectado al sitio correcto.
brazalete
1
@Gilles Quizás le interesen las respuestas a ¿Qué clientes han demostrado ser vulnerables a Heartbleed? . Logré ganar memoria "interesante" en nginx (modo proxy), wget, enlaces y otros.
Lekensteyn
1
@ MuhamedHuseinbašić El paquete opensslcontiene herramientas de línea de comandos. No es utilizado por aplicaciones que usan la biblioteca OpenSSL para implementar el protocolo SSL (como Apache). Pero solo debe aplicar las actualizaciones de seguridad de la distribución.
Gilles
40

Para ver qué versión de OpenSSL está instalada en Ubuntu, ejecute:

dpkg -l | grep openssl

Si ve el siguiente resultado de la versión, se debe incluir el parche para CVE-2014-0160.

ii  openssl      1.0.1-4ubuntu5.12      Secure Socket Layer (SSL)...

Mirando https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12 , muestra qué tipo de errores se corrigen:

...
 SECURITY UPDATE: memory disclosure in TLS heartbeat extension
    - debian/patches/CVE-2014-0160.patch: use correct lengths in
      ssl/d1_both.c, ssl/t1_lib.c.
    - CVE-2014-0160
 -- Marc Deslauriers <email address hidden>   Mon, 07 Apr 2014 15:45:14 -0400
...
crimi
fuente
2
He actualizado y obtengo la versión 5.12 pero esta herramienta todavía me dice que soy vulnerable filippo.io/Heartbleed Thoughts?
toxaq
3
He probado nuestros servidores actualizados en este lado y me dijo que no estoy afectado. ¿Reinició su sistema, o al menos está seguro de que todos los procesos necesarios se han reiniciado?
crimi
3
Después de actualizar el OPENSSL, todo lo que tuve que hacer fue reiniciar el servicio apache, pero agraciado no ayudó . Tuve que ir y reiniciar usandosudo service apache2 restart
Tom Hert
1
Acabo de encontrar la causa de mi vulnerabilidad: tenía instalado mod-spdy-beta. Después de eliminarlo y reiniciar Apache, todas las pruebas son verdes ahora.
Andreas Roth
3
La actualización opensslno repara aplicaciones como Apache, Nginx o postfix. Tienes que actualizarlos libssl1.0.0y reiniciarlos como se explica en otras publicaciones.
tnj
17

Si sus repositorios apt-get no contienen ninguna versión OpenSSL 1.0.1g precompilada , descargue las fuentes del sitio web oficial y compílelo.

Debajo de la línea de comando única para compilar e instalar la última versión de openssl.

curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install

Reemplace el viejo archivo binario openssl por el nuevo a través de un enlace simbólico.

sudo ln -sf /usr/local/ssl/bin/openssl `which openssl`

Todos ustedes son buenos!

# openssl version should return
openssl version
OpenSSL 1.0.1g 7 Apr 2014

Cf esta publicación de blog .

NB: Como se indicó en la publicación del blog, esta solución no solucionará "el servidor Nginx y Apache que debe recompilarse con fuentes openSSL 1.0.1g".

Quentin Rousseau
fuente
2
Como generalmente, Ubuntu no proporciona la nueva versión ascendente, pero parcheó las versiones de todas las versiones compatibles para mantener los cambios al mínimo.
Florian Diesch
1
Nota: Asegúrese de reiniciar su servidor después de actualizar OpenSSL. Apache y Nginx recogieron la nueva lib y se cerró la vulnerabilidad.
dAngelov
66
Heh, ahora que me tomo el tiempo de leer los detalles de esta publicación, estoy aún más horrorizado: descargar un tarball de algún lugar aleatorio de Internet, desempacar y ejecutar partes de él como root es solo un comportamiento imprudente. Sería un poco mejor si las firmas de tarball se descargaran y verificaran, pero asegurarse de validar que las firmas fueron firmadas con la clave correcta es en sí una pregunta difícil. Las distribuciones ya se han esforzado por garantizar la procedencia segura de tarballs y parches. Gracias.
sarnold
2
podría ser una buena idea compilar desde la fuente AHORA, e instalar una nueva más tarde desde apt, de esa manera es más seguro que sin esperar en versiones anteriores de ubuntu de todos modos solo mis dos centavos
nwgat
2
@sarnold openssl.org no parece un lugar aleatorio para descargar la fuente de openssl. Canonical debería hacer que esto sea innecesario, pero openssl.org debería ser el flujo ascendente autorizado para trabajar.
Rustavore
12

Para aquellos que no desean hacer una actualización del paquete en todo el servidor. Leí un montón de estas guías hoy y apt-get upgrade openssl=== apt-get upgradeesto aplicará todas las correcciones de seguridad requeridas por su máquina. Maravilloso, a menos que se apoye explícitamente en una versión antigua del paquete en alguna parte.

Esta es la acción mínima requerida en Ubuntu 12.04 LTS con Apache 2:

  • Vaya a esta dirección y demuestre que tiene la vulnerabilidad. Debe usar la DIRECCIÓN EXTERNA DIRECTA DE SU SERVIDOR WEB. Si utiliza un equilibrador de carga (por ejemplo, ELB), es posible que no se contacte con su servidor web directamente.

  • Ejecute el siguiente liner para actualizar paquetes y reiniciar. Sí, vi a todas las guías diciendo que debería tener una marca de tiempo posterior al 4 de abril de 2014, este no parece ser mi caso.

    apt-get update && apt-get install openssl libssl1.0.0 && /etc/init.d/apache2 restart

  • Asegúrese de tener instaladas las versiones de paquete adecuadas y verifique la vulnerabilidad en su servidor web una vez más.

Los paquetes de claves son los siguientes, determiné esta información usando el comando a continuación y luego edité la información (no necesita saber mucho sobre el estado de mis máquinas). 

$ dpkg -l | grep ssl

ii  libssl-dev                       1.0.1-4ubuntu5.12          SSL development libraries, header files and documentation
ii  libssl1.0.0                      1.0.1-4ubuntu5.12          SSL shared libraries
ii  openssl                          1.0.1-4ubuntu5.12          Secure Socket Layer (SSL)* binary and related cryptographic tools

1.0.1-4ubuntu5.12NO debe contener la vulnerabilidad. Asegúrese de que este sea el caso nuevamente yendo al sitio web a continuación y probando su servidor web.

http://filippo.io/Heartbleed/

Adrian
fuente
2
El uso de un sitio externo para probar una vulnerabilidad en un servidor parece ser un enfoque incorrecto para mí.
Rinzwind
Los scripts de prueba de vulnerabilidad externa se están volviendo cada vez más comunes en estos días. Hace exactamente lo que hace un script interno, la conexión se inicia desde un servidor web externo. Puede buscar sitios como WhiteHatSecurity.com para ver un ejemplo de un programa que inicia todas las conexiones de forma remota. Hay casos en los que esto no funcionaría, por ejemplo, las pruebas de vulnerabilidad de red, pero para probar un servidor web orientado hacia adelante (que en general será un servidor SSL), esto es casi ideal.
Adrian
¿Por qué instalar el paquete si se está actualizando?
Braiam
1
apt-get install openssl libssl1.0.0Lo hice por mí. Ejecutar openssl version -aahora muestra:built on: Mon Apr 7 20:33:29 UTC 2014
topher
"Los scripts de prueba de vulnerabilidad externa se están volviendo cada vez más comunes en estos días", lo que abre la posibilidad de que ese sitio externo abuse de mi sistema: todo lo que necesitan saber es que falla y piratea mi sistema antes de que lo corrija. No, esta no es la forma correcta. (y sí, alojo mis propios sitios con apache y openssl).
Rinzwind
11

Noté muchos comentaristas aquí que necesitan ayuda con urgencia. Están siguiendo las instrucciones, y actualizando y reiniciando, y siguen siendo vulnerables cuando usan algunos de los sitios web de prueba.

Debe verificar para asegurarse de que no tiene paquetes en espera como libssl.

:~$ sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  libssl-dev (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  libssl1.0.0 (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  linux-image-virtual (3.2.0.31.34 => 3.2.0.60.71)
  linux-virtual (3.2.0.31.34 => 3.2.0.60.71)
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

Para actualizar esos apt-mark unhold libssl1.0.0(por ejemplo). A continuación, actualice: apt-get upgrade -V. Luego, reinicie los servicios afectados.

dominó
fuente