☰

Testfall

tag-icon • tag-icon wireshark wpa decryption
Testfall

Ausdiese Wiki-Seite:

WPA und WPA2 verwenden Schlüssel, die aus einem EAPOL-Handshake abgeleitet wurden, um den Datenverkehr zu verschlüsseln.alle vierHandshake-Pakete für die Sitzung vorhanden sind, die Sie entschlüsseln möchten, kann Wireshark den Datenverkehr nicht entschlüsseln. Sie können den Anzeigefilter eapol verwenden, um EAPOL-Pakete in Ihrer Erfassung zu finden.

Mir ist aufgefallen, dass die Entschlüsselung auch mit (1, 2, 4) funktioniert, aber nicht mit (1, 2, 3). Soweit ich weiß, reichen die ersten beiden Pakete aus, zumindest was Unicast-Verkehr betrifft. Kann mir bitte jemand genau erklären, wie Wireshark damit umgeht, mit anderen Worten, warum nur die erste Sequenz funktioniert, wenn das vierte Paket doch nur eine Bestätigung ist? Ist außerdem garantiert, dass (1, 2, 4) immer funktioniert, wenn (1, 2, 3, 4) funktioniert?

Testfall

Dies ist der gzippte Handshake (1, 2, 4) und ein verschlüsseltes ARPPaket (SSID: SSID, Passwort: password) in base64der Kodierung:

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

Dekodieren mit:

$ base64 -d | gunzip > handshake.cap

Führen Sie es aus tshark, um zu prüfen, ob das ARPPaket korrekt entschlüsselt wird:

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

Es sollte gedruckt werden:

  1 0.000000 D-Link_a7:8e:b4 -> HonHaiPr_22:09:b0 EAPOL-Schlüssel
  2 0,006997 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 EAPOL-Schlüssel
  3 0,038137 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 EAPOL-Schlüssel
  4 0.376050 ZyxelCom_68:3a:e4 -> HonHaiPr_22:09:b0 ARP 192.168.1.1 ist bei 00:a0:c5:68:3a:e4

Antwort1

EAPOL-Austausche werden auch verwendet, um die temporären Schlüssel zu erneuern. Die neuen Schlüssel werden auf dem Supplicant installiert, nachdem dieser 4/4 gesendet hat, und auf dem Authenticator, wenn dieser 4/4 empfängt[1]. Wenn Wireshark die Neuverschlüsselung korrekt handhaben soll, darf es die Schlüssel erst nach dem Lesen des 4/4-Pakets im Frame verwenden, da während der Neuverschlüsselung möglicherweise noch Pakete fließen (selbst wenn dies aufgrund der Pufferung nicht der Fall sein sollte).

Beim ersten 4WHS ist es möglich, nicht auf 4/4 zu warten, aber es ist vollkommen verständlich, dass sie einfach zu faul waren, es umzusetzen. 3/4 ist immer noch notwendig, da es Gruppenschlüssel (auch wenn Sie nicht daran interessiert sind, aber wissen, dass Sie keine ARP-Anfragen vom AP oder einem Client sehen werden, dessen 4WHS Sie nicht haben) und Verwaltungsschlüssel enthält. Sie können 3/4 auch überspringen, aber dann haben Sie keine Bestätigung, dass der Austausch erfolgreich war, da 3/4 verwendet wird, um zu überprüfen, ob der Authenticator den PMK kennt.

[1] Beachten Sie, dass beim aktuellen Schema, wenn die 4/4-Nachricht verloren geht, der Supplicant den neuen Schlüssel verwendet und der Authenticator immer noch den alten Schlüssel verwendet. Das erneute Senden von 3/4 verschlüsselt mit dem alten Schlüssel wird nicht helfen. Dieses Problem, neben vielen anderen mit WPA2, wird im neuesten 802.11 2012-Standard dadurch gelöst, dass zwei Schlüssel parallel aufbewahrt werden.

Antwort2

In den Schritten 1 und 2 werden alle zum Erstellen des PTK erforderlichen Informationen ausgetauscht. Dies sollte ausreichen, um Unicast-Verkehr zu entschlüsseln.

Ohne Schritt 3 verfügen Sie nicht über GTK und das Entschlüsseln von Multicast/Broadcast ist daher nicht möglich.

Schritt 4 ist nicht wirklich notwendig, um den erfassten Datenverkehr zu entschlüsseln, aber wenn es keinen Schritt 4 gibt, wird der Client/AP nicht mit der Verschlüsselung beginnen. Wireshark kann dies ebenfalls berücksichtigen, bevor es versucht, Daten zu entschlüsseln.

Antwort3

Nun, offensichtlich ist die WireShark-Dokumentation falsch. :-)

Ausgehend von der DokumentationHier:

  • Nach EAPOL 1 und 2 kennen beide Seiten den zeitlichen Schlüssel, der zur Entschlüsselung des Datenverkehrs verwendet wird.
  • Die dritte Nachricht ist der Beweis, dass beide Seiten den zeitlichen Schlüssel kennen und weist darauf hin, dass dieAuthentifikator(die Basisstation) ist bereit, den zeitlichen Schlüssel zu verwenden.
  • Die vierte Nachricht löst den Wechsel vom vor dem EAPOL eingerichteten PMK zum im EAPOL abgeleiteten zeitlichen Schlüssel aus.

Insofern ergibt es Sinn. WireShark braucht Nachricht 3 für nichts. Es kennt die Schlüssel nach den Nachrichten 1 und 2, wartet aber mit der Verwendung dieser Schlüssel zum Entschlüsseln des Datenverkehrs, bis es Nachricht 4 empfangen hat.

Es gibt für nichts im Leben eine Garantie, insbesondere nicht für das Verhalten von freier Software. Man kann jedoch davon ausgehen, dass das Vorhandensein von Nachricht 3 nicht erforderlich ist, damit WireShark die Sitzung entschlüsseln kann.

Antwort4

Dies erklärt nicht, warum, aber ein Zitat aus dem airdecap-ngDokumentationwie auch immer,

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.

verwandte Informationen