Wireshark WPA 4-kierunkowy uścisk dłoni

13

Z tej strony wiki :

WPA i WPA2 używają kluczy pochodzących z uzgadniania EAPOL do szyfrowania ruchu. O ile nie są dostępne wszystkie cztery pakiety uzgadniania dla sesji, którą próbujesz odszyfrować, Wireshark nie będzie w stanie odszyfrować ruchu. Możesz użyć filtru wyświetlania eapol, aby zlokalizować pakiety EAPOL w twoim przechwytywaniu.

Zauważyłem, że deszyfrowanie działa również z (1, 2, 4), ale nie z (1, 2, 3). O ile wiem, dwa pierwsze pakiety są wystarczające, przynajmniej w odniesieniu do ruchu emisji pojedynczej. Czy ktoś może wyjaśnić dokładnie, jak sobie z tym radzi Wireshark, innymi słowy, dlaczego działa tylko poprzednia sekwencja, skoro czwarty pakiet jest tylko potwierdzeniem? Czy jest też zagwarantowane, że (1, 2, 4) zawsze będzie działać, gdy (1, 2, 3, 4) działa?

Przypadek testowy

To zgzipowany uścisk dłoni (1, 2, 4) i zaszyfrowany ARPpakiet (SSID :, SSIDhasło :) passwordw base64kodowaniu:

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

Dekoduj za pomocą:

$ base64 -d | gunzip > handshake.cap

Uruchom, tsharkaby sprawdzić, czy poprawnie odszyfrowuje ARPpakiet:

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

Powinien wydrukować:

  1 0,000000 D-Link_a7: 8e: b4 -> HonHaiPr_22: 09: b0 Klucz EAPOL
  2 0,006997 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Klucz EAPOL
  3 0,038137 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Klucz EAPOL
  4 0,376050 ZyxelCom_68: 3a: e4 -> HonHaiPr_22: 09: b0 ARP 192.168.1.1 jest o 00: a0: c5: 68: 3a: e4
Cyrus
źródło
Nie może… musi być odszyfrowywany, ponieważ ma wszystkie cztery lub jesteś podłączony do sieci Wi-Fi i to odszyfrowuje pakiety
Paul
Mówię (oczywiście) o pakietach przechwyconych w trybie RFMON.
cyr
@Paul: Zredagowałem pytanie; Możesz odpowiedzieć?
cyr
Chciałbym móc. Jeśli postępujesz zgodnie z sekwencją EAPOL, klient ma kod PTK tylko po pierwszym pakiecie (anonce jest przekazywany). AP zna PTK po drugim pakiecie (snonce). Jeśli zaobserwujesz te dwa i znasz adresy MAC, które oczywiście robisz, oraz ssid + psk, to powinno być wszystko, czego potrzebujesz. Trzeci pakiet to tylko GTK do emisji i multiemisji, a czwarty to tylko ACK. Jeśli odszyfrowujesz emisję pojedynczą (która jest odpowiedzią arp), powinny wystarczyć dwa pierwsze pakiety. Nie mogę się powstrzymać, ale myślę, że coś mi umknęło, ponieważ wszystko mówi, że potrzebujesz wszystkich czterech.
Paul
Czy poszedłeś dalej z tym?
Paul

Odpowiedzi:

1

Wymiana EAPOL służy również do odnawiania kluczy tymczasowych. Nowe klucze są instalowane w Dostawcy po wysłaniu 4/4 i są instalowane w Authenticator, gdy otrzymuje on 4/4 [1]. Jeśli Wireshark musi poprawnie obsługiwać ponowne generowanie klucza, musi korzystać z kluczy tylko po odczytaniu pakietu 4/4 w ramce, ponieważ pakiety mogą nadal przepływać podczas ponownego generowania klucza (nawet w przypadku, gdy nie powinny, ze względu na buforowanie)

W przypadku pierwszego 4WHS możliwe jest nie czekanie na 4/4, ale jest całkowicie zrozumiałe, że byli po prostu leniwi, aby go wdrożyć. 3/4 jest nadal konieczne, ponieważ zawiera klucze grupy (nawet jeśli nie jesteś nimi zainteresowany, ale wiesz, że nie zobaczysz żądań ARP od AP lub klienta, dla którego nie masz części jego 4WHS) i kluczy zarządzania. Możesz także pominąć 3/4, ale wtedy nie masz potwierdzenia, że ​​wymiana się powiodła, ponieważ 3/4 służy do sprawdzenia, czy Authenticator zna PMK.

[1] Zauważ, że przy obecnym schemacie, jeśli wiadomość 4/4 zostanie utracona, suplikant zaczął używać nowego klucza, a wystawca uwierzytelnienia nadal używa starego klucza, a ponowne przesłanie 3/4 zaszyfrowanego starym kluczem nie pomoże . Problem ten, między innymi w przypadku WPA2, został rozwiązany w najnowszym standardzie 802.11 2012 poprzez równoległe połączenie dwóch kluczy.

BatchyX
źródło
1

Wszystkie informacje niezbędne do zbudowania PTK są wymieniane w krokach 1 i 2. To powinno wystarczyć do odszyfrowania ruchu emisji pojedynczej.

Bez kroku 3 nie będziesz mieć GTK, więc odszyfrowanie multiemisji / emisji nie będzie możliwe.

Krok 4 nie jest tak naprawdę konieczny do odszyfrowania przechwytywania ruchu, ale jeśli nie ma kroku 4, klient / AP nie zacznie używać szyfrowania. Wireshark może to wyłączyć, zanim spróbuje również odszyfrować dane.

YLearn
źródło
0

Cóż, oczywiście dokumentacja WireShark jest błędna. :-)

Wyjście z dokumentacji tutaj :

  • Po EAPOL 1 i 2 obie strony znają klucz czasowy, który będzie używany do odszyfrowywania ruchu.
  • Trzeci komunikat jest dowodem na to, że obie strony znają klucz czasowy i wskazuje, że Authenticator (stacja bazowa) jest gotowy do rozpoczęcia korzystania z klucza czasowego.
  • Czwarty komunikat uruchamia przejście z PMK skonfigurowanego przed EAPOL-em do klucza czasowego wyprowadzonego w EAPOL-u

Ma to więc sens. WireShark do niczego nie potrzebuje komunikatu 3. Zna klucze po wiadomościach 1 i 2, ale czeka na ich użycie do odszyfrowania ruchu, dopóki nie otrzyma wiadomości 4.

W życiu nie ma żadnych gwarancji, w szczególności zachowania wolnego oprogramowania, ale rozsądne jest założenie, że nie będzie wymogu obecności komunikatu 3 w celu odszyfrowania sesji przez WireShark.

Old Pro
źródło
Wydaje mi się, że pakiet 4 również nie jest konieczny - jest po prostu zaprojektowany, aby na niego czekać.
Paul,
@Paul, to tak jakby powiedzieć „wznawianie” nie jest konieczne po „pauzie”.
Old Pro
@OldPro, nie jestem pewien, czy czekanie na 4 ° jest dobrym pomysłem, przechwycone pakiety zwykle gubią się, szczególnie gdy podróżują w powietrzu.
cyr
@ cYrus, czekanie na 4 jest niezbędne, ponieważ klucze szyfrowania muszą być zmieniane jednocześnie po obu stronach. Jeśli klient nie otrzyma 4, nie wie, że baza otrzymała 3. Jeśli klient nie otrzyma 4, wysyła ponownie 3 (co powoduje ponowne wysłanie 4), dopóki nie otrzyma 4 lub zrezygnuje z próby aby utworzyć połączenie.
Old Pro
@OldPro: Nie mówię o protokole. Obie strony mogą odbierać wszystkie pakiety, ale mogą zostać upuszczone lub nie zostać przechwycone przez jednostkę, która biernie przechwytuje ruch.
cyr
0

To nie wyjaśnia dlaczego, ale cytowanie z airdecap-ng dokumentacji anyways,

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
źródło