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.
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.
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).
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.
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