CVE-2023-52424 WiFi Vulnerability: The SSID Confusion Attack

This vulnerability exploits a design flaw in the WiFi standard, allowing attackers to trick WiFi clients on any operating system into connecting to a untrusted network.
Header illustration for SSID Confusion WiFi Vulnerability Report
Simon Migliano

A new vulnerability arising from a design flaw in the WiFi standard allows attackers to trick victims into connecting to less secure networks and intercept their traffic.

Additionally, the attack can exploit the auto-disconnect feature in certain VPN clients, which automatically disables the VPN connection when the device connects to a predefined “trusted” WiFi network.

Top10VPN has teamed up with highly-experienced security researcher Mathy Vanhoef to share this WiFi vulnerability ahead of its presentation at the WiSec ’24 conference in Seoul.

Vulnerability Details:

  • Nature of vulnerability: An SSID Confusion attack on enterprise, mesh, and some home WiFi networks, due to a flaw in the IEEE 802.11 standard.
  • Affected software: All WiFi clients
  • Affected platforms: All operating systems
  • Impact:
    • Allows an attacker to trick a victim into connecting to a different network with a spoofed network name (SSID), if there is credential reuse, leaving them vulnerable to traffic interception and manipulation.
    • Any VPN with the functionality to auto-disable when connected to trusted networks will be fooled into turning itself off.
    • 6 universities identified so far (including institutions in UK and US) where staff and students are particularly at risk due to credential re-use.
  • Identifier: CVE-2023-52424

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:

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, 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 app

Screenshot of auto-disable on trusted network from Cloudflare 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 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:

  1. 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.
  2. 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:

  1. Access points transmit previous keys, but this requires modifying AP functionality.
  2. 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.
  3. 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.

SSID Confusion Attack Video

Prof Vanhoef demonstrates the SSID Confusion attack that forces a downgrade to an untrusted WiFi network.

Attack Details

In the following diagram you can see the different stages of the SSID Confusion Attack, which are explained in more detail below.

Diagram illustrating details of the SSID Confusion Attack

Diagram illustrating details of the SSID Confusion Attack.

Attack overview

The SSID Confusion attack allows an adversary to trick victims into connecting to a malicious WiFi network by exploiting flaws in how WiFi devices validate the network name (SSID) during connection setup.

It has three stages:

  1. Network Discovery
  2. Authentication Hijacking
  3. Ongoing Man-in-the-Middle

Attack Walkthrough

Here’s how the SSID Confusion attack works in more detail:

Initial Setup

The adversary sets up a rogue access point (“WrongAP” in the diagram) on a different channel to the target “wrong” network (“WrongNet” in the diagram) that they want the victim to connect to and uses it to advertise WrongNet.

WrongAP, which could easily be created on a standard laptop, is then used to create a multi-channel man-in-the-middle (MC MitM) between the victim and WrongNet.

The MC MitM array is then used to perform the three-stage attack.

Stage 1: Network Discovery

In the first stage of the attack, the MitM array intercepts the WiFi packets sent by the real AP (“TrustedNet” in the diagram) and the victim’s WiFi software as part of normal network discovery.

The attacker modifies these frames to switch the SSIDs of the trusted and untrusted networks before forwarding them on to their original destinations.

As a result, the victim’s device sees responses suggesting the trusted network is nearby, even though it’s the adversary’s rogue AP impersonating it.

Stage 2: Authentication hijacking

This stage of the attack involves fooling the victim’s WiFi client into successfully authenticating WrongNet and connecting to it as if it were TrustedNet.

The adversary intercepts frames sent by the victim’s WiFi client as part of the authentication process and rewrites the SSID from TrustedNet to WrongNet before forwarding them to the real AP so that authentication can be completed.

The specifics of what happens next depends on the protocol being used but as long as the SSID is not used as part of the PMK derivation process (see above), the attack will succeed.

Stage 3: Ongoing MitM

The final stage is an ongoing MC MitM attack that intercepts all traffic between the victim’s device and the AP and rewriting frames in real-time to change the SSID from WrongNet to TrustedNet so that client keeps thinking they are connected to the trusted network.

VPN Impact

Some VPN clients automatically disable the VPN connection when connecting to “trusted” WiFi networks specified by their SSID.

A successful SSID Confusion attack can trick these VPNs into disabling, exposing the user’s traffic.

At this point, the traffic can be inspected and man-in-the-middled by the WrongNetwork network operator.

Attack Variants

Prof Vanhoef and Gollier also discovered a stealthier variation of the attack that takes advantage of how most clients stop verifying the SSID after the initial connection.

Most clients stop checking the advertised WiFi network name (SSID) in beacons after initially connecting. This allows the attacker to simply be present during the victim’s initial connection and then change the SSID being broadcast, while the victim remains connected to the malicious network.

Testing confirmed that clients universally failed to continuously validate the SSID, allowing this optimized attack variant to stealthily man-in-the-middle anytime simply by being temporarily present during the initial WiFi association.

This persistent lack of client-side SSID checking once associated dramatically decreases the effort and timing constraints for attackers to carry out WiFi hijacking attacks.

About Top10VPN's Security Research

Mathy Vanhoef is a security researcher whose major discoveries have included Dragonblood, KRACK Attack and TunnelCrack.[1][2][3]

He is also a professor in the DistriNet (Distributed Systems and Computer Networks) research group of the Department of Computer Science at KU Leuven, Belgium.

At Top10VPN, we only work with carefully vetted external researchers and ensure the applicable parts of our Responsible Disclosure Policy are followed at all times.

The identified vulnerability, stemming from a flaw in the WiFi standard itself, has been reported to the WiFi Alliance. However, updating the standard can take several years.

Making the research public makes it easier to update the standard and for everyone to give feedback and agree on a solution.

In the meantime, organizations and individuals can prevent the attack by tweaking their network configurations based on the suggestions in this report.

The authors of all our investigations abide by the journalists’ code of conduct.