Spoofing SSIDs to Downgrade WiFi Security
We worked with Professor Vanhoef to identify a new WiFi vulnerability, which affects every WiFi client on every device and operating system as it arises from a design flaw in the IEEE 802.11 WiFi standard itself.
Our objective in publishing this research is to raise the bar for wireless network security by publicizing flaws in the protocols, prompting regulatory bodies to address them, and ensuring the public remains well-informed.
We also hope to prompt software vendors into patching their products where appropriate.
We also want to educate the public about the intrinsic risks associated with connecting to shared networks and provide advice on how to stay safe against such threats.
Further Reading:
- Download the full paper SSID Confusion: Making Wi-Fi Clients Connect to the Wrong Network
- Our previous report on two serious WiFi security flaws.
Affected devices and platforms
The root cause of the vulnerability is that the IEEE 802.11 standard underpinning how WiFi works does not require the network name (SSID) to always be authenticated.
WiFi access points announce the presence of a wireless network to nearby devices by broadcasting beacon frames, which naturally include the SSID.
To make this network discovery process as easy and efficient as possible, WiFi clients don’t try to authenticate the SSID in these beacons.
This relies on an assumption, which has been proved incorrect by the discovery of this new vulnerability, that security measures are only needed once a device has decided to join a network.
The result of this fundamental design flaw means all WiFi clients on all platforms and operating systems are vulnerable to the SSID confusion attack outlined in this report.
In short, the attack tricks a victim into connecting to a different WiFi network than the one they intended by exploiting this lack of SSID authentication.
In experimental tests, all devices could be attacked successfully, as long as the conditions for the vulnerability were met.
Types of WiFi networks at risk
The following table shows which types of WiFi networks and authentication protocols are vulnerable to the SSID Confusion attack based on whether the network name (SSID) is used to derive the encryption key during the authentication handshake.
An orange tick means the authentication protocol is vulnerable under certain conditions.
Home networks
While WPA3 is generally more secure than the WPA1 and WPA2 protocols it was designed to replace, it is actually the only version of the protocol that is vulnerable to the SSID Confusion attack.
This is because WPA3 has an optional mode where the SSID is not used to derive the Pairwise Master Key (PMK) in the SAE (Simultaneous Authentication of Equals) handshake.
Unfortunately while avoiding the use of the SSID is what makes this mode highly robust against a variety of cyber attacks, it is also what makes it vulnerable to the new attack outlined in this report.
When WPA3 incorporates the network’s SSID, the new attack fails.
Enterprise networks
Enterprise networks are always vulnerable as they authenticate using 802.1X and variations of the EAP protocol, none of which make use of the SSID to derive the PMK.
Mesh networks
As mesh networks typically use SAE rather than 802.11X to avoid introducing a single point of failure, they are also vulnerable to the attack under the same conditions as a WPA3 network.
Mesh networks that do use 802.1X for authentication are also vulnerable to the attack.
Other protocols
FILS (Fast Initial Link Setup) and FT (Fast BSS Transition) are both protocols designed to make connecting and reconnecting to a network faster.
FILS is vulnerable when the shared key it uses to create the PMK comes from an EAP handshake. If it instead uses a cached PMK then it’s only vulnerable if the victim has previously connected to the target untrusted network.
FT is not vulnerable as the correct SSID is required as part of a 4-way handshake used for authentication.
How this new vulnerability can be exploited
For a more detailed explanation of how the SSID Confusion attack works, jump ahead to the next section, but it essentially involves performing a man-in-the-middle (MitM) attack to spoof the SSID of a trusted network in order to downgrade the victim into connecting to a less secure network.
This makes it easier to perform other attacks, trick the victim into installing malware, or simply snoop their internet traffic.
For the SSID Confusion attack to succeed, the following must be true:
- The victim wants to connect to a trusted network.
- There is a second network available with the same authentication credentials as the first.
- The attacker is within range to perform a man-in-the-middle (MitM) attack between the victim and the trusted network.
Note that the victim doesn’t need to have ever connected to the untrusted network. Nor does the attacker need to know the victim’s credentials.
Threat models
A common scenario is where there is a different SSID per frequency band, ie a 2.4GHz network and a 5GHz network with the same owner.
The attacker tricks the victim into connecting to an access point (AP) in the 2.4GHz band, which typically supports fewer security features such as management frame protection, beacon protection, or operating channel validation.
The AP may also be older and still vulnerable to attacks such as KRACK or FragAttacks.
An adversary could also follow up a successful SSID Confusion attack with the Kr00k and “Framing Frames” attacks, both of which are effective against older APs.
Most VPNs will prevent your traffic being intercepted in the event of a successful SSID Confusion attack.
However, some VPN apps, including popular services like Cloudflare’s WARP, hide.me and Windscribe, have a feature that automatically disables the VPN connection when your device connects to a “trusted” WiFi network. This is typically configured by specifying which SSIDs should be trusted in the VPN app settings.
Screenshot of auto-disable on trusted network from Cloudflare 1.1.1.1 app.
While this functionality offers some convenience, along with potential improvements to performance and battery life, it does leave victims’ traffic exposed when this attack succeeds.
Of course, if a victim were not to have a VPN connected at all and they were tricked into downgrading from a secure to a public network, this would also leave their traffic completely exposed.
Another threat model is where a trusted local university Wi-Fi network and an untrusted eduroam WiFi network use the same credentials.
Eduroam is the international roaming service that allows students, researchers, and staff to get WiFi access when visiting other campuses by connecting to the eduroam WiFi network using the same credentials as their home institution.
Prof Vanhoef and Gollier’s investigations revealed at least 6 educational organizations (in Czech Republic, US, UK, Belgium, Ireland, Israel) where employees could potentially be tricked into connecting to eduroam networks of other, potentially less secure institutions.
At the researchers’ own university of KU Leuven in Belgium, employees use the same enterprise authentication for both the campus WiFi and public hotspots provided by residential internet customers and broadcast from their home routers.
An attack could lure university employees onto these residential hotspots while thinking they remain on the secure corporate network, exposing their traffic to the hotspot owners – ordinary people with no data oversight.
Data shows Luxembourg uses a similar setup, leaving employees of luxfuturelab.lu vulnerable to being redirected to consumer citiwifi hotspots.
How to defend against SSID Confusion attacks
There are three potential defenses, requiring changes at the level of the WiFi protocol itself, clients, and user behavior.
WiFi standard improvements
The most reliable defense would be to update the 802.11 WiFi standard to mandate authentication of the SSID when connecting to a protected network.
Two potential changes are proposed:
- Always include the SSID in key derivation during the 4-way handshake when connecting to protected networks, in a similar way to how the Fast Transition (FT) protocol handles it.
- Include the SSID as additional authenticated data in the 4-way handshake, allowing clients to securely verify the network name.
The second option provides a backward-compatible approach by encapsulating the SSID in a new Information Element for the handshake’s authenticated data.
Old clients would ignore this element while new clients would use it to securely verify the SSID.
These changes would eliminate the vulnerability while preserving compatibility across devices and networks.
WiFi Client Improvements
At the client level, improvements to beacon protection would help defend against SSID Confusion attacks.
WiFi 7, which was launched in January 2024 but will take many years before widespread adoption, does already mandate support for beacon protection.
Unfortunately the current implementation of beacon protection is flawed as clients fail to authenticate beacons received before connecting, even after obtaining the beacon integrity key during the handshake.
Even if beacon protection causes the client to disconnect from the “wrong” network due to beacon loss, there will have been at least a few seconds of vulnerability to traffic interception.
The proposed improvement is to let the client store a reference beacon containing the network’s SSID and verify its authenticity during the 4-way handshake.
After receiving the beacon integrity group key in message 3, the client can authenticate the previously captured reference beacon. If successful, the handshake completes; otherwise, it aborts.
However, the beacon key might change between capturing the reference beacon and receiving the key, causing handshake failure. Potential solutions include:
- Access points transmit previous keys, but this requires modifying AP functionality.
- Clients wait for a new beacon, verify its authenticity, and compare it to the reference beacon. This avoids protocol changes but may cause noticeable delays as beacons typically arrive every 102.4ms.
- Immediately complete the handshake and verify the SSID of the first beacon and disconnect if it doesn’t match. While preventing connection delays, attackers could block legitimate beacons, leaving clients vulnerable until disconnecting due to beacon loss.
The second option, though introducing delays, is the most straightforward as it only requires patching clients without protocol or major network configuration changes.
A notable limitation of the proposed improvements to beacon protection is that they do not prevent an attack against a hidden network.
As hidden networks omit the SSID from beacons, beacon protection cannot reliably secure the SSID’s disclosure.
Avoiding credential re-use
Networks can mitigate the attack by avoiding credential reuse across SSIDs.
Enterprise networks should use distinct RADIUS server CommonNames, while home networks should use a unique password per SSID.
However, the trade-off is reduced usability when a network uses separate SSIDs for 2.4GHz and 5GHz bands, as each would then require different credentials.
Proper VPN use
Habitually using a VPN while connecting to WiFi will greatly mitigate the consequences of this attack, as the encrypted tunnel will prevent the adversary from intercepting traffic even after successfully executing the attack.
However, it’s critical that the VPN connection is configured to remain active at all times, regardless of whether a network is trusted or not.
For a full technical analysis and all relevant background, download the SSID Confusion: Making Wi-Fi Clients Connect to the Wrong Network report authored by Mathy Vanhoef and Héloïse Gollier.
