☰

Caso de prueba

tag-icon • tag-icon wireshark wpa decryption
Caso de prueba

Deesta página wiki:

WPA y WPA2 utilizan claves derivadas de un protocolo de enlace EAPOL para cifrar el tráfico. A menos quelos cuatroSi hay paquetes de protocolo de enlace presentes para la sesión que está intentando descifrar, Wireshark no podrá descifrar el tráfico. Puede utilizar el filtro de visualización 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 en lo que respecta al tráfico de unidifusión. ¿Puede alguien explicar exactamente cómo aborda Wireshark esto? 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 protocolo de enlace comprimido con gzip (1, 2, 4) y un ARPpaquete cifrado (SSID:, SSIDcontraseña password:) en 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 Clave EAPOL
  3 0.038137 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 Clave 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

Respuesta1

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 recodificación de claves correctamente, solo debe usar las claves después de leer el paquete 4/4 en el marco, porque es posible que los paquetes aún fluyan durante la recodificación (incluso en el caso de que no deban hacerlo, debido al almacenamiento en búfer).

Para el primer 4WHS, no es posible esperar el 4/4, pero es perfectamente comprensible que les haya dado pereza implementarlo. 3/4 sigue siendo necesario ya que contiene claves de grupo (incluso si no está interesado en ellas, pero sepa que no verá solicitudes ARP del AP o de un cliente del que no tiene parte de su 4WHS) y claves de administración. También puede omitir 3/4, pero entonces no tendrá confirmación de que el intercambio fue exitoso, porque 3/4 se usa para verificar que el Autenticador conoce el PMK.

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

Respuesta2

Toda la información necesaria para construir la 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/difusió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 utilizar el cifrado. Wireshark también puede desactivar esto antes de intentar descifrar los datos.

Respuesta3

Bueno, obviamente la documentación de WireShark es incorrecta. :-)

Saliendo de la documentaciónaquí:

  • Después de EAPOL 1 y 2, ambas partes 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 elAutenticador(la estación base) está lista para comenzar a usar la clave temporal.
  • El cuarto mensaje activa el cambio de la PMK configurada 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 recibe el mensaje 4.

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

Respuesta4

Esto no explica por qué, pero citando a airdecap-ngdocumentaciónde 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.

información relacionada