PMKID-Angriff

Grundidee

Beim 4-Wege-Handshake mussten wir Nachricht 2 des Clients mitschneiden und über den KCK die MIC nachrechnen. Beim PMKID-Angriff geht es kürzer

Der Access Point liefert den PMKID freiwillig schon in der ersten Handshake-Nachricht (M1) – noch bevor sich ein Client vollständig verbunden hat.

Der PMKID wird direkt aus dem PMK gebildet. Und der PMK ist – genau wie beim Handshake – nur aus PSK und SSID abgeleitet. Die einzige Unbekannte bleibt also wieder der PSK.

Wir setzen nacheinander Passwörter als PSK ein, rechnen den PMKID nach und vergleichen ihn mit dem mitgeschnittenen. Passt er, ist das Passwort gefunden.

Einleitung

• Der PMKID-Angriff wurde 2018 von Jens "atom" Steube (Entwickler von hashcat) veröffentlicht und quasi durch Zufall beim Untersuchen des 802.11r-Roamings entdeckt.
• Der entscheidende Unterschied zum klassischen Handshake-Angriff liegt nicht im Cracken, sondern im Mitschneiden: Man braucht keinen verbundenen Client und keinen Deauth mehr.
• Kernziel dieses Artikels ist zu zeigen, dass hinter dem PMKID dieselbe Rechenkette steckt wie beim 4-Wege-Handshake – nur deutlich kürzer.

Begriffe

PSK

• Preshared Key : gemeinsamer Schlüssel (das WLAN-Passwort) – die einzige Unbekannte.

SSID

• Service Set Identifier : Name des WLAN-Netzwerkes.

PMK

• Pairwise Master Key : Mehrfachanwendung einer Hashfunktion (SHA1 / 4096 Durchgänge) auf PSK und SSID. Exakt derselbe Wert wie beim 4-Wege-Handshake.

PMKID

• Pairwise Master Key Identifier : eindeutige Kennung für einen zwischengespeicherten PMK. Eigentlich fürs schnelle Roaming gedacht (PMK-Caching / 802.11r), damit sich ein Client bei einem AP-Wechsel nicht komplett neu authentifizieren muss.

PMK Name

• Feste ASCII-Zeichenkette "PMK Name" (8 Byte). Geht als Konstante in die Berechnung ein – überall gleich, also bekannt.

Association Request

• Anmelde-Anfrage einer Station beim AP. Unterstützt der AP PMKID-Caching, antwortet er mit einem M1, das das PMKID-Feld enthält.

M1 (erste EAPOL-Nachricht)

• Erste Nachricht des 4-Wege-Handshakes (AP → Client). Enthält im RSN-Element optional den PMKID. Für den Angriff reicht diese eine Nachricht.

Wo steckt der PMKID?

Der PMKID sitzt im RSN-Element der ersten EAPOL-Nachricht (M1), die der AP verschickt. Er ist optional – der AP füllt das Feld nur, wenn er PMKID-Caching unterstützt. Genau deshalb funktioniert der Angriff nicht gegen jeden AP.

Berechnungen

PMK

Verfahren ist bekannt – einzige Unbekannte ist der PSK. Identisch zum Handshake-Artikel.

• PMK = HASH(PSK | SSID) (PBKDF2-HMAC-SHA1, 4096 Runden, 256 Bit)

PMKID

Der PMKID ist ein HMAC-SHA1 über eine feste Konstante und zwei MAC-Adressen – mit dem PMK als Schlüssel. Es werden die ersten 128 Bit verwendet.

• PMKID = HMAC-SHA1( PMK , "PMK Name" + MAC-AP + MAC-CLIENT )

Alles was grün ist, ist bekannt oder mitgeschnitten:

• "PMK Name" = feste Konstante → bekannt
• MAC-AP = BSSID des Access Points → mitgeschnitten
• MAC-CLIENT = eigene MAC (die des Angreifers) → bekannt
• PMKID = aus M1 → mitgeschnitten

Nur der PMK ist unbekannt – und der hängt allein am PSK.

Iterationsformel

Alles in eine Formel eingesetzt. Nur der PSK ist unbekannt

• PMKID = HMAC-SHA1( HASH(PSK | SSID) , "PMK Name" + MAC-AP + MAC-CLIENT )

Zum Vergleich die Handshake-Formel

• MIC = HMAC-SHA1( ⌊HASH( HASH(PSK|SSID) + NONCE-A + NONCE-S + MAC-AP + MAC-CLIENT )⌋₁₂₈ , 2. EAPOL-Frame )

Man sieht direkt

Beim PMKID fallen beide Nonces und der ganze EAPOL-Frame weg. Kürzere Formel, weniger mitzuschneiden – aber der teure PBKDF2-Teil (HASH(PSK|SSID), 4096 Runden) steht in beiden drin.

Angriff (Ablauf)

Alles außer dem PSK haben wir. Jetzt iterieren wir

• Association Request an den Ziel-AP senden
• AP antwortet mit M1 inkl. PMKID (falls er es unterstützt)
• PMKID, BSSID, Client-MAC und SSID mitschneiden
• Passwort aus der Liste als PSK einsetzen
• PMKID berechnen (nach der Formel oben)
• berechneten PMKID mit dem mitgeschnittenen vergleichen
• gleich? → Passwort gefunden. Sonst → nächstes Passwort.

Vergleich zum 4-Wege-Handshake

Merkmal	4-Wege-Handshake	PMKID
Verbundener Client nötig	ja	nein
Deauth nötig	meist ja	nein
Nonces in der Rechnung	ja (NONCE-A, NONCE-S)	nein
EAPOL-Frame in der Rechnung	ja (2. Frame)	nein
Voraussetzung	Handshake muss stattfinden	AP muss PMKID mitsenden
Rechenaufwand pro Passwort	hoch (PBKDF2 4096)	gleich hoch (PBKDF2 4096)

Wichtig: Das Cracken selbst ist nicht schneller. Der teure Teil ist der PMK (PBKDF2 mit 4096 Runden) – und der ist bei beiden Angriffen identisch. PMKID macht nur das Einsammeln leichter, nicht das Knacken.

Grenzen

• Funktioniert nur, wenn der AP den PMKID im M1 mitsendet (PMKID-Caching). Viele APs tun das nicht.
• WPA3 / SAE ist immun: Dort wird der PMK nicht mehr direkt per PBKDF2 aus dem PSK abgeleitet – den offline-angreifbaren Wert gibt es schlicht nicht mehr.
• Der Rechenaufwand pro Passwort bleibt unverändert. Lange, zufällige Passwörter bleiben praktisch sicher – die Länge und der Zeichenraum entscheiden, nicht der Angriffsweg.

Praxis

Der eigentliche Werkzeug-Ablauf steht im Kapitel zu hcxdumptool / hashcat. Kurzform

• Mitschneiden: hcxdumptool -i wlan0 -w dump.pcapng
• Umwandeln: hcxpcapngtool -o hash.hc22000 dump.pcapng
• Cracken: hashcat -m 22000 hash.hc22000 password.lst

Im hashcat-Format (Mode 22000) hat der PMKID den Typ 01

WPA*01*<PMKID>*<MAC-AP>*<MAC-CLIENT>*<SSID hex>***

(ein voller EAPOL-Handshake bekäme dagegen Typ 02).

Links

• https://hashcat.net/forum/thread-7717.html
• https://github.com/ZerBea/hcxdumptool
• https://www.kali.org/tools/hcxtools/