Tuesday, 18 May 2021

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! =)

Saturday, 12 September 2020

Providing source code when submitting papers: how to give anonymous but protected access

When submitting an academic paper for review, it is often a good idea to provide access to the research code as well. Even if reviewers only rudimentary scroll through the code, it shows you are committed to releasing the code once the paper is published.

The problem is that often you want to provide reviewers anonymous access to your code, but don't want the code to be accessible publicly. In this blog post, I'll explain how to provide read-only (anonymous) access to a GitLab repository. The end result is that you can instruct reviewers to execute the following command:

git clone https://gitlab.com/anongroup/anonproject.git

where they use the token "anonymous" as the username and a generated password. This token provides read-only access and can easily be revoked if needed (this login info isn't a GitLab account). You can easily include these instructions in a paper, giving reviewers access to the code without revealing your GitLab username in the URL, and while protecting access to the code using a password.

How to configure this in practice?

First, to assure the git URL won't contain your username, you have to create a new group on GitLab with an anonymous name. The name of this group will replace "anongroup" in the above example URL.

Second, in this group create a new project (i.e. repository) with an anonymous name. The name of this project will replace "anonproject" in the above example URL. You will now have a git URL containing only anonymous identifiers.

Finally, to provide read-only access to this repository, open the repository, go to Settings, and then to Repository. Then create a Deploy Token and select that the token provides read-only access. For the username we'll pick "anonymous". Then configure when the token expires: make sure it stays valid during the complete review process! Finally, click on "Create deploy token", and GitLab will automatically generate a password for this token.

Viola! The resulting token can only be used to clone the repository. Note that this token cannot be used to log into GitLab and view the repository in a browser. This token can only be used to directly clone the git repository using, for example, the command above.

Remember to create commits under an anonymous identity as well! That can easily be done using:

    git config user.name "Paper 1"
    git config user.email "anon@mail.com"

The configured name and email will only be used in the git repository you are currently in. A final tip is to include a README file in the repository, which can for example be written in Markdown and then converted to HTML.

Friday, 24 July 2020

Protecting Wi-Fi Beacons from Outsider Forgeries

We recently presented the paper Protecting Wi-Fi Beacons from Outsider Forgeries at the WiSec 2020 conference. You can view the recorded presentation on YouTube:



After the presentation we received a lot of interesting question, and it's useful to discuss these in more detail. So let's dig into some of the details of our work!

How does beacon protection handle hidden networks?


A hidden network still sends out beacon frames just like a normal network. The only difference with a hidden network is that its beacons do not contain the SSID of the network. As a result, all our attacks apply to hidden networks as well. Additionally, our defense works exactly the same for hidden networks.

Did you observe any clients recover from attacks after they received a beacon from the real AP?


In our attacks we spoof beacons to influence the behavior of clients. We found that with some attacks, such as those manipulating the throughput of clients, the effects of the attack are reset when the victim receives a real beacon (after we injected a spoofed one). In this specific case however, we found a way to make the effect permanent, and I refer to the second paragraph of section 3.3 in our paper on how we accomplished that.

Additionally, our transmission power attack did not work against all operating systems, and this might be because these devices reset their behavior back to normal when receiving a real beacon.

What makes certain devices more vulnerable than others?


Certain devices or operating systems may not support all features that are advertised in a beacon, and therefore they may not be affected.

Another reason why some devices are not affected to certain attacks is because they do not constantly track all information in a beacon. Put differently, some devices initialize parameters when they connect to the network, and will not update these parameters while being connected. As a result, if we spoof a beacon with different parameters, these updated values will simply be ignored.

What are the differences between beacon protection and Management Frame Protection of 802.11w?


We purposely designed beacon protection to be similar to Management Frame Protection. In particular, they both use the same underlying cryptographic primitives. This will hopefully simplify implementations and encourage vendors to adopt our defense.

Unfortunately, Management Frame Protection did not authenticate beacons and left them unprotected. In order to also protect beacons we cannot simply protect them in exactly the same way though: several edge cases have to be handled differently. This is discussed in more detail in section 4 of the paper. For example, care is needed when handling "Multiple BSSID" beacons, we need backwards compatibility, we added a capability to report rogue APs, and we are using a new beacon protection key.

Why do we need a new key? Why not use the same key used by Management Frame Protection?


Using the same key will only be secure if the same nonce (i.e. replay counter) will never be reused. This would imply using the same replay counter for beacons and other broadcast management frames. Unfortunately, this is surprisingly hard to implement: in practice the Wi-Fi chip may reorder beacons and broadcast management frames right before their transmission (after they were authenticated!). Preventing this is non-trivial. Unfortunately, we also cannot use two different replay counters under the same key, because they would again result in nonce reuse. All combined, the easier solution in practice is to generate a second key.

Have you thought about clients maliciously reporting fake beacons even if there aren't any?


We only prevent outsider attacks, so an insider can indeed maliciously report fake beacons. The impact of this is likely low though. The idea behind reporting fake beacons is that the network administrated is aware that something fishy is going on in the network (e.g. someone setting up rogue APs). So maliciously reporting fake beacons will annoy the network administrator, but other than that will likely have no impact.

In practice we can also consider fake beacon reports valid if multiple clients send a report. Additionally, in an enterprise network such as Eduroam, the network administrator can determine the username of the device that reported a fake beacon. This means such misbehaving insiders can be issued a warning or even banned from the network.