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

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 ?

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.

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

• The Heartbleed Bug (por uno de los dos equipos que descubrieron el error de forma independiente)
• ¿Cómo funciona exactamente la explotación del latido del corazón OpenSSL TLS (Heartbleed)?
• ¿Heartbleed significa nuevos certificados para cada servidor SSL?
• Heartbleed: ¿Qué es y cuáles son las opciones para mitigarlo?

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

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".

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/

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.