I found some design and implementation flaws in Wi-Fi again. All Wi-Fi devices are affected. It was a long ~9 months embargo, over this time a lot of info has been collected and that info now available at
Finally, WPA3!! It will include a more secure handshake: "WPA3 will deliver robust protections even when users choose passwords that fall short of typical complexity recommendations"
New
#TunnelCrack
flaw can break a large majority of VPNs: we can trick a VPN into leaking traffic outside the protected VPN tunnel. Our tests indicate that this is a widespread design issue. For a demo, more details, and the USENIX Security paper, see
Me and
@eyalr0
found new flaws in the WPA3 security guidelines that were *privately* created after our 1st disclosure. More details at and in our just accepted S&P paper. Wi-Fi standard is now being updated with proper defenses, which might lead to WPA3.1
Some IoT devices are initialized through smartphone apps that encode the SSID and password of the Wi-Fi network in the length of broadcasted packets. Attacker can capture this and extract the password. See
#wisec
Also check out It's test tool with 45+ test cases, a live USB image, can test both APs and clients, both home and enterprise networks, supports multiple network cards, and contains references to slides and other overview info :)
Finally updated my WPA2 KRACK scripts to Python3. They should now be more reliable and usable on recent Linux distributions. Use them to see if WPA2 devices are (still) vulnerable to the KRACK attack!
The findings consist of three design flaws and several widespread implementations flaws. Some of the flaws have been part of Wi-Fi since 1997! Full details are in my paper:
👀 Looks like nearly all setuid programs on Linux can be easily exploited. Local user can gain root privileges.
I confirmed the resulting crash on my own installation.. And apparently "this buffer overflow is easily exploitable (by transforming it into a data-only attack)"
New version of ModWifi has been released. Provides modified drivers/firmware to perform low-layer Wi-Fi attacks. Now supports Linux kernel 5.3 and below (tested with 4.9.0 and 5.2.9).
Several vulnerabilities discovered by Sönke Huster in Linux's Wi-Fi stack: heap overflow, use-after-free, infinite loop. PoC were tested in a simulated environment. But Sönke says the vulnerabilities are driver-independent (and I agree with that concern).
Slides for my presentation "Rooting Routers Using Symbolic Execution" at
#HITB2018DXB
is now online at Great conference so far, and an excellent organization!
Implementation bug in certain Wi-Fi chipsets: after being disconnected by the AP, the client sets the session key to all-zeros. Because of a bug it then sends all pending frames in the transmission buffer encrypted using an all-zero key.
Scripts to detect whether WPA2 clients are vulnerable to KRACK have been updated to work properly on the latest Kali release (which uses a new scapy version).
New bruteforce attack on pre-shared WPA2 passwords. Abuses the PMKID to test if a password is correct. Cool technique :) Only works against networks with roaming enabled, so I suspect most personal networks aren't affected. Does not affect enterprise networks.
Good post about exploiting the Wi-Fi stack in a Tesla Model S (2020). First exploits the Wi-Fi firmware, then the host. Firmware vulnerability is the 802.11e (WMM) functionality when handling ADDTS and TSPEC frames, host vulnerability in the driver.
WPA3: A Missed Opportunity tl;dr: only mandatory part of WPA3 is a new handshake that prevents dictionary attacks. That's surprising: they promised more features in their press release earlier this year.
Abusing Wi-Fi to localize someone's devices. Attacker spoofs beacons to pretend there's buffered traffic. Clients request this traffic & reveal their MAC address. Fake frames are sent to the victim & time-of-flight of the response is used for localization
We discovered that the Wi-Fi network name isn't properly verified when connecting. Clients can be tricked to connect to a wrong network. E.g., can downgrade clients to the less secure 2.4 GHz. To be presented at WiSec'24.
Simon of
@top10vpn
wrote about it
History repeats. In the proposed fix to our Dragonblood WPA3 attacks, they're applying HKDF on the password, and our advice to use PBKDFs instead is ignored (this would make dictionary attacks in the face of implementation vulnerabilities more costly).
In our USENIX
#WOOT18
paper, we found a decryption oracle in Android's and Linux's Wi-Fi client called wpa_supplicant. Only exploitable when using TKIP on a WPA2 network (the default in 20% of networks). See section 5.4 of
Heap overflow discovered in sudo! Researchers demonstrated exploits on Ubuntu 20.04, Debian 10, and Fedora 33 to obtain root privileges. Vulnerability has been present for over 10 years. Tracked as CVE-2021-3156. Read the details at
Intel patched these vulnerabilities in the Management Engine as well.
It's still crazy to me how there's a whole OS that's hidden in the lower layers of your CPU... and that this OS supports Wi-Fi.
I found some design and implementation flaws in Wi-Fi again. All Wi-Fi devices are affected. It was a long ~9 months embargo, over this time a lot of info has been collected and that info now available at
Blogpost about some new KRACK attack results, and our extension to the WiFi standard to prevent multi-channel man-in-the-middle attacks My
#HITBGSEC
talk will be about this too, but contains more results, so vote for it :)
That means dictionary attacks no longer work. The handshake they're referring to is likely Simultaneous Authentication of Equals (SAE). Which is also called Dragonfly. See
One design flaw can be used to inject packets towards clients. Makes it possible to force victim to use malicious DNS server.
Some implementation flaws can be abused to inject packets towards an AP. Can be abused to punch a hole in the router's NAT and attack local devices.
YouTube deleted my demo video about WPA3 research.
It was a minor video that was purely technical. Showing something in the fairly rarely used Linux IWD client. But apparently enough to get a strike on my account.
Slides of my presentation about the
#KRACK
attack against WPA2 at
#bluehatil
< It contains some new thoughts and remarks on multi-party vulnerability coordination!
We have some follow-up work on the WPA2 KRACK attack. Check it out at tl;dr: some updates were flawed & Wi-Fi’s official defense could be bypassed, so selected attacks were still possible. No need for panic, most affected vendors already provided updates.
@pwnheadcom
Was this inspired by a Black Mirror episode? You're assigning a "social score" to researchers... The academic world tried this with several type of metrics and it's a bad idea.
@evacide
@hackerfantastic
Privately scanning for Wi-Fi networks was properly implemented all the time. Apple was the first vendor to introduce this. The flaw only leaks your MAC address when *connected* to a Wi-Fi network. While a valid issue, it sounds worse than it actually is.
This new iPhone flaw is about tracking users *while connected* to a Wi-Fi network. Even with the CVE fixed, that's IMO hard to fully prevent.
Usage of random MAC addresses while *scanning* for Wi-Fi networks seems to have properly worked all the time.
Glad to see that beacon protection for Wi-Fi, which we standardized in collaboration with Broadcom, Intel, and others, is being implemented in Linux. Initial commits available at and
@IanColdwater
Assumes two SSIDs share the same passwords/credentials. It's an interesting attack, but to be honest also not something to worry about too much, the threat model is fairly unique.
Currently making a new Wi-Fi tool. More details soon =) Want to make sure your device is supported? Then reply with the current wireless card that is in your laptop! (On Linux check with `lspci | grep -i net`).
Interesting case where a Wi-Fi network caused interference for a weather radar that was 47 miles (!) away. They explain how the offending Wi-Fi network was tracked down.
As always though: update your devices, we never know when attacks will improve. Check with your vendor to know the current practical impact for your device.
Today I received an email with two identical attachments (an official letter). Why? So I can sign one and send it back, while keeping the other as a personal copy.
The
@WiFiAlliance
published a draft standard that ties a public key to the password of a Wi-Fi network. This can prevent rogue AP attacks. This is a good opportunity for anyone to review its security!
More evidence that WPA3 and its Dragonfly handshake is hard to implement securely: IWD was still vulnerable to side-channel leaks. Additionally, the patch for FreeRADIUS was not backported to their v3 branch.
This confirms our warning that Dragonfly is hard to implement securely
Microsoft released their crypto library the day after we disclosed Dragonblood. Looks like their WPA3 code includes the necessary defenses. I wonder what it looked like initially...
Slides of the Dragonblood presentation at
#bhusa
are now online Important to mention is that WPA3 is better than WPA2, even with it's flaws. So when available, switch to WPA3!
The impact of the attacks really depends on the device. Sometimes the impact is very minor and there's nothing to worry about. Sometimes the impact is serious.
Doing Wi-Fi research is always... an adventure. Sometimes things suddenly stop working. It feels like your past weeks of work were all useless. You wonder whether it's better to focus on other ideas.
Then you realize you were simply sending frames on the wrong channel... oops
Protocol state bugs remain tricky! We found that in an IWD Wi-FI AP we could skip Msg2 of the handshake to bypass authentication. And in wpa_supplicant the Phase2 authentication can be skipped when using PEAP. See and
Looks like beacon protection will likely become mandatory in Wi-Fi 7 (a.k.a. 802.11be)! 🤠
There's an update to the draft IEEE 802.11be standard that adds the line "An EHT AP shall have dot11BeaconProtectionEnabled set to 1". Source:
Clever Wi-Fi attack against a locked Windows 10 screen in an enterprise setting.
Several of us pointed out before that having a Wi-Fi network selection menu in the Lock Screen is bad... and this confirms that hunch using an impactful attack!
Finished implementation of Operating Channel Validation on top of Hostap. It prevents multi-channel MitM in Wi-Fi networks. Only 2762 lines of code (of which 975 are tests), but spread over 76 files (!!). Background:
The website of a company doing corona tests in The Netherlands and Belgium was vulnerable to a trivial vulnerability.
Data of all tests were leaked. On top of that, it was possible (and easy!) to insert fake test results in their database and get a valid QR code...
nieuws: Door een groot lek bij een testbedrijf kon iedereen kinderlijk eenvoudig valse reis- en toegangsbewijzen in de app CoronaCheck krijgen.
Ook zijn de gegevens van 60.000 mensen die bij deze organisatie een coronatest hebben gedaan gelekt.
In our USENIX
#WOOT18
paper, we found a decryption oracle in Android's and Linux's Wi-Fi client called wpa_supplicant. Only exploitable when using TKIP on a WPA2 network (the default in 20% of networks). See section 5.4 of
Operating Channel Validation has been merged to the development version of wpa_supplicant and hostapd! It prevents multi-channel MitM in Wi-Fi networks. For more background on this defense see our paper or our presentation
Is your company implementing WPA3? Contact me if you want your implementation to be tested for free: I only need a device that supports WPA3. Details can always be discussed.