¿Cómo me recupero del error Heartbleed en OpenSSL?

CVE-2014-0160 aka Heartbleed es una vulnerabilidad en OpenSSL. Se ve aterrador.

¿Cómo determino si estoy afectado?

Si estoy afectado, ¿qué debo hacer? Aparentemente, actualizar no es suficiente.

Esta vulnerabilidad tiene un alto impacto potencial porque si su sistema ha sido atacado, seguirá siendo vulnerable incluso después de parchear, y los ataques pueden no haber dejado rastros en los registros. Existe la posibilidad de que si parches rápidamente y no eres un objetivo de alto perfil, nadie habrá podido atacarte, pero es difícil estar seguro.

¿Soy vulnerable?

La versión con errores de OpenSSL

El software con errores es la biblioteca OpenSSL 1.0.1 hasta 1.0.1f , y OpenSSL 1.0.2 hasta beta1. Las versiones anteriores (0.9.x, 1.0.0) y las versiones donde se ha solucionado el error (1.0.1g en adelante, 1.0.2 beta 2 en adelante) no se ven afectadas. 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.

Puede usar la herramienta de línea de comandos openssl version -apara mostrar el número de versión de OpenSSL. Tenga en cuenta que algunas distribuciones portan la corrección de errores a versiones anteriores; si el registro de cambios de su paquete menciona la corrección de errores de Heartbleed, está bien, incluso si ve una versión como 1.0.1f. Si openssl version -amenciona una fecha de compilación (no la fecha en la primera línea) del 07/04/2014 alrededor de la tarde UTC o posterior, debería estar bien. Tenga en cuenta que el paquete OpenSSL puede tener 1.0.0su nombre a pesar de que la versión es 1.0.1 (se 1.0.0refiere a la compatibilidad binaria).

Aplicaciones afectadas

La explotación se realiza a través de una aplicación que utiliza la biblioteca OpenSSL para implementar conexiones SSL . Muchas aplicaciones usan OpenSSL para otros servicios criptográficos, y eso está bien: el error está en la implementación de una característica particular del protocolo SSL, el "latido del corazón".

Es posible que desee verificar qué programas están vinculados con la biblioteca en su sistema. En los sistemas que usan dpkg y apt (Debian, Ubuntu, Mint, ...), el siguiente comando enumera los paquetes instalados que no sean las bibliotecas que usan libssl1.0.0(el paquete afectado):

apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii  lib'

Si ejecuta algún software de servidor que está en esta lista y escucha conexiones SSL, probablemente estés afectado. Esto se refiere a servidores web, servidores de correo electrónico, servidores VPN, etc. Sabrá que ha habilitado SSL porque tuvo que generar un certificado, ya sea enviando una solicitud de firma de certificado a una autoridad de certificación o haciendo su propia firma certificado. (Es posible que algún procedimiento de instalación haya generado un certificado autofirmado sin que lo note, pero eso generalmente se hace solo para servidores internos, no para servidores expuestos a Internet). 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,

El software del cliente se ve afectado solo si lo usó para conectarse a un servidor malicioso. Entonces, si se conectó a su proveedor de correo electrónico utilizando IMAPS, no necesita preocuparse (a menos que el proveedor haya sido atacado, pero si ese es el caso, debería informarle), pero si navegaba por sitios web aleatorios con un navegador vulnerable, es posible que necesite preocuparse. Hasta ahora parece que la vulnerabilidad no estaba siendo explotada antes de ser descubierta, por lo que solo debe preocuparse si se conectó a servidores maliciosos desde el 8/04/2014.

Los siguientes programas no se ven afectados porque no usan OpenSSL para implementar SSL:

• SSH (el protocolo no es SSL)
• Cromo / Cromo ( usa NSS )
• Firefox (usa NSS) (al menos con Firefox 27 en Ubuntu 12.04, ¿pero no con todas las compilaciones?

¿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 a la vez. 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. Potencialmente, esto permite al atacante recuperar cualquier información que haya estado en la memoria del proceso del servidor, incluidas claves, contraseñas, cookies, etc.

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.

El error también permite que cualquier servidor al que esté conectado su cliente SSL recupere aproximadamente 64kB de memoria del cliente a la vez. Esto es preocupante si utilizó un cliente vulnerable para manipular datos confidenciales y luego se conectó a un servidor no confiable con el mismo cliente. Por lo tanto, los escenarios de ataque en este lado son significativamente menos probables que en el lado del servidor.

Tenga en cuenta que para las distribuciones típicas, no hay impacto de seguridad en la distribución de paquetes ya que la integridad de los paquetes se basa en firmas GPG, no en el transporte SSL.

¿Cómo soluciono la vulnerabilidad?

Remediación de servidores expuestos

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 paquete de la biblioteca OpenSSL . Todas las distribuciones deben tener una solución ahora (ya sea con 1.0.1g, o con un parche que corrige el error sin cambiar el número de versión). Si compiló desde la fuente, actualice a 1.0.1 go superior. Asegúrese de que todos los servidores afectados se reinicien.
   En Linux, puede verificar si los procesos potencialmente afectados todavía se están ejecutando congrep 'libssl.*(deleted)' /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 conectar su servidor .

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

Remediación en otros casos.

Los servidores que solo escuchan en localhost o en una intranet solo deben considerarse expuestos si los usuarios que no son de confianza pueden conectarse a ellos.

Con los clientes, solo hay escenarios raros en los que el error puede haber sido explotado: una explotación requeriría que utilizaras el mismo proceso de cliente para

1. manipular datos confidenciales (por ejemplo, contraseñas, certificados de clientes, ...);
2. y luego, en el mismo proceso, se conecta a un servidor malicioso a través de SSL.

Entonces, por ejemplo, un cliente de correo electrónico que solo usa para conectarse a su proveedor de correo (no completamente no confiable) no es una preocupación (no es un servidor malicioso). Ejecutar wget para descargar un archivo no es una preocupación (no se filtran datos confidenciales).

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 cliente están en peligro.

Referencias

• The Heartbleed Bug (por uno de los dos equipos que descubrieron independientemente el error)
• ¿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 probar si es vulnerable, vaya aquí: http://filippo.io/Heartbleed/

Si encuentra que es vulnerable, actualice openssly reinicie su servidor web.

No hay forma de recuperarse de este error. Guarde todos los registros, serán necesarios en caso de que alguien se haya dado cuenta de que la vulnerabilidad existía antes de que se anunciara