New attack on WPA/WPA2 using PMKID

[M4d6r33nh4t]

So far, nothing but goose eggs (no success yet). I've used three separate routers (Linksys WRT54GL, Netgear Nighthawk R7000, and Belkin N450). All configured with WPA2, no clients attached.

I've used two separate adapters (Panda PAU09 148f:5572, and Alfa AWUS 051NH v2 148f:3572) against all previously mentioned APs.

Here's the syntax I used:
hcxdumptool -o output.pcapng -i wlan0 -t 5 --enable_status --filterlist=test.txt --filtermode=2
"test.txt" was the file containing the BSSID of the AP (colons removed)

I'll keep testing with a few more adapters and routers and post once I've got something worth posting!

[stryngs]

@atom,

Very nice work. Figured I'd bring scapy into play and make this a lot easier to work with. Weaponized script is up at:
https://github.com/stryngs/scripts/tree/...id2hashcat

Enjoy!

[netgab_joe]

Hi,
first of all, congratulations to your work - nice job.
Especially, because the attack is so simple, I'm wondering why nobody discovered it earlier

Mostly for me, I'm writing a short summary of the stuff here:
http://netgab.net/web/2018/08/08/yawa-ye...-analysis/

However, regarding the question whether "my device is affected" or not:

I guess, consumer grade hardware won't be attackable using this tool, because these simply do not perform PMKID caching (i guess). I did a quick test using an AVM Fritz!Box (popular model in Germany). There is no PMKID in the first message of the 4-way handshake.
=> Therefore, it is not vulnerable, right?!

However, I tested it as well using enterprise grade equipment (Cisco). The PMKID is included in the first EAPoL message of the 4 way handshake.
Maybe this is a silly question, but does PMKID including make sense for WPA2 PERSONAL networks?
In my opinion no, because there is no functional benefit (except with 802.11r FT).

PMKID caching makes sense for WPA2 Enterprise (802.1X) networks. However, as you outlined, the attack does not work for these WLANs. The reason is, that the PMK is dynamically derived per user per session and is a random value, not included in any dictionary (at least I'm sure for all TLS based EAP methods like EAP-TLS, PEAP, EAP-TTLS etc.).

So, the combination PMKID caching and PSK networks does not makes sense (right?). However, some vendors might send the PMKID anyways. Despite of the fact, that the playrules for a WPA2 PSK network doesn't change because of the new attack, the mitigation for a vendor is pretty simple:
=> Disable sending of PMKIDs for PSK network (because it does not make sense, right).

The only thing that remains open is the combination of PSK networks with 802.11r FT - because there is a (small) functional benefit (2 messages instead of 6 during the roaming event).

[dominikg43g34]

Hi together,
when using hxcdumptool, I just see PROBEREQUESTs and PROBERESPONSEs for each SSID.
But the tool doesn't seem to send association requests, so there won't be any EAPOLs/PMKIDs.
I'm using an Atheros chip, could this be the problem? Monitoring mode is active.

./hcxdumptool -i wlxfc7516e1fxxx -o test.pcapng
I tried with filterlist and manual channel as well.

Best regards
Dominik

[atom]

I guess, consumer grade hardware won't be attackable using this tool, because these simply do not perform PMKID caching (i guess). I did a quick test using an AVM Fritz!Box (popular model in Germany). There is no PMKID in the first message of the 4-way handshake.

From what I've seen roaming one of the big new features in Fritz!OS7. Older versions Fritz!Box routers may not be vulnerable but new ones maybe. Since I do not have access to such a router I can't test myself.

However, my Speedport (w724v) from german Telekom is vulnerable. Works on first try.

[undeath]

I'm using an Atheros chip, could this be the problem?

Atheros chips are in fact known to be buggy. See https://hashcat.net/forum/thread-6661-po...l#pid41311

[atom]

Indeed, hcxdumptool doesn't work with my atheros (mini-pci):

[ 13.804884] ath5k: phy0: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)

However, my usb card works perfectly:

Bus 001 Device 002: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

I guess it's a driver problem but I can't say for sure.

[ZerBea]

Some statistics:

Session..........: hashcat
Status...........: Quit
Hash.Type........: WPA-PMKID-PBKDF2
Hash.Target......: 16800.txt
Time.Started.....: Wed Aug 8 12:16:43 2018 (10 secs)
Time.Estimated...: Wed Aug 8 15:29:47 2018 (3 hours, 12 mins)
Guess.Base.......: File (cracked.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....: 364.8 kH/s (0.64ms) @ Accel:64 Loops:16 Thr:1024 Vec:1
Recovered........: 19424/89046 (21.81%) Digests, 19105/87531 (21.83%) Salts
Recovered/Time...: CUR:N/A,N/A,N/A AVG:0,0,0 (Min,Hour,Day)
Progress.........: 5435056/5406089622 (0.10%)
Rejected.........: 0/5435056 (0.00%)
Restore.Point....: 0/61762 (0.00%)
Candidates.#1....: $HEX[0000000000000000] -> $HEX[d9a1d9a2d9a3d9a4d9a5d9a6d9a7d9a8d9a9d9a0]
HWMon.Dev.#1.....: Temp: 61c Fan: 43% Util: 97% Core:1873MHz Mem:5005MHz Bus:16

[ZerBea]

Limitations:
This attack will not work on dynamic calculated PMKs.
You can identify them in your hash file:
MAC_AP, MAC_STA and ESSID are the same, PMKID changed.
In that case an EAPOL 4/4 handshake is also usless.

[ZerBea]

And please do not wonder about "802.11q". We added this to the write-up, to see how many people simply copy from one another. So please, forgive us.....