The SSID Confusion Attack: Common Misconceptions

We've spotted some confusion about the SSID confusion attack. First, it's by no means something to panic about, but it's nice research to make one think about threat models. To address some common misconceptions:

The adversary doesn't need to know the pre-shared secret. The SSID Confusion attack can cause a victim to connect to a different SSID, as long as that SSID uses the same credentials as another SSID. However, the adversary doesn't need to know these credentials. After all, if the adversary, for instance, already has access to the password of a home network, they could simply perform a generic man-in-the-middle attack by spoofing the real SSID.

The adversary doesn't need access to the RADIUS server. To execute this attack against an Enterprise network, the adversary doesn't require any access to the RADIUS server. The attack doesn't require any Enterprise network credentials—no usernames, passwords, certificates, or RADIUS access. The adversary is always an outsider. Having some kind of additional access can increase the impact of the attack though. For example, in Section 4.3, the adversary is also assumed to have the capability to obtain the Wi-Fi decryption keys from a hotspot. However, even in this scenario, direct access to the RADIUS server is not required—only access to the Pairwise Master Key (PMK) is needed.

The attack applies to most, if not all, EAP methods. The attack isn't limited to MS-CHAPv2; it applies to all EAP methods. In the paper, we mentioned MS-CHAPv2 and EAP-PWD because they are often used by eduroam networks. Note that based on scraped public configuration profiles, MS-CHAPv2 is still the most common EAP method for eduroam networks.

The 2.4 GHz band can support management frame protection. Previous surveys (i.e., wardrives) of over 250,000 networks have found that, on average, 2.4 GHz networks are less likely to use management frame protection. So 2.4 GHz networks can certainly support management frame protection, but it's less common in practice compared to 5 GHz networks, especially on networks that only broadcast on the 2.4 GHz band.

Typically, the same equipment advertises 2.4 and 5 GHz SSIDs. Usually, the same router or access point advertises both the 2.4 and 5 GHz SSIDs. As we'll further discuss below, it's therefore less common for the 2.4 and 5 GHz SSIDs to have different security settings. However, previous research has found that this does occasionally occur. In particular, a separate SSID for the 2.4 GHz band can be created for backwards compatibility, in which case management frame protection is then also disabled to further enhance backwards compatibility.

Security of 2.4 vs. 5 GHz networks. The attack can make a client connect to the 2.4 GHz SSID of a network, even if the client is configured to connect only to the 5 GHz SSID. This might not seem useful, but real-world measurements have shown that the 2.4 GHz SSID is often less secure and more vulnerable to older attacks. That being said, due to the point discussed above, this difference in security is lower for networks that support both the 2.4 and 5 GHz band. Nevertheless, even for networks that support both 2.4 and 5 GHz, it does occasionally occur that the 2.4 GHz band is less secure, as mentioned above.

What's the real lesson? The most interesting part of the paper is not its practical impact. Given the specific threat model, I don't expect many real-world attacks. However, it highlights the importance of considering threat models. In particular, it shows that only verifying credentials without checking the SSID can impact security. Additionally, it highlights that some Enterprise networks with different purposes and different SSIDs, may actually share the same RADIUS server and security configuration. These scenarios may not be typical, but they represent how some use Wi-Fi in practice. We should consider these use cases or at least warn about their potential insecurity!

Making the Cloudflare WARP VPN leak DNS requests

Cloudflare offers a free VPN client called Cloudflare WARP. I found that its Windows client can be tricked into leaking all DNS requests. The adversary can then spoof DNS responses and intercept nearly all traffic.

To exploit the vulnerability, the adversary needs to create a rogue Wi-Fi or Ethernet network that supports IPv6. When the local network supports IPv6, all DNS requests are leaked.

Why are DNS requests leaked?

When you enable the VPN tunnel, the Cloudflare WARP client will configure a local DNS server. This can be seen when executing ipconfig:

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : cs.kuleuven.be.
   [..]
   DNS Servers . . . . . . . . . . . : fd01:db8:1111::2
                                       fd01:db8:1111::3
                                       127.0.2.2
                                       127.0.2.3
   NetBIOS over Tcpip. . . . . . . . : Enabled

The idea is that the Cloudflare WARP client will act as a local DNS server. This local DNS server will perform the actual DNS requests in a secure manner. For IPv4, the special IP addresses 127.0.2.2 and 127.0.0.3 are configured as the DNS server. These IP addresses refer to the Windows computer itself (they're called loopback addresses). So when the network only supports IPv4, these loopback IP addresses are used for the DNS server, and all DNS requests are handled by the Cloudflare WARP client. The WARP client will then securely handle the DNS requests. So everything works as expected when using IPv4.

The Cloudflare WARP client also configures the IPv6 addresses fd01:db8:1111::2 and fd01:db8:1111::3 as DNS servers. When the local network supports IPv6, these addresses will be used. But these are not loopback addresses referring to the Windows machine itself! These special are Unique Local Addresses (ULAs). This means they behave the same as private IPv4 address of the form 192.168.x.y. In other words, these two IPv6 addresses represent random computers in the local network. They don't represent the Windows computer itself.

All combined, the Cloudflare WARP client is configuring two random IPv6 computers in the local network as DNS servers. Namely, the computers fd01:db8:1111::2 and fd01:db8:1111::3 are configured as DNS servers. So a rogue Wi-Fi network simply needs to advertise support for IPv6, assign itself the IPv6 address fd01:db8:1111::2, and then it will receive all DNS requests:

The leakage of DNS requests has a direct impact on the user's privacy: you can now see which websites the victim is visiting, which apps are being used, and so on.

But there's more: once the adversary can intercept DNS requests, they can also spoof DNS responses. And by doing so, the adversary can easily intercept nearly all IP-based traffic of the victim! For instance, if the victim is looking up the IP address of website.com the adversary can return the IP address of their own server. When the victim now visits this website, all traffic will be sent to the adversary's server (and the adversary can forward it to the real server and back). If the website uses HTTPS then traffic is still protected, but the VPN itself is now completely bypassed, and all unprotected protocols can be subsequently attacked.

The severity was rated as High. This matches the CVSS score of 7.4: it doesn't require user interaction and has a high attack complexity. Intuitively, I would actually say it has a low attack complexity. But CVSS has the following example for high attack complexity: "The attacker must inject themselves into the logical network path [..] e.g., a man in the middle attack". And exploiting the vulnerability essentially requires a MitM position.

Another harder-to-exploit flaw

A second issue was that the Clouldflare WARP client only updated the DNS servers of the first two network interfaces. If you have more than two network interfaces, the DNS servers associated to these extra network interfaces didn't get changed. This means a rogue Wi-Fi network could assign itself as the DNS server, and if the victim has more than two network interfaces, Windows would use the adversary's Wi-Fi router as the DNS server! This happened even when the local network only supported IPv4.

Having multiple network interfaces can occur more often than you think. For instance, if the victim installed VirtualBox, then a virtual network interface is created and the attack becomes possible.

To patch this initial vulnerability, the Windows client was updated to assign the DNS servers 127.0.2.2 and 127.0.0.3 to all network interfaces. Interestingly, it was no longer assigning IPv6 addresses for the DNS server. So that patch, without us really realizing it yet, also prevented the above IPv6-based attack.

All combined, these two vulnerabilities were fixed in beta build 2023.5.170.1 which was made available on May 12, 2023. The first official release that included the fix was version 2023.7.7.0 which was released on July 7, 2023.

Discussion

I first noticed the "multiple-interfaces DNS leakage" flaw and immediately reported that. While doing so, I already saw some weird IPv6 behavior, but I didn't have time to investigate it. Afterwards I also checked the IPv6 issue and also discovered this more impactful attack.

Finally, I'd like to thank Cloudflare for the smooth handling of this vulnerability and disclosure.

FragAttacks: Clarifying Some Aspects

If you haven't yet read about this research then watch my USENIX Security presentation:

In this blog post I'll discuss some aspects in more detail than I could in the paper.

Addressing general misconceptions

• None of the flaws are in the cryptographic primitives used by Wi-Fi. In other words, we're not attacking RC4 or SHA1. The design flaws are instead at the intersection of crypto and protocol design, which people colloquially refer to as "the encryption used in Wi-Fi". In other words, the encryption of Wi-Fi is still being broken and in some cases bypassed.
  
• The aggregation design flaw (CVE-2020-24588) can be abused to make receivers process a normal frame as if it were an aggregated frame. It cannot be abused to force a device to aggregate frames.
• Both clients and Access Points (APs) are affected. Some flaws are more common in clients, while others are more common in APs.

Being within range

Just like practically all Wi-Fi vulnerabilities, you need to be in proximity of the victim to exploit the discovered flaws. Put differently, as the second line of the FragAttack website states: "an adversary that is within range of a victim's Wi-Fi network can abuse these vulnerabilities".

This doesn't mean the adversary has to be right next to the target network. A simple external antenna can be used to receive a Wi-Fi signal up to one kilometer. In leaked documents the NSA even claims that a range of more than 12 kilometers is possible, though that extreme range is only possible in perfect conditions.

Antenna made by Matt Parkinson.

Easy or hard to abuse? Why not both!

The design flaws are, on their own, hard to exploit. To quote the FragAttacks website: "the design flaws are hard to abuse because doing so requires user interaction or is only possible when using uncommon network settings. As a result, in practice the biggest concern are the programming mistakes in Wi-Fi products". This echoes the conclusion in the paper: "our implementation-specific vulnerabilities are the most devastating".

So it's the implementation flaws we have to worry about. Why? Because exploiting some of them is absolutely trivial: an adversary that is within proximity of the target network can then simply inject plaintext frames. It cannot get any easier than that. In fact, one can argue that this is even easier than exploiting the horribly broken (and ancient) WEP protocol.

It gets more complicated when design flaws are combined with implementation flaws. The biggest example is when the aggregation design flaw (CVE-2020-24588) in clients is combined with implementation flaw CVE-2020-26139 in access points. In this scenario, the aggregation design flaw can be exploited without user interaction (i.e. without social engineering). That means the adversary merely has to be within range of the target network. Section 6.6 in the paper discusses this in further detail and the presentation also briefly covers this.

As further context I've also created a short overview with attacks and their preconditions. A quick way to determine whether it's important to immediately patch a device is to see whether it's affected by any of the CVEs that allow plaintext injection.

Applicability to the old WEP and TKIP protocols

The paper describes the impact of the vulnerabilities on the latest standards such as WPA2 and WPA3. For completeness, it also briefly discusses WEP and TKIP to confirm that some of these vulnerabilities have existed for a long time. It's hopefully clear though, as also indicated in the paper, that WEP and TKIP should no longer be used :) They're both insecure, old, and deprecated by the Wi-Fi Alliance.

Image from Musheera Mirani.

Do attackers need to know the password of the network?

Some have asked me whether any of the attacks require knowing the pairwise transient keys (PTK) or group key (GTK) of the victim. That's not the case. If an attacker knows the PTK it means Wi-Fi security has already been broken: the adversary can use the PTK to passively decrypt all data. All the attacks work without knowing the password of the network.

The cache attack (CVE-2020-24586) does have a more exotic threat model. When an AP is vulnerable, this flaw can be exploited in Hotspot 2.0 or Enterprise networks, as long as the adversary also has credentials that are needed to connect to this network. But even in this threat model the adversary does not know the PTK of the victim! And the adversary also does not know the credentials of the victim. Finally, when a client is vulnerable to the fragment cache attack, it can only be exploited when the client first connects to the adversary's network, and subsequently connects to the target network. This threat model to exploit CVE-2020-24586 in a client is currently a theoretic threat model and you can ignore it in practice.

Two types of hotspots: the less secure and more secure ones

The fragment cache design flaw can only be abused against hotspots. It's important to note that there are two kinds of hotspots: the traditional coffee-shop hotspot and the new Hotspot 2.0. This difference is touched upon in Section 5.1 of the paper. The coffee-shop hotspots are normal home networks where the password of the network is shared publicly among customers. And you can think of Hotspot 2.0 networks as special enterprise networks where users are automatically provided unique credentials (for more details see Section 2.4 in the paper). The coffee-shop hotspots are less secure because an adversary can set up a rogue clone of the hotspot and intercept traffic. The Hotspot 2.0 networks are more secure because the authenticity of the network is verified (meaning a rogue clone cannot be created by an adversary).

To exploit APs that are vulnerable to the fragment cache vulnerability, we target Hotspot 2.0 networks. To exploit clients that are vulnerable to the fragment cache vulnerability, the attack makes use of traditional coffee-shop hotspots. In other words, these two types of hotspots are abused under different circumstances.

 

Hotspots 2.0 vs. the fragment cache of access points

Let's first focus on Hotspot 2.0 security and enterprise networks. In these networks users may distrust each other. This is the easiest to explain in hotspot networks: I don't know who the other users are and I don't trust them. The same can be true in enterprise networks such as Eduroam, a network used by universities worldwide. With Eduroam, someone from university A can visit university B and connect to the eduroam network using the credentials of their home network. Awesome! But I don't trust researchers from other universities though. Unfortunately, these visitors can connect to the same network that I'm using. In fact, they can connect to exactly the same access point that I'm connected to. But I don't trust them!

The above situation doesn't have to be problematic. By using client isolation, downstream group-addressed forwarding, and a proxy ARP service, clients are unable to attack each other (see the Hotspot 2.0 spec). Note that in these networks each client uses their own unique credentials (e.g. username and password) to access the network and that an adversary cannot impersonate the eduroam network (i.e. the network is authenticated while connecting). However, the observation that distrustful users connect to the same access point in these hotspots, forms the basis of how the fragment cache vulnerability (CVE-2020-24586) is abused against access points. In particular, the visitor/attacker from the other university can connect to the same access point that I'm using, inject a malicious fragment into the fragment cache of the AP, which can then be abused to attack me. In practice, this can be abused to exfiltrate data that I'm sending, at least when my device is sending fragmented Wi-Fi frames (which is uncommon unless Wi-Fi 6 is used).

Secure Wi-Fi hotspots are becoming more common!

Hotspots vs. the fragment cache of clients

Exploiting the fragment cache design flaw (CVE-2020-24586) against clients is trickier. The paper discusses a scenario where this is made possible by relying on traditional coffee-shop hotspots. Briefly summarized, the adversary clones the coffee-shop hotspot using a spoofed BSSID, and the victim connects based on the real SSID. Then a malicious fragment is injected into the fragment cache of the client. This attack is academic and will be discussed in another blog post in more detail. In any case, I'm not worried about it in practice. Just remember that when abusing the fragment cache design flaw against a client the attack relies on traditional hotspots, while abusing the fragment cache design flaw against an access point targets Hotspot 2.0 and/or enterprise Wi-Fi networks.

Doesn't matter which EAP authentication method is used

All attacks are possible no matter how the client authenticates the network. In other words, attacks are identical against home and enterprise networks. Moreover, it doesn't matter which EAP method you use in an enterprise network: all attacks are possible and work exactly the same way no matter which EAP method is used.

Note that the paper briefly mentions an experiment with EAP-PWD. With this EAP method you don't have to configure certificates which makes it easier to do a quick experiment with EAP-PWD. Nevertheless, attacks were also tested when using other EAP methods, but this wasn't explicitly mentioned in the paper as those experiments were performed at a later point in time.

I do have a hunch why some wrongly claimed that attacks are prevented by using EAP. In particular, this is likely caused by a misunderstanding of how some attacks require a machine-in-the-middle position. This leads me to the next clarification!

Multi-Channel MitM vs. Rogue AP

Abusing the design flaws, on their own, is not trivial (in contrast to the implementation flaws which can be trivial to exploit). One of the requirements is that the adversary must be able to block and modify encrypted Wi-Fi frames. In my experiments, I accomplished this by using a multi-channel machine-in-the-middle position. This is not a typical rogue AP though! Instead, the attacker is copying all frames from the real AP to a different Wi-Fi channel, and this is used to reliably block and modify encrypted frames. Copying frames between different channels can be done no matter how the client authenticates the network. How this multi-channel MitM works is further explained in an old blog post and is also discussed in the operating channel defense paper.

To further clarify: the multi-channel MitM doesn't break encryption. This MitM position is only used to reliably block or modify encrypted frames and this MitM can be established no matter what authentication or EAP method is used. In other words, mutual authentication EAP types don't prevent this MitM and won't prevent the exploitation of the discovered vulnerabilities.

Side remark: a few years ago I collaborated with the industry to standardize a defense that makes it much harder to establish this MitM position. Hopefully, if this defense eventually gets implemented in practice, it will make it harder to exploit new (currently unknown) vulnerabilities in Wi-Fi.

In a multi-channel MitM frames are copied between two channels [source].

Using 802.11w doesn't make attacks harder

Using 802.11w, also known as management frame protection, has no impact on any of the attacks. Even attacks that rely on the multi-channel machine-in-the-middle position (i.e. the design flaws and CVE-2020-26146) remain possible when using 802.11w. This is because this MitM isn't established by sending deauthentication or disassociation frames to first disconnect the client from the network. Instead, to establish this MitM, the attacker forces the client to switch to another channel (see the section above). This is accomplished by spoofing beacon frames that contain malicious Channel Switch Announcements. These beacon frames can be spoofed even when 802.11w is enabled, meaning that enabling 802.11w won't make attacks harder.

Collaboration with Wi-Fi companies

Finally, I'd like to thank everyone that helped during the embargo, especially all the people that went out of the way to ask questions, either directly or through the Wi-Fi Alliance, to understand all aspects of the research. I realize that academic papers are dense and not always the easiest to understand, so whenever possible I will gladly try to clarify things.

Finally, do try out the test tool, and happy hacking testing! =)