¿Comprobar los registros para el uso de exploits de Heartbleed?

Question

¿Comprobar los registros para el uso de exploits de Heartbleed?

#1 de Lekensteyn (11 votos)

10

Según artículos tales como lo siguiente , aparentemente es posible verificar los registros de las solicitudes de latido que coincidan con las cargas útiles descritas en el exploit Heartbleed.

¿Es esto algo que cualquier operador de servidor puede verificar en sus propios registros (a nivel de servidor, cualquier distribución estándar de Linux)? Si es así, ¿qué registros deben verificarse y para qué patrón?

heartbleed logging server

pregunta Jon L. 11.04.2014 - 13:26

fuente

1 respuesta

Lea otras preguntas en las etiquetas heartbleed logging server

Estirando un hash, muchas iteraciones versus una cadena de entrada más larga Cuando el DES de fuerza bruta, ¿saber algo sobre el texto simple ayuda?

score 11 · Accepted Answer

Desde los registros de acceso de un servicio (nginx, Dovecot, etc.), no puede ver si fue afectado o no. A menos que haya capturado previamente todo el tráfico SSL, tampoco puede ver si fue atacado en el pasado.

El patrón a coincidir en la captura de un paquete es muy simple:

Se envía una solicitud maliciosa de Heartbeat.
Se devuelve una respuesta de Heartbeat demasiado larga (para versiones con errores).

Si la solicitud de Heartbeat no está cifrada (es decir, se envió antes de que se complete el protocolo de enlace), los datos en la capa de transporte (UDP, TCP o una capa adicional específica de la aplicación) son:

18       # Content Type Heartbeat 
vv vv    # TLS version (e.g. 03 01 is TLS 1.0, 03 03 is TLS 1.2)
ll ll    # Record length (length of the following data)
01       # Message type (1 = request, 2 = response)
xx xx    # Payload length
[payload]
[at least 16 bytes of padding]

Si la carga útil no es exactamente la longitud xx xx (big-endian), posiblemente fue atacado. Sería exitoso si recibes una respuesta:

18 vv vv    # Same record layer header
ll ll       # Length of following data
02
xx xx       # Same length as requested
[data of length xx xx]

Un comando de ejemplo (que requiere root) que captura todos los datos futuros de la interfaz de red eth0 hasta que se interrumpa:

tcpdump -i eth0 'tcp port 443' -w ssl.pcap

Puede usar Wireshark para investigar el archivo ssl.pcap . El filtro de visualización ssl.heartbeat_message muestra todas las solicitudes y mensajes de Heartbeats. Nota: a veces el filtro SSL no se aplica. En ese caso, haga clic con el botón derecho en un paquete, haga clic en Descodificar como ... y seleccione SSL . Como git commit 3f81af22e0116a2f83c0298de7874959b3967da2 (11 de abril de 2014), también puede usar el filtro experto ssl.heartbeat_message.payload_length.invalid para dirigirse a solicitudes de Heartbeat mal formadas (si no están encriptadas).

En cuanto a los latidos encriptados ... no es común ver los latidos del corazón, así que cuando tienes uno para las conexiones TCP, ya es sospechoso. Algunos consejos para los latidos encriptados que pueden ayudar:

Una solicitud de latido seguida de respuestas de latido gigantesco es un signo de un servidor vulnerable que fue explotado con éxito.
Una solicitud de latido no seguida por una respuesta de latido puede indicar un intento de explotar el servidor, pero el servidor está parcheado y no responde.
Una solicitud de latido seguida de una alerta cifrada puede indicar un intento de explotar el servidor, pero el servidor no ejecuta OpenSSL y rechaza la solicitud no válida.
Un gran número de latidos posteriores (incluso si es pequeño) pueden ser intentos de explotación exitosos con pequeñas longitudes de carga útil.