Heartbleed: ¿se ven afectados los servicios que no sean HTTPS?

65

La vulnerabilidad 'heartbleed' de OpenSSL ( CVE-2014-0160 ) afecta a los servidores web que sirven HTTPS. Otros servicios también usan OpenSSL. ¿Son estos servicios también vulnerables a la fuga de datos similar a un heartbleed?

Estoy pensando en particular en

  • sshd
  • SMTP seguro, IMAP, etc. - palomar, exim y postfix
  • Servidores VPN - openvpn y amigos

todo lo cual, al menos en mis sistemas, está vinculado a las bibliotecas OpenSSL.

security  openssl  heartbleed 
— Flup
fuente
Solución para Ubuntu: apt-get update && apt-get install openssl libssl1.0.0 && service nginx restart; luego,
— vuelva a
Use esta herramienta para detectar los hosts vulnerables: github.com/titanous/heartbleeder
— Homer6
1
apt-get updatedebería ser suficiente para Ubuntu ahora sin degradar, el parche apareció en el repositorio principal anoche.
— Jason C
10
La actualización de apt-get NO es suficiente. la actualización solo muestra los últimos cambios, se aplicará apt-get UPGRADE luego de la actualización.
— sjakubowski
1
Estoy seguro de que eso es lo que @JasonC quiso decir, pero +1 por dejarlo explícitamente claro.
— Craig

Respuestas:

40

Cualquier servicio que use OpenSSL para su implementación de TLS es potencialmente vulnerable; Esta es una debilidad en la biblioteca de criptografía subyacente, no en cómo se presenta a través de un servidor web o un paquete de servidor de correo electrónico. Usted debe considerar todos los servicios vinculados vulnerables a la fuga de datos , al menos .

Como estoy seguro de que es consciente, es muy posible encadenar ataques juntos. Incluso en los ataques más simples es perfectamente posible, por ejemplo, usar Heartbleed para comprometer SSL, leer credenciales de correo web, usar credenciales de correo web para obtener acceso a otros sistemas con un rápido "Estimado servicio de asistencia, ¿puede darme una nueva contraseña para $ foo, CEO de amor " .

Hay más información y enlaces en The Heartbleed Bug , y en otra pregunta mantenida por una falla de servidor, Heartbleed: ¿Qué es y cuáles son las opciones para mitigarlo? .

— Rob Moir
fuente
3
"Esta es una debilidad en el sistema subyacente, no en cómo se presenta a través de un sistema de nivel superior como SSL / TLS" - No, eso está mal. Es una debilidad en la implementación de la extensión de latidos TLS. Si nunca usa TLS, está a salvo. Sin embargo, estoy de acuerdo con su conclusión de que debe tener mucho cuidado en su análisis de lo que podría verse afectado por los ataques encadenados.
— Perseidas
66
@ Perseids tiene razón, por supuesto, estaba tratando de encontrar una manera fácil de entender de decir que las personas no son seguras porque están ejecutando esta versión del servidor web X o esa versión del servidor SMTP Y. Estoy haciendo una edición con suerte mejorará las cosas, así que gracias por señalarlo.
— Rob Moir
35

Parece que tus ssh-keys están a salvo:

Vale la pena señalar que OpenSSH no se ve afectado por el error OpenSSL. Si bien OpenSSH usa openssl para algunas funciones de generación de claves, no usa el protocolo TLS (y en particular la extensión de latido TLS que ataca). Por lo tanto, no hay necesidad de preocuparse por el compromiso de SSH, aunque sigue siendo una buena idea actualizar openssl a 1.0.1go 1.0.2-beta2 (pero no tiene que preocuparse por reemplazar los pares de claves SSH). - dr jimbob Hace 6 horas

Ver: https://security.stackexchange.com/questions/55076/what-should-one-do-about-the-heartbleed-openssl-exploit

— simme
fuente
¿No se ve afectado indirectamente como lo indica @RobM? Alguien lee la contraseña de root de la memoria usando la vulnerabilidad Heartbleed, obtiene cualquier acceso que no sea SSH al sistema y luego roba el material SSH.
— Thomas Weller
1
No puede leer CUALQUIER 64k de memoria con este error, solo 64k cerca de donde se almacena el paquete entrante. Desafortunadamente, muchas cosas tienden a almacenarse allí, como solicitudes HTTP descifradas con contraseñas de texto sin formato, claves privadas e imágenes de gatitos.
— larsr
3

Sí, esos servicios pueden verse comprometidos si confían en OpenSSL

OpenSSL se usa para proteger, por ejemplo, servidores de correo electrónico (protocolos SMTP, POP e IMAP), servidores de chat (protocolo XMPP), redes privadas virtuales (VPN SSL), dispositivos de red y una amplia variedad de software del lado del cliente.

Para una redacción más detallada sobre las vulnerabilidades, los sistemas operativos afectados, etc., puede consultar http://heartbleed.com/

— Peter
fuente
3

Cualquier cosa que se vincule libssl.sopuede verse afectada. Debe reiniciar cualquier servicio que se vincule con OpenSSL después de haber actualizado.

# lsof +c 0 | grep -w DEL | awk '1 { print $1 ": " $NF }' | grep libssl | sort -u
bacula-fd: /usr/lib/libssl.so.1.0.0
php-fpm: /usr/lib/libssl.so.1.0.0
php-fpm: /usr/lib/php/modules/openssl.so
python2: /usr/lib/libssl.so.1.0.0
python2: /usr/lib/python2.7/lib-dynload/_ssl.so
python: /usr/lib/libssl.so.1.0.0
ruby-timer-thr: /usr/lib/libssl.so.1.0.0
ruby: /usr/lib/libssl.so.1.0.0

Cortesía de Anatol Pomozov de la lista de correo de Arch Linux .

— Nowaker
fuente
2
Cualquier cosa que se vincule con libssl y use TLS. Openssh usa openssl pero no usa TLS, por lo que no se ve afectado.
— StasM
2
@StasM Por eso escribí puede verse afectado , no afectado . Además, el servidor OpenSSH NO se vincula en absoluto con OpenSSL. Las utilidades como ssh-keygen sí, pero el servidor OpenSSH no las usa . Lo cual es claramente visible en la salida de lsof que proporcioné: OpenSSH no aparece allí, aunque se está ejecutando en el servidor.
— Nowaker
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.