Wireshark WPA 4-Wege-Handshake

13

Von dieser Wiki-Seite :

WPA und WPA2 verwenden Schlüssel, die von einem EAPOL-Handshake abgeleitet sind, um den Datenverkehr zu verschlüsseln. Solange nicht alle vier Handshake-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 lokalisieren.

Ich habe bemerkt, dass die Entschlüsselung auch mit (1, 2, 4) funktioniert, aber nicht mit (1, 2, 3). Soweit ich weiß, reichen die ersten beiden Pakete zumindest für den Unicast-Verkehr. Kann jemand bitte genau erklären, wie Wireshark damit umgeht, mit anderen Worten, warum funktioniert nur die vorherige Sequenz, da das vierte Paket nur eine Bestätigung ist? Ist auch 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 :, SSIDpassword :) passwordbei der base64Codierung:

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 tsharkSie Folgendes aus, um zu überprüfen, ob das ARPPaket korrekt entschlüsselt wurde :

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

Es sollte drucken:

  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 um 00: a0: c5: 68: 3a: e4
cYrus
quelle
Es kann nicht .. es muss entschlüsselt werden, weil es alle vier hat, oder Sie sind mit dem WiFi-Netzwerk verbunden und das entschlüsselt die Pakete
Paul
Ich spreche (offensichtlich) von Paketen, die im RFMON-Modus erfasst wurden.
CYRUS
@Paul: Ich habe die Frage bearbeitet. Kannst du antworten?
CYRUS
Ich wünschte ich könnte. Wenn Sie die EAPOL-Sequenz befolgen, hat der Client die PTK erst nach dem ersten Paket (der Anonce ist bestanden). Der AP kennt die PTK nach dem zweiten Paket (snonce). Wenn Sie diese beiden beobachten und die MACs, die Sie natürlich haben, und die ssid + psk kennen, dann sollte dies alles sein, was Sie brauchen. Das dritte Paket ist nur GTK für Broadcast und Multicast, und das vierte ist nur eine ACK. Wenn Sie Unicast entschlüsseln (was die Arp-Antwort ist), sollten die ersten beiden Pakete ausreichen. Ich kann nicht anders, als zu glauben, dass mir etwas fehlt, da alles sagt, dass Sie alle vier brauchen.
Paul
Bist du damit weiter gekommen?
Paul

Antworten:

1

EAPOL-Vermittlungen werden auch verwendet, um die temporären Schlüssel zu erneuern. Die neuen Schlüssel werden nach dem Senden von 4/4 auf dem Supplicant installiert und beim Empfang von 4/4 auf dem Authenticator [1] installiert. Wenn Wireshark die Neuverschlüsselung korrekt handhaben muss, darf es die Schlüssel erst nach dem Lesen des 4/4-Pakets im Frame verwenden, da möglicherweise noch Pakete während der Neuverschlüsselung fließen (auch 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 durchaus verständlich, dass die Implementierung nur faul war. 3/4 ist weiterhin erforderlich, da es Gruppenschlüssel enthält (auch wenn Sie nicht daran interessiert sind, aber wissen, dass Sie keine ARP-Anforderungen vom AP oder einem Client sehen, für den Sie keinen Teil des 4WHS haben) und Verwaltungsschlüssel. Sie können auch 3/4 überspringen, haben aber keine Bestätigung, dass der Austausch erfolgreich war, da mit 3/4 überprüft wird, ob der Authentifikator das PMK kennt.

[1] Beachten Sie, dass mit dem aktuellen Schema, wenn die 4/4-Nachricht verloren geht, der Supplicant den neuen Schlüssel verwendet und der Authentifikator weiterhin den alten Schlüssel verwendet und das erneute Senden von mit dem alten Schlüssel verschlüsselten 3/4 nicht hilft . Dieses Problem, unter anderem mit WPA2, wird im neuesten 802.11 2012-Standard behoben, indem zwei Schlüssel parallel gehalten werden.

BatchyX
quelle
1

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

Ohne Schritt 3 ist die GTK nicht verfügbar, sodass Multicast / Broadcast nicht entschlüsselt werden kann.

Schritt 4 ist nicht wirklich erforderlich, um den erfassten Datenverkehr zu entschlüsseln. Wenn jedoch kein Schritt 4 ausgeführt wird, verwendet der Client / AP die Verschlüsselung nicht. Wireshark kann dies deaktivieren, bevor es versucht, Daten ebenfalls zu entschlüsseln.

YLearn
quelle
0

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

Abgehend die Dokumentation hier :

  • Nach EAPOL 1 und 2 kennen beide Seiten den Zeitschlüssel, der zum Entschlüsseln des Datenverkehrs verwendet wird.
  • Die dritte Nachricht ist ein Beweis dafür, dass beide Seiten den Zeitschlüssel kennen, und zeigt an, dass der Authentifikator (die Basisstation) bereit ist, den Zeitschlüssel zu verwenden.
  • Die vierte Nachricht löst den Wechsel von der vor dem EAPOL eingerichteten PMK zu dem im EAPOL abgeleiteten Zeitschlüssel aus

Das macht also Sinn. WireShark benötigt für nichts Nachricht 3. Er kennt die Schlüssel nach den Nachrichten 1 und 2, wartet jedoch, bis er die Nachricht 4 empfangen hat, damit, den Datenverkehr zu entschlüsseln.

Es gibt keine Garantie für irgendetwas im Leben, insbesondere für das Verhalten freier Software, aber es ist eine vernünftige Wette, dass keine Nachricht 3 vorhanden sein muss, damit WireShark die Sitzung entschlüsseln kann.

Alter Pro
quelle
Mir scheint, dass Paket 4 auch nicht notwendig ist - es ist nur dafür gedacht, darauf zu warten.
Paul
@Paul, das ist ungefähr so, als würde man sagen, dass nach einer "Pause" "Wiederaufnahme" nicht notwendig ist .
Old Pro
@OldPro, ich bin mir nicht sicher, ob es eine gute Idee ist, auf 4 ° zu warten. Erfasste Pakete neigen dazu, verloren zu gehen, besonders wenn sie durch die Luft fliegen.
CYRUS
@cYrus, das Warten auf 4 ist unerlässlich, da die Verschlüsselungsschlüssel auf beiden Seiten gleichzeitig geändert werden müssen. Wenn der Client keine 4 empfängt, weiß er nicht, dass die Basis 3 empfangen hat. Wenn der Client keine 4 empfängt, sendet er erneut 3 (was einen erneuten Versand von 4 auslöst), bis er entweder 4 empfängt oder den Versuch aufgibt um die Verbindung herzustellen.
Old Pro
@OldPro: Ich spreche nicht über das Protokoll. Beide Seiten können alle Pakete empfangen, sie werden jedoch möglicherweise von der Entität verworfen oder nicht erfasst, die den Datenverkehr passiv erfasst.
CYRUS
0

Dies erklärt nicht, warum, aber trotzdem aus der Dokumentation der Flugsicherung zu zitieren,

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
quelle