Thursday 10 August 2023

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  . :
   DNS Servers . . . . . . . . . . . : fd01:db8:1111::2
   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 and 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 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 and 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.


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.

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

Update 30 November '21: if you simply want to anonymize your GitHub repository and are OK with it being public, then consider using


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

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 "Paper 1"
    git config ""

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.