¿Qué clientes han demostrado ser vulnerables a Heartbleed?

Question

¿Qué clientes han demostrado ser vulnerables a Heartbleed?

#1 de Lekensteyn (66 votos)
#2 de HD Moore (26 votos)
#3 de Brad (8 votos)
#4 de SPRBRN (0 votos)

73

En varias páginas , se reitera que los atacantes pueden obtener hasta 64 K de memoria del servidor o cliente que usa una implementación OpenSSL vulnerable a Heartbleed (CVE-2014-0160). Hay docenas de < a href="https://gist.github.com/takeshixx/10107280"> herramientas que revelan el error en las aplicaciones del servidor.

Hasta ahora no he visto una sola herramienta que explote el error en las aplicaciones cliente. ¿Es tan difícil explotar el error en los clientes? ¿Son los clientes realmente vulnerables o no?

tls heartbleed

pregunta Lekensteyn 09.04.2014 - 16:08

fuente

4 respuestas

26

Escribí un módulo Metasploit para probar este ~~, actualmente se está revisando, pero debería golpear la rama maestra relativamente pronto~~ . La primera versión se fusiona en la rama maestra en este punto.

~~A diferencia del ataque del lado del servidor, tiene que implementar la mayor parte de TLS, ya que la respuesta del latido del corazón se cifra contra la clave de sesión SSL.~~ Probé con wget, curl y la línea de comandos openssl. Un dato interesante es que, en contra de wget y openssl (1), el ataque tiene éxito independientemente de la validación del certificado. El binario curl requiere -k o un certificado válido para mantener la sesión abierta el tiempo suficiente para que el ataque funcione. Contra estas pruebas relativamente sintéticas, podría filtrar de manera confiable la clave de sesión TLS (AES-128-CBC), pero esto no proporciona mucho ya que el servidor conoce la misma clave durante el protocolo de enlace.

EDIT1 : parece que el código del marcapasos logra esto sin hacer el apretón de manos TLS completo (¡aún mejor!). Me interesaría conocer los resultados de las pruebas que puedan tener las personas entre las implementaciones. IOW, ¿el marcapasos tiene éxito en los casos en que el cliente se desconectaría debido a un certificado autofirmado?

EDIT2 : el método que utiliza @Lekensteyn en el marcapasos (enviar un latido después del saludo del servidor) es un mejor enfoque porque la validación de CA no es un problema. Envié un nuevo Metasploit PR que se establece de manera predeterminada en este modo y conserva la ruta del código de negociación TLS usando la opción NEGOTIATE_TLS (establezca NEGOTIATE_TLS verdadero para el modo antiguo). ¡Apoyos a @Lekensteyn!


respondido por el HD Moore 09.04.2014 - 21:54
fuente

8

Es posible explotar el error en los clientes. Este probador se puede usar para distribuir una URL "malvada" a clientes arbitrarios y ver si se muerden o no. Encontré los 3 mejores 100 sitios web (no los nombraré aquí) que obtienen URL utilizando clientes que eran vulnerables a partir del 2014-04-09.


respondido por el Brad 10.04.2014 - 03:06
fuente

0

Si tiene un dispositivo Android, puede instalar una de las aplicaciones Heartbleed que prueban la vulnerabilidad, como esta:

enlace

Probé esto en dos teléfonos con Android, uno con 4.3 y otro con 4.4, y ambos reportan ser vulnerables, pero para OpenSSL no se usa, por lo que todo está bien ...

Así que todo está bien. Genial entonces, ninguna aplicación está usando OpenSSL. ¿Pero qué pasa si instalo una aplicación que la usa? ¿Seré notificado? Supongo que no!

El teléfono 4.4 es nuevo de Sony, y después de usarlo por primera vez, descargó una actualización del sistema, ¡pero supongo que esto no es lo suficientemente importante como para arreglarlo.


respondido por el SPRBRN 26.05.2014 - 14:42
fuente

Lea otras preguntas en las etiquetas tls heartbleed

Convenciendo a mi gerente de usar sales Desbordamientos de pila - Derrotar a Canaries, ASLR, DEP, NX

score 66 · Accepted Answer

De hecho, sí , los clientes son vulnerables. Hasta ahora, la atención se ha centrado en los servidores, ya que están mucho más abiertos a la explotación. (Casi) todos pueden conectarse a un servidor HTTP / SMTP / ... público.

Este blog describe cómo funciona realmente el error (menciona dtls_process_heartbeat() , pero tls_process_heartbeat() se ve afectado de la misma manera). Esta función se usa tanto para clientes como para aplicaciones de servidor, por lo que, de hecho, los clientes también deberían ser vulnerables

.

De acuerdo con RFC 6520, los latidos no deben enviarse durante los apretones de manos. En la práctica, OpenSSL acepta latidos del corazón justo después de enviar ServerHello (esto es lo que hace ssltest.py de Jared Stafford). Tras realizar más pruebas, descubrí que los servidores pueden abusar de los clientes enviando un Heartbeat justo después de también enviando el ServerHello. Dispara el mismo error.

Puede encontrar una prueba de concepto en mi repositorio en enlace . Desde su README:


Los siguientes clientes han sido probados contra 1.0.1f y se han filtrado   Memoria antes del apretón de manos:


MariaDB 5.5.36

wget 1.15 (pierde memoria de conexiones anteriores y estado propio)

curl 7.36.0 (https, FTP / IMAP / POP3 / SMTP con --ftp-ssl)

git 1.9.1 (clone / push probado, fugas no mucho)

nginx 1.4.7 (en modo proxy, pierde memoria de solicitudes anteriores)

enlaces 2.8 (¡se filtran contenidos de visitas anteriores!)

KDE 4.12.4 (kioclient, Dolphin, https y ftps probados con kde4-ftps-kio)

Exim 4.82 (SMTP saliente)


Se ha demostrado que se pueden devolver 64 KiB de memoria (65535 bytes). También se ha demostrado que los clientes ( wget , KDE Dolphin, ...) pueden filtrar datos, como las solicitudes anteriores que posiblemente contengan contraseñas.