08-13-2018, 03:57 AM
@lint What failed, your router or the attack?
|
New attack on WPA/WPA2 using PMKID
|
08-13-2018, 09:51 AM
Tested, works just fine. Thank you for researching.
Also, not sure if this info useful to anyone, but following hubs are vulnerable to this attack: BTHub3 (HuaweiTe) BTHub4 (Arcadyan) BTHub6 (Sagemcom) Also, the attack is successful on following adapters: ALFA AWUS036NHA (black) - Atheros AR9271 ALFA AWUS036H (grey) - Realtek RTL8187 ALFA AWUS036NH (green) - Ralink RT2870/RT3070
08-13-2018, 09:58 PM
(This post was last modified: 08-13-2018, 09:59 PM by netgab_joe.)
(08-11-2018, 08:46 AM)soxrok2212 Wrote: A quick note about 802.11r... the new trend is "mesh" networking. Lots of homes are popping up with 2-3 APs all linked together so I guess it kinda does make sense. And I guess vendors would want to have seamless handoffs with repeaters as well (which they try to push so hard). Home networks = WPA2 PERSONAL (Pre-Shared Key). 802.11r reduces the time to roam from 6 frames (2 association + 4 EAPoL frames) to 2 frames (association). However, normal roaming is still "fast enough" - even for time sensitive applications like VoIP. 802.11r and other fast roaming technologies (OKC, PMKID caching, CCKM etc.) makes perfectly sense for WPA2 ENTERPRISE (802.1X) networks to remove or minimize the EAP backend authentication (RADIUS server) during roaming. However, WPA2 ENTERPRISE is not vulnerable to this exploit, because the PMK is dynamically derived per session and is random 256 bit key. So, if a vendor for home equipment introduced 802.11r, I think this is kinda senseless, because: - Supplicants needs to be explicitely configured for 802.11r ("normal users are not clever enough") => Increase of help-desk calls - 802.11r adds complexity to the system, because the APs need to exchange the keys - The benefit is minimal to zero - There are (legacy) clients, which are disturbed if 802.11r is enabled in coexistence mode with non-802.11r within the same SSID => Increase of help-desk calls From my point of view, the vendors should simple disable the PMKID announcement in the first EAPoL message of the 4way handshake for WPA2 PERSONAL networks (... because it does not make sense). => Issue closed. 
Well, it doesn't make sense to attack dynamically derived PMKs, but it's really funny.
I did a small update on hcxtools. Download example cap from here: https://wiki.wireshark.org/SampleCaptures File: wpa-eap-tls.pcap.gz Description: 802.11 capture with WPA-EAP. PSK's to decode: a5001e18e0b3f792278825bc3abff72d7021d7c157b600470ef730e2490835d4 79258f6ceeecedd3482b92deaabdb675f09bcb4003ef5074f5ddb10a94ebe00a 23a9ee58c7810546ae3e7509fda9f97435778d689e53a54891c56d02f18ca162 or direct: https://wiki.wireshark.org/SampleCapture...ls.pcap.gz Add the PMKs to a pmklist run latest hcxpcaptool: $ hcxpcaptool -Z pmkid wpa-eap-tls.pcap.gz decompressing wpa-eap-tls.pcap.gz to /tmp/wpa-eap-tls.pcap.gz.tmp start reading from /tmp/wpa-eap-tls.pcap.gz.tmp summary: file name....................: wpa-eap-tls.pcap.gz.tmp file type....................: pcap 2.4 file hardware information....: unknown file os information..........: unknown file application information.: unknown network type.................: DLT_IEEE802_11_RADIO (127) endianess....................: little endian read errors..................: flawless packets inside...............: 86 skipped packets..............: 0 packets with FCS.............: 0 EAPOL packets................: 4 EAPOL PMKIDs.................: 1 EAP packets..................: 20 found........................: EAP type ID found........................: EAP-TLS Authentication run hashcat WPA-PMKID-PMK hashmode: $ hashcat -m 16801 pmkid pmklist Session..........: hashcat Status...........: Cracked Hash.Type........: WPA-PMKID-PMK Hash.Target......: d2cd0ca09bf5e9288fa2d529607acc4a*106f3f0e333c*247703d25ea8 Time.Started.....: Mon Aug 13 23:07:20 2018 (0 secs) Time.Estimated...: Mon Aug 13 23:07:20 2018 (0 secs) Guess.Base.......: File (pw) Guess.Queue......: 1/1 (100.00%) Speed.Dev.#1.....: 4270 H/s (0.01ms) @ Accel:512 Loops:512 Thr:1024 Vec:1 Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts Progress.........: 3/3 (100.00%) Rejected.........: 0/3 (0.00%) Restore.Point....: 0/3 (0.00%)
08-14-2018, 02:47 AM
Meant to post this earlier to see if anyone else is experiencing this. I’m using a ThinkPad with The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) and the built in WiFi chipset intel 8260. When I run hcxdumptool either with or without a specific channel it seems to spit out a few notifications, associations and stuff, but then appears to “get stuck” and the terminal really doesn’t say much else. Now if I open another window and run Airodump wlan0mon (its scanning) the terminal window running hcxdumptool starts spitting out all kinds of info and captures handshacks, multiple pmkids etc.
What do you all typically do? Run hcxdumptool locked on one channel or allow it to scan? Seems strange, but it my case I always have faster results when Airodump is running in another window.
I got many issue reports on git regarding K*A*L*I.
For all K*A*L*I users, which are not penetration testers, please read this nice post here (remove the "*" inside the link): https://unix.stackexchange.com/questions...le-help-me And please ask yourself some questions: Is the chipset recommended by hcxdumptool? Did I read help menu and README.md of hcxtools/hcxdumptool?
08-14-2018, 10:55 AM
I believe some people experienced same problem here, but I cannot find the answers.
Tandem of below parameters are not working on my hcxdumptool as designed. hcxdumptool is 4.2.0 version. Clearly channel parameter working fine, but not defined mac. ZerBea, please help. --filtermode=2 --filterlist=filter.txt
08-14-2018, 01:04 PM
Thanks ZerBea. I just used what I had laying around at the time. I can get everything to work as described. I mentioned the chipset in my post, works in monitor mode and just fine with Aircrack. Seems to work for the most part in hcxdumptool in the sense I can eventually fully carry out the attack on multiple vendors Acesss points. I’ll try another chipset whenever possible.
(08-14-2018, 08:32 AM)ZerBea Wrote: I got many issue reports on git regarding K*A*L*I.
I have:
hcxdumptool 4.2.1 (* see below) hcxtools release 4.2.0 (incl the 07/08/2018 change), and hashcat 4.2.1.8 running under The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) (Week 32 release). It can be done, but you need to RFTM. The most difficult part was getting the NVIDIA driver running - broke my install until I realised I hadn't R'd the FM well enough. (oh, and waiting for the postman to bring me ANOTHER wifi adaptor that the wife doesnt know about!!) * Note: Since v4.2.1, hxcdumptool --enable_status requires a parameter. 1 is the number you are looking for. You might want to +2 if you want to see which AP is which.
08-14-2018, 11:01 PM
(08-13-2018, 11:25 PM)ZerBea Wrote: Well, it doesn't make sense to attack dynamically derived PMKs, but it's really funny.Hi there how do you Add the PMKs to a pmklist ? Trying to test your example. Thanks Kev |
|
« Next Oldest | Next Newest »
|