Apretón de manos de 4 vías Wireshark WPA

13

Desde esta página wiki :

WPA y WPA2 usan claves derivadas de un protocolo de enlace EAPOL para cifrar el tráfico. A menos que los cuatro paquetes de protocolo de enlace estén presentes para la sesión que está intentando descifrar, Wireshark no podrá descifrar el tráfico. Puede usar el filtro de pantalla eapol para localizar paquetes EAPOL en su captura.

He notado que el descifrado también funciona con (1, 2, 4), pero no con (1, 2, 3). Hasta donde yo sé, los dos primeros paquetes son suficientes, al menos para lo que concierne al tráfico de unidifusión. ¿Alguien puede explicar exactamente cómo Wireshark trata eso, en otras palabras, por qué solo funciona la secuencia anterior, dado que el cuarto paquete es solo un reconocimiento? Además, ¿está garantizado que (1, 2, 4) siempre funcionará cuando (1, 2, 3, 4) funcione?

Caso de prueba

Este es el apretón de manos comprimido (1, 2, 4) y un ARPpaquete cifrado (SSID:, SSIDcontraseña :) passworden la base64codificación:

H4sICEarjU8AA2hhbmRzaGFrZS5jYXAAu3J400ImBhYGGPj / n4GhHkhfXNHr37KQgWEqAwQzMAgx
6HkAKbFWzgUMhxgZGDiYrjIwKGUqcW5g4Ldd3rcFQn5IXbWKGaiso4 + RmSH + H0MngwLUZMarj4Rn
S8vInf5yfO7mgrMyr9g / Jpa9XVbRdaxH58v1fO3vDCQDkCNv7mFgWMsAwXBHMoEceQ3kSMZbDFDn
ITk1gBnJkeX / GDkRjmyccfus4BKl75HC2cnW1eXrjExNf66uYz + VGLl + snrF7j2EnHQy3JjDKPb9
3fOd9zT0TmofYZC4K8YQ8IkR6JaAT0zIJMjxtWaMmCEMdvwNnI5PYEYJYSTHM5EegqhggYbFhgsJ
9gJXy42PMx9JzYKEcFkcG0MJULYE2ZEGrZwHIMnASwc1GSw4mmH1JCCNQYEF7C7tjasVT + 0 / J3LP
gie59HFL + 5RDIdmZ8rGMEldN5s668eb / tp8vQ + 7OrT9jPj / B7425QIGJI3Pft72dLxav8BefvcGU
7 + kfABxJX + SjAgAA

Decodificar con:

$ base64 -d | gunzip > handshake.cap

Ejecute tsharkpara ver si descifra correctamente el ARPpaquete:

$ tshark -r handshake.cap -o wlan.enable_decryption:TRUE -o wlan.wep_key1:wpa-pwd:password:SSID

Debería imprimir:

  1 0.000000 D-Link_a7: 8e: b4 -> HonHaiPr_22: 09: b0 Clave EAPOL
  2 0.006997 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Tecla EAPOL
  3 0.038137 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Tecla EAPOL
  4 0.376050 ZyxelCom_68: 3a: e4 -> HonHaiPr_22: 09: b0 ARP 192.168.1.1 está en 00: a0: c5: 68: 3a: e4
wireshark wpa decryption Ciro
fuente
No puede ... debe estar descifrando porque tiene los cuatro, o está conectado a la red wifi y eso es descifrar los paquetes
Paul
Estoy (obviamente) hablando de paquetes capturados en modo RFMON.
cYrus
@Paul: he editado la pregunta; ¿Puede usted responder?
cYrus
Ojalá pudiera. Si sigue la secuencia EAPOL, el cliente tiene el PTK después del primer paquete (se pasa el anonce). El AP conoce el PTK después del segundo paquete (snonce). Si observa estos dos y conoce los MAC, que por supuesto lo hace, y el ssid + psk, entonces esto debería ser todo lo que necesita. El tercer paquete es solo GTK para transmisión y multidifusión, y el cuarto es solo un ACK. Si está descifrando unicast (que es la respuesta de arp), los dos primeros paquetes deberían ser suficientes. No puedo evitar pensar que me falta algo, ya que todo dice que necesitas los cuatro.
Paul
¿Llegaste más lejos con esto?
Paul

Respuestas:

1

Los intercambios EAPOL también se utilizan para renovar las claves temporales. Las nuevas claves se instalan en el Suplicante después de que envía 4/4, y se instalan en el Autenticador cuando recibe 4/4 [1]. Si Wireshark debe manejar la reimpresión correctamente, solo debe usar las teclas después de leer el paquete 4/4 en el marco, porque los paquetes pueden seguir fluyendo durante la reimpresión (incluso en caso de que no lo hagan, debido al almacenamiento en búfer)

Para el primer 4WHS, no es posible esperar 4/4, pero es perfectamente comprensible que solo fueran flojos para implementarlo. 3/4 sigue siendo necesario ya que contiene claves de grupo (incluso si no está interesado en ellas, pero sepa que no verá las solicitudes ARP del AP o un cliente para el que no tiene parte de su 4WHS) y claves de administración. También puede omitir 3/4, pero no tiene confirmación de que el intercambio se realizó correctamente, ya que 3/4 se utiliza para verificar que el Autenticador conoce el PMK.

[1] Tenga en cuenta que con el esquema actual, si se pierde el mensaje 4/4, entonces el solicitante comenzó a usar la nueva clave, y el autenticador aún usa la clave anterior, y reenviar 3/4 cifrado con la clave anterior no ayudará. . Este problema, entre muchos otros con WPA2, se aborda en el último estándar 802.11 2012 manteniendo dos claves en paralelo.

BatchyX
fuente
1

Toda la información necesaria para construir el PTK se intercambia en los pasos 1 y 2. Esto debería ser suficiente para descifrar el tráfico de unidifusión.

Sin el paso 3, no tendrá el GTK, por lo que no será posible descifrar la multidifusión / transmisión.

El paso 4 no es realmente necesario para descifrar el tráfico de captura, pero si no hay un paso 4, el cliente / AP no comenzará a usar el cifrado. Wireshark puede desconectarse de esto antes de que también intente descifrar los datos.

Aprender
fuente
0

Bueno, obviamente la documentación de WireShark está mal. :-)

Saliendo de la documentación aquí :

  • Después de EAPOL 1 y 2, ambos lados conocen la clave temporal que se utilizará para descifrar el tráfico.
  • El tercer mensaje es una prueba de que ambas partes conocen la clave temporal e indica que el Autenticador (la estación base) está listo para comenzar a usar la clave temporal.
  • El cuarto mensaje activa el cambio de la configuración PMK antes de EAPOL a la clave temporal derivada en EAPOL

Entonces con eso, tiene sentido. WireShark no necesita el mensaje 3 para nada. Conoce las claves después de los mensajes 1 y 2, pero espera comenzar a usarlas para descifrar el tráfico hasta que reciba el mensaje 4.

No hay garantías para nada en la vida, especialmente el comportamiento del software libre, pero es una apuesta razonable que no habrá un requisito para que el mensaje 3 esté presente para que WireShark descifre la sesión.

Viejo pro
fuente
Me parece que ese paquete 4 no es necesaria , ya sea a la derecha - que sólo está diseñado para esperar.
Paul
@Paul, es como decir que "reanudar" no es necesario después de una "pausa".
Old Pro
@OldPro, no estoy seguro de que esperar 4 ° sea una buena idea, los paquetes capturados tienden a perderse, especialmente cuando viajan por el aire.
cYrus
@cYrus, esperar 4 es esencial, ya que las claves de cifrado deben cambiarse simultáneamente en ambos lados. Si el cliente no recibe 4, no sabe que la base recibió 3. Si el cliente no recibe 4, envía 3 nuevamente (lo que desencadena un reenvío de 4) hasta que recibe 4 o deja de intentarlo para crear la conexión
Old Pro
@OldPro: no estoy hablando del protocolo. Ambas partes pueden recibir todos los paquetes, pero pueden ser descartados o no capturados por la entidad que captura pasivamente el tráfico.
cYrus
0

Esto no explica por qué, pero citando el airdecap-ng documentación de todos modos,

WPA/WPA2 Requirements

The capture file must contain a valid four-way handshake. For this purpose having (packets 2 and 3) or (packets 3 and 4) will work correctly. In fact, you don't truly need all four handshake packets.
sybind
fuente