Hay más para considerar que solo nuevos certificados (o, más bien, nuevos pares de claves) para cada servidor afectado. También significa:

• Aplicar parches a los sistemas afectados a OpenSSL 1.0.1g
• Revocación de los antiguos par de llaves que fueron reemplazados
• Cambiando todas las contraseñas
• Invalidar todas las claves de sesión y cookies
• Evaluar el contenido real manejado por los servidores vulnerables que podrían haberse filtrado y reaccionar en consecuencia.
• Evaluar cualquier otra información que pueda haber sido revelada, como direcciones de memoria y medidas de seguridad

Neel Mehta (el ingeniero de seguridad de Google que informó el error ) ha twitteado :

  

Los patrones de asignación del montón hacen que la exposición de la clave privada sea improbable para #heartbleed #dontpanic.

Tomas Rzepka (probablemente de la firma de seguridad sueca Certezza ) respondido con lo que tuvieron que hacer para recuperar las claves:

  

Podemos extraer la clave privada con éxito en FreeBSD después de   reiniciando apache y haciendo la primera solicitud con ssltest.py

El robo de clave privada también se ha demostrado en Desafío CloudFlare .

Y el usuario de Twitter makomk intervino en con :

  

Lo he recuperado de Apache en Gentoo como un factor primordial en   binario, pero su demostración es mucho más clara ... Tiene una tasa de éxito baja,   más intentos en la misma conexión no ayudan, reconectando puede,   reiniciar probablemente no lo hará ... Alguien con una explotación decente   habilidades probablemente podrían mejorar la fiabilidad. Realmente no estoy tratando   que duro.

Resumí los puntos anteriores de heartbleed.com (el énfasis es mío):

  

¿Qué es el material de clave principal filtrado y cómo recuperarlo?

     

Estas son las joyas de la corona, las propias claves de cifrado . Filtrado   las claves secretas permiten al atacante descifrar cualquier tráfico pasado y futuro   A los servicios protegidos y suplantar el servicio a voluntad. Alguna   Protección dada por el cifrado y las firmas en el X.509.   Los certificados pueden ser anulados. La recuperación de esta fuga requiere   parcheando la vulnerabilidad, revocación de las claves comprometidas y   Reedición y redistribución de nuevas claves. Incluso haciendo todo esto todavía   dejar cualquier tráfico interceptado por el atacante en el pasado todavía   vulnerable al descifrado. Todo esto tiene que ser hecho por los dueños de la   servicios.

     

¿Qué es el material clave secundario filtrado y cómo recuperarlo?

     

Estas son, por ejemplo, las credenciales de usuario (nombres de usuario y   contraseñas) utilizadas en los servicios vulnerables. Recuperación de estas fugas.   Requiere que los propietarios del servicio primero restauren la confianza en el servicio.   De acuerdo con los pasos descritos anteriormente. Después de esto los usuarios pueden comenzar   cambiando sus contraseñas y posibles claves de cifrado de acuerdo con la   Las instrucciones de los propietarios de los servicios que han sido   comprometida. Todas las claves de sesión y las cookies de sesión deben ser invalidadas   y considerado comprometido.

     

¿Qué es el contenido protegido filtrado y cómo recuperarlo?

     

Este es el contenido real manejado por los servicios vulnerables . Eso   Pueden ser detalles personales o financieros, comunicación privada como   Correos electrónicos o mensajes instantáneos, documentos o cualquier cosa vista que valga la pena.   Protección mediante encriptación. Sólo los propietarios de los servicios podrán   estimar la probabilidad de lo que se ha filtrado y deben notificar   sus usuarios en consecuencia. Lo más importante es devolver la confianza a   el material de la clave primaria y secundaria como se describe anteriormente. Solo esto   permite el uso seguro de los servicios comprometidos en el futuro.

     

¿Qué es la garantía filtrada y cómo recuperarla?

     

Las garantías filtradas son otros detalles que se han expuesto a la   atacante en el contenido de la memoria filtrada. Estos pueden contener técnicas   Detalles tales como direcciones de memoria y medidas de seguridad tales como   Canarios utilizados para proteger contra los ataques de desbordamiento. Estos tienen solo   valor contemporáneo y perderá su valor para el atacante cuando   OpenSSL se ha actualizado a una versión fija.

Copiado directamente desde sitio de OpenSSL

Advertencia de seguridad de OpenSSL [07 de abril de 2014]

saturación de lectura de latido de TLS (CVE-2014-0160)

Una comprobación de límites faltantes en el manejo de la extensión de latido de TLS puede ser utilizado para revelar hasta 64k de memoria a un cliente o servidor conectado.

Solo se ven afectadas las versiones 1.0.1 y 1.0.2-beta de OpenSSL, incluidas 1.0.1f y 1.0.2-beta1.

Gracias a Neel Mehta de Google Security por descubrir este error y por Adam Langley y Bodo Moeller para preparando el arreglo.

Los usuarios afectados deben actualizar a OpenSSL 1.0.1g. Los usuarios no pueden inmediatamente la actualización puede recompilar alternativamente OpenSSL con -DOPENSSL_NO_HEARTBEATS.

1.0.2 se solucionará en 1.0.2-beta2.

• Compruebe si está utilizando las versiones mencionadas de OpenSSL, si es así, aplíquelo a 1.0.1g (al compilarlo desde source y envolver el paquete con, por ejemplo, FPM ).

• (Adición por atk) Luego, reemplace sus certificados expuestos y revóquelos.

• (Addition by dr.jimbob) Vale la pena señalar que OpenSSH no se ve afectado por el error de OpenSSL. Mientras OpenSSH usa openssl para algunas funciones de generación de claves, no usa el protocolo TLS (y, en particular, la extensión del latido del corazón TLS que ataques de corazón). Por lo tanto, no hay necesidad de preocuparse por el hecho de que SSH esté en peligro, aunque aún es una buena idea actualizar openssl a 1.0.1g o 1.0.2-beta2 (pero no tiene que preocuparse por reemplazar los pares de llaves SSH).

  • (OrangeDog): @drjimbob a menos que sus claves SSH estén en la memoria de un proceso que está utilizando el TLS de OpenSSL. Es poco probable pero posible.

• (Adición de Deer Hunter): a juzgar por los intentos activos informados en DMZ , lo mejor ahora es DETENER EL SERVIDOR FRIKKIN LO ANTES POSIBLE . Se secuestran las sesiones, se filtran las contraseñas y se revelan datos comerciales confidenciales.

• (Un bit adicional cortesía de EFF.org ): "Para llegar a una conclusión más firme sobre la historia de Heartbleed, sería mejor para la comunidad de redes tratar de replicar los hallazgos de Koeman. Cualquier operador de red que tenga registros extensos de tráfico de capa TLS puede verificar "latidos cardíacos maliciosos, que normalmente tienen una carga TCP de 18 03 02 00 03 01 40 00 o 18 03 01 00 03 01 40 00 , aunque el 0x4000 al final puede ser reemplazado por números más bajos, especialmente en implementaciones que intentan leer varios contenedores de piezas malloc". En pocas palabras, si mantiene registros detallados de TLS (no es probable para la mayoría de los operadores), verifique los intentos de explotación anteriores (y comparta lo que tiene).

Preguntas y respuestas relacionadas sobre A en ServerFault:

enlace

enlace

enlace

enlace

Un resumen bien escrito en AskUbuntu: enlace

Una completa Q & A en Unix & Linux SE: enlace

Si, por casualidad, ejecuta un servidor en Mac OS X: enlace

Recuperando la clave SSL privada usando el sangrado del corazón: enlace Sí, es posible!

[editado]

Hice una herramienta para verificar el estado de su SSL y ver si el latido está habilitado y es vulnerable. Herramienta en: enlace

Hay otro en enlace

Si eres vulnerable, actualiza tus paquetes OpenSSL & ¡Renueva tus certificados!

Tenga en cuenta que si está utilizando un proveedor basado en la nube o una red de distribución de contenido, y son vulnerables, el contenido con fugas de su sitio web se combinará con el contenido de todos los demás sitios web que utilicen este proveedor. Acabo de acabo de ver que con Incapsula , donde el contenido de un sitio web bancario se filtró a lo largo del sitio web de criptomoneda. Se han arreglado ahora, afortunadamente.

Jspenguin escribió una herramienta fuera de línea para verificar si un servidor tiene la falla. Descárguelo, audítelo y ejecútelo.

También escribí ssl-heartbleed-check.pl (también una herramienta fuera de línea) para comprobar si OpenSSL utiliza. Su pila de Perl (que en * n * x es a menudo la openssl utilizada por todo el sistema) se ve afectada. Esto puede ayudarlo a determinar si está afectado en el lado del cliente.

Nmap 6.45 incluye una secuencia de comandos ssl-heartbleed . ssl-heartbleed.nse también puede ser se utiliza junto con nmap ≥6.25 .