Introduction

8 August 2023 — This website presents TunnelCrack, a combination of two widespread security vulnerabilities in VPNs. Although a VPN is supposed to protect all data that a user transmits, our attacks can bypass the protection of a VPN. For instance, an adversary can abuse our vulnerabilities to leak and read user traffic, steal user information, or attack user devices. Our tests indicate that every VPN product is vulnerable on at least one device. We found that VPNs for iPhones, iPads, MacBooks, and macOS are extremely likely to be vulnerable, that a majority of VPNs on Windows and Linux are vulnerable, and that Android is the most secure with roughly one-quarter of VPN apps being vulnerable.

The discovered vulnerabilities can be abused regardless of the security protocol used by the VPN. In other words, even VPNs that claim they use "military grade encryption" or that use self-developed encryption protocols can be attacked. The root cause of both vulnerabilities has been part of VPNs since their first creation around 1996. This means that our vulnerabilities went unnoticed, at least publicly, for more than two decades.

Our first set of vulnerabilities, called LocalNet attacks, can be exploited when a user connects to an untrusted Wi-Fi network. Our second set of vulnerabilities, called ServerIP attacks, can be exploited by untrusted Wi-Fi networks and by malicious Internet service providers. Both attacks manipulate the victim's routing table to trick the victim into sending traffic outside the protected VPN tunnel, allowing an adversary to read and intercept transmitted traffic.

To protect users, security updates were prepared during a 90-days coordinated disclosure in collaboration with CERT/CC and various VPN vendors. Some example patched VPNs are Mozilla VPN, Surfshark, Malwarebytes, Windscribe (can import OpenVPN profiles), and Cloudflare's WARP. If updates for your VPN are not available, you can mitigate the LocalNet attack by disabling local network access. You can also mitigate attacks by assuring websites use HTTPS, which many websites nowadays support.

Our research will be presented at the USENIX Security conference on 11 August 2023. The research was carried out by Nian Xue (New York University), Yashaswi Malla, Zihang Xia, Christina Pöpper (New York University Abu Dhabi), and Mathy Vanhoef (KU Leuven University). You can contact Mathy Vanhoef for any questions.

Demo

The video below shows three examples of how an adversary can abuse the discovered vulnerabilities. First, the LocalNet attack is abused to make the victim leak traffic. This is used to intercept sensitive info sent to insecure websites, e.g., the victim's username and password is leaked. We also show how an adversary can identify which websites someone is visiting, which is normally not possible when using a VPN. Finally, a variant of the LocalNet attack is abused to block a security camera from notifying the user of unexpected movements.

As the demo illustrates, the VPN flaws can be abused to trivially leak traffic and identify the websites that someone is visiting. Additionally, any data sent to improperly configured websites, or sent by insecure apps, can be intercepted.

Users can defend themselves by updating their VPN software. Additionally, when a website is properly configured with HSTS to always use HTTPS as an extra layer of security, which nowadays around 25% of websites are, any transmitted data cannot be stolen. Moreover, several browsers now warn the user when HTTPS is not being used. Finally, although not always perfect, modern mobile apps by default use HTTPS and therefore also use this extra protection.

Apart from targeting websites, another risk is that VPNs are often used to protect older or insecure protocols. Our attacks now enable an adversary to remove the protection offered by a VPN, meaning adversaries can subsequently attack any older or insecure protocols used by the victim, such as RDP, POP, FTP, telnet, and so on.

Details

Background and core idea

The core idea behind our attacks is to manipulate the VPN client into sending traffic outside the protected VPN tunnel. By doing so, the victim's traffic can be read and intercepted. Under normal conditions, the client’s routing table assures that all traffic will be sent, i.e., routed, through the protected VPN tunnel. However, many VPN clients add exceptions to send the following two types of traffic outside the VPN tunnel:

  1. Traffic sent to and from the local network; and
  2. Traffic sent to and from the VPN server.

The first routing rule assures that the local network remains accessible while using the VPN, meaning the user can enable the VPN while simultaneously printing files, performing screen casting to their TV, and so on. The second routing rule assures that there is no routing loop, i.e., that already-encrypted VPN packets do not undergo encryption again. Unfortunately, we discovered that an adversary can manipulate these routing exceptions such that arbitrary traffic will be sent outside the VPN tunnel.

In our LocalNet attacks, the adversary acts as a malicious Wi-Fi network and pretends that websites and Internet servers are directly reachable in the local Wi-Fi network. This causes traffic leakage due to the "send local traffic outside the VPN tunnel" rule. In our ServerIP attacks, an adversary changes, i.e., spoofs, the IP address of the VPN server. This causes traffic leakage due to the "send traffic to the IP address of the VPN server outside the VPN tunnel" rule.

LocalNet Attacks

In the LocalNet attack, the adversary acts as a malicious Wi-Fi or Ethernet network, and tricks the victim into connecting to this network. An easy way to accomplish this is by cloning a popular Wi-Fi hotspot such as "starbucks". When a victim connects to this malicious network, the adversary assigns a public IP address and subnet to the victim. The figure below shows an example of this, where the adversary's goal is to intercept traffic towards the website target.com:

In the above figure, the website target.com has the IP address 1.2.3.4. To intercept traffic to this website, the adversary tells the victim that the local network is using the subnet 1.2.3.0/24. In other words, the victim is informed that IP addresses in the range 1.2.3.1-254 are directly reachable in the local network. When the victim now visits target.com, a web request will be sent to the IP address 1.2.3.4. Because the victim thinks that this IP address is directly reachable in the local network, it will send the web request outside the protected VPN tunnel.

An adversary can also assign larger subnets to the local network to leak nearly all of the victim's traffic. Additionally, although the main goal of the LocalNet attack is to leak traffic outside the VPN tunnel, the attack can also be abused to block selected traffic while the VPN is being used (see our paper for details) .

We tested more than 66 VPN apps on five platforms and found that all VPN apps on iOS are vulnerable. Additionally, all but one VPN client on macOS is vulnerable, on Windows a large majority of VPNs are vulnerably, and on Linux more than one-third are vulnerable. Interestingly, VPN apps on Android are typically the most secure, with one-quarter being vulnerable to the LocalNet attack. We conjecture that this is because Android has a more carefully designed API to create VPN apps.

To defend against the attack, the VPN app should automatically disable local network access when the local network is using public IP addresses. On most platforms this can be easily implemented. On iOS this can be done by using the includeAllNetworks and excludeLocalNetworks APIs, unfortunately, using these APIs may cause reliability issues, making some vendors hesitant to adopt this defense on iOS. Ideally, Apple should create a more robust API for VPNs on iOS, so that VPN apps can be implemented in a ore secure and reliable manner.

ServerIP Attacks

In the ServerIP attacks, the attacker must be able to spoof DNS replies before the VPN is enabled, and must be able to see traffic to the VPN server. Similar to the LocalNet attacks, this can be accomplished by acting as a malicious Wi-Fi or Ethernet network. The attacks can also be carried out by a malicious ISP or compromised core Internet router.

The core idea is that the adversary spoofs the IP address of the VPN server. For example, if the VPN server is identified by the hostname vpn.com and its real IP address is 2.2.2.2, then the adversary can spoof the DNS response to have a different IP address. The following figure shows an example of this, where the adversary's goal is to intercept traffic towards target.com which has the IP address 1.2.3.4:

The adversary first spoofs the DNS reply for vpn.com to return the IP address 1.2.3.4, which equals the IP address of target.com. In other words, we spoof the IP address that we want to leak traffic towards. The victim will then connect with the VPN server at 1.2.3.4. To assure the victim still successfully creates a VPN connection, the adversary redirects this traffic to the real VPN server. As a result, even though the victim is using the wrong IP address for the VPN server, the VPN tunnel is still successfully created. Moreover, the victim will add a routing rule so that all traffic to 1.2.3.4 is sent outside the VPN tunnel.

When the victim now visits target.com, a web request is sent to 1.2.3.4. Due to the routing rule to prevent re-encryption of packets to the VPN server, this request is sent outside the protected VPN tunnel. As a result, the web request is leaked.

We found that the built-in VPN clients of Windows, macOS, and iOS are vulnerable. Android 12 and higher is not affected. A significant number of Linux VPNs are also vulnerable. Additionally, we found that most OpenVPN profiles, when used with a vulnerable VPN client, use a hostname to identify the VPN server and therefore may result in vulnerable behavior. For more details about the ServerIP experiments, see our paper. To prevent the attack, VPN clients should be updated to send all traffic through the VPN tunnel, except traffic generated by the VPN app itself.

Discussion

Our attacks are not computationally expensive, meaning anyone with the appropriate network access can perform them, and they are independent of the VPN protocol being used. Overall, our attacks break the security and anonymity that VPNs are expected to provide. Even if the victim is using another layer of encryption such as HTTPS, our attacks reveal which websites a user is visiting, which can be a significant privacy risk. Moreover, the leaked traffic can contain sensitive data if older insecure protocols are used, and our attack can be used as a basis to attack such older protocols.

We believe that one reason why these routing manipulation vulnerabilities were only discovered more than two decades after the introduction of VPNs, is that most previous works focused on the VPN protocols themselves, but only few studied their integration into real-world clients and platforms. In other words, our attacks show that properly integrating VPNs into a platform, and securely managing the routing table, is essential for security.

Our results also show that the security of VPN clients practically always depends on the Operating System (OS), meaning one must always take into account the OS when discussing the security of a VPN product or brand. We also believe that the OS should provide a straightforward and secure API to configure and start VPN clients. This avoids each VPN having to implement its own or routing table code on each supported OS, which should increase overall security. For instance, Android has one of the more robust APIs to enable a VPN, and this is one explanation why VPN clients are typically more secure on Android.

Assigned CVE identifiers

Our findings were tracked by CERT/CC under the identifier VU#563667. Our attacks got assigned the following Common Vulnerabilities and Exposures (CVE) identifiers:

  • CVE-2023-36672: LocalNet attack resulting in leakage of traffic in plaintext. The reference CVSS score is 6.8.
  • CVE-2023-35838: LocalNet attack resulting in the blocking of traffic. The reference CVSS score is 3.1.
  • CVE-2023-36673: ServerIP attack, combined with DNS spoofing, that can leak traffic to arbitrary IP address. The reference CVSS score is 7.4.
  • CVE-2023-36671: ServerIP attack where only traffic to the real IP address of the VPN server can be leaked. The reference CVSS score is 3.1.

Note that these are reference CVE identifiers. Normally each affected codebase receives a unique CVE, but the agreement between affected vendors was that, in this specific case, using the same CVE across different codebases would make communication easier. For instance, by tying one CVE to each vulnerability, a customer can now ask a vendor whether their product is affected by a specific CVE. Please note that this deviates from normal MITRE guidelines, and that this decision was made by affected vendors independently of MITRE, and that this in no way reflects any changes in how MITRE assigns CVEs.

Paper

Our paper behind the attack is titled Bypassing Tunnels: Leaking VPN Client Traffic by Abusing Routing Tables and will be presented at USENIX Security. You can use the following bibtex entry to cite our paper:

@inproceedings{usenix2023-tunnelcrack,
  author = {Nian Xue and Yashaswi Malla and Zihang Xia and Christina P\"opper and Mathy Vanhoef},
  title = {Bypassing Tunnels: Leaking {VPN} Client Traffic by Abusing Routing Tables},
  booktitle = {Proceedings of the 32th {USENIX} Security Symposium},
  year = {2023},
  month = {August},
  publisher = {{USENIX} Association}
}

Paper Clarifications

  • In Section 5.6.5 regarding Cisco AnyConnect, during the disclosure we were only able to replicate the leakage of packets on port 443. There were no observed leaks on other ports.
  • In Section 6.1.1 regarding defenses to the LocalNet attack, with "Disable local traffic" we don't mean blocking traffic. We mean that traffic to local IP addresses should also be sent through the VPN tunnel.
  • In Section 5.4.2 regarding defenses to the LocalNet attack on iOS, before our disclosure only a few vendors used the includeAllNetworks and excludeLocalNetworks API parameters. We remark that the parameter excludeLocalNetworks only has an effect when includeAllNetworks is to True.

Tools

Our GitHub repository contains instructions on how to manually test VPN clients. These are the instructions that we also followed while carrying out the research. During the coordinated disclosure, we also made a more automated script to test VPNs, as can be seen in the demo. However, to prevent malicious individuals from abusing our testing script to attack users, we will only release this script once sufficiently many VPNs have been patched.

The LocalNet attack can be easily tested though: configure a router to use the subnet 216.165.47.0/24 for the local network. Connect to the router, enable the VPN, and visit http://nyu.edu or http://216.165.47.10. If, while the VPN is enabled, the NYU website won't load using one of these URLs, then the VPN is likely vulnerable.

A quick method to confirm that a VPN client cannot be vulnerable to the ServerIP attack is to enable the VPN and then use Wireshark to identify the VPN server's IP address. Then visit http://$VPN_SERVERIP. If you cannot see plaintext TCP SYNs in Wireshark (use the filter "tcp.flags.syn == 1") then the VPN client cannot be vulnerable.

Q&A

Note: we are still tweaking the Q&A during the initial hours of the disclosure.

How can I contact you?

The research was carried out by Nian Xue (New York University), Yashaswi Malla, Zihang Xia, Christina Pöpper (New York University Abu Dhabi), and Mathy Vanhoef (KU Leuven University). You can e-mail Mathy Vanhoef for any questions.

How did you discover this?

The initial research idea came from Mathy Vanhoef. To quote him: "I've wanted to study the security of VPN for a while. Around 9 June 2020, so during the midst of COVID, I was looking at all the configuration options of OpenVPN for Android. At the time I was living in Abu Dhabi and using a VPN was common to get access to my computers in Belgium. While randomly scrolling through the options, I saw the option "Bypass VPN for local networks". Enabling that option allowed you to directly connect to devices in the local network without going through the VPN. At that moment I realised that some VPN clients might not check whether the local network is using private IP address. And I realized that an adversary would then be able to create a rogue Wi-Fi network that advertises public IP address and would then be able to intercept traffic. I was able to quickly confirm this against my own VPN client. After this initial experiment, we first had to finished other research, and it took a while before our team could devote our full attention towards VPN research."

Can I reuse the images on this website?

Yes. For instance, you can use the logo, illustrations of the LocalNet attack (mobile version), illustrations of the ServerIP attack (mobile version), and statistics of the LocalNet experiments (mobile version).

Thanks goes to Darlee Urbiztondo for designing the logo.

Which OpenVPN-capable clients have patched the vulnerabilities?

In case you use OpenVPN servers and profiles, then you can use the open-source Windscribe client and load your OpenVPN profile in Windscribe. You will then be able to use Windscribe with your own server. At the time of disclosure, the Windscribe client was secure against all attacks on all the platforms that we tested (Windows, Android, macOS, Linux, iOS). In contrast, during the disclosure we were not aware of any updates that the OpenVPN Connect client had planned, meaning we don't know to which extent OpenVPN Connect will prevent our attacks.

Why is the disclosure so close to Black Hat and DEF CON?

The research was accepted at USENIX Security. We decided to disclose our research on the Patch Tuesday before the start of USENIX Security, which turned out to be Tuesday 8 August 2023.

I only realized while making this website that people will likely be relying on VPNs during Black Hat and DEF CON (and the other security conferences). And given the large amount of VPN clients that exist, it might be unclear whether your specific VPN client is already patched and secure.. #oops.

Was ClarioVPN informed of the vulnerabilities?

Yes. The Dubai-based ClarioVPN team was notified about both attacks. The summarized disclosure timeline was:

  • 15 April 2023: Initial report about a ServerIP attack variant sent to Clario.
  • 5 May 2023: After some discussion, they informed us that MitM attacks are out of scope.
  • 8 May 2023: Mathy Vanhoef publicly tweeted that Clario considers MitM attacks against a VPN to be out of scope.
  • 12 May 2023: Clario changed the scope of their vulnerability program and now does consider MitM to be in scope for its VPN client. They will forward the report to the appropriate team for review.
  • 15 May 2023: Initial report about LocalNet attacks sent to Clario.
  • 7 June 2023: They informed us that the LocalNet attack doesn’t seem to have any significant security risk and/or security impact. Clario mentioned that they aren't interested in participating in this "multi-party coordinated disclosure on VPN security".
  • 7 June 2023: Informed them that ClarioVPN will be part of the disclosure.
  • 21 July 2023: Clario informed us that there appeared to be a miscommunication. They believe the risk to their customers is not low, but medium, and that they are nevertheless going to release fixes.

Note that Mathy Vanhoef handled the disclosure with Clario. Based on his experience, and their reaction, he doesn't consider ClarioVPN to be a trustworthy VPN.

Was Ivanti informed of the vulnerabilities?

Yes.

Is Window's built-in VPN also vulnerable?

Yes, it's vulnerable to both the LocalNet and ServerIP attacks. Microsoft is not planning to release patches.

The disclosure timeline for the ServerIP attack was:

  • 8 May 2023: Initial report send to Microsoft.
  • 14 July 2023: They asked if our research would be presented at Black Hat. We informed then that both the ServerIP and LocalNet attacks will be presented at USENIX Security.
  • 7 August 2023: Microsoft informed us this behavior is by design, the barrier-to-entry to mount this attack is high. Microsoft claims that after the VPN tunnel is established, a MitM won't be able to decapsulate content (while in our opinion the attack is about making the victim leak traffic, not the 'decapsulation' of encrypted traffic). They also mentioned that with a forced tunnel such an attack is not possible because DNS is then also tunneled (in our attack DNS is spoofed before the tunnel is established). It's mentioned that traffic will only leak when using a split-tunnel configuration (while our ServerIP attack can also make a full tunnel VPN leak traffic). It's also mentioned that the attack makes the assumption that TLS-based DNS protocols are not in use (by default they were never used by the Windows platforms that we tested). They mentioned this case will be closed.
  • 7 August 2023: We briefly replied that they seemed to have misunderstood the attack.
  • 8 August 2023: Public disclosure as planned.

The disclosure timeline for the LocalNet attack was:

  • 11 May 2023: Initial report send to Microsoft.
  • 7 August 2023: Microsoft answered that this doesn't meet the bar for an immediate and urgent fix in an upcoming Security Patch update. It's mentioned that if an attacker can hand out "rogue IP addresses" to clients, then network connectivity would be highly likely be broken on the client anyway. They mentioned that therefore, the attack scenario is similar to the ServerIP attacks, where attacks are only possible in a split-tunnel configuration, which they mention is no different to not having a VPN configured for the targeted address ranges. They mentioned this case will be closed.
  • 7 August 2023: We briefly replied that they seemed to have misunderstood the attack.
  • 8 August 2023: Public disclosure as planned.

We consider it unfortunate that their reply came so late. We hope it's still possible to rectify the misunderstandings about how the attacks work, or at least to better understand the mismatch between what users expect about a VPN compared to the actual provided security guarantees of Window's built-in VPN.

Why did nobody notice these vulnerabilities before?

We think this is because previous research focused on the cryptographic aspects of VPNs, or focused on detecting typically programming vulnerabilities in VPNs, but up until now no attention was given to the secure integration of VPNs into a real-world system.

My VPN client isn't patched yet, what can I do?

First, it's always good to remember general security best practices: update your devices, don't reuse your passwords, make sure you have backups of important data, don't visit shady websites, and so on.

In regard to the discovered VPN vulnerabilities, you can mitigate the LocalNet attack by disabling "local network access" in your VPN client. Unfortunately, not all VPN clients offer such a feature.

Why is a VPN still important? These days we can rely on HTTPS.

These days a lot of websites and apps use HTTPS to encrypt data. When using HTTPS, an adversary cannot see the data you are transmitting even when you are connected to an open Wi-Fi network. This also means that you can safely use open Wi-Fi hotspots as long as you keep your devices up-to-date and as long as you assure that websites are using HTTPS. Unfortunately, not all websites require the usage of HTTPS (i.e. they're not using HSTS), meaning they remain vulnerable to possible attacks.

When only relying on HTTPS, it's also easy for an adversary to determine which websites you visit. There is research work that can also determine exactly which webpage you're visiting on an HTTPS website. So although HTTPS protects the data that you are transmitting, it does not hide who you are sending it to. And that on its own can be sensitive information.

How sure are you that every VPN is vulnerable on at least one device?

In experiments on more than 75 devices, all of them were vulnerable to one or more of the discovered attacks. I'm curious myself whether all devices in the whole world are indeed affected though! To find this out, if you find a device that isn't affected by at least one of the discovered vulnerabilities, let me know.

Also, if your company provides Wi-Fi devices and you think that your product was not affected by any of the discovered vulnerabilities, you can send your product to me. Once I confirmed that it indeed was not affected by any vulnerabilities the name of your product and company will be put here! Note that I do need a method to assure that I'm indeed testing a version of the product that was available before the disclosure of the vulnerabilities (and that you didn't silently patch some vulnerabilities).

Isn't it irresponsible to release tools to perform the attacks?

The test tool that we released can only be used to test whether a device is vulnerable. It cannot be used to perform attacks: an adversary would have to write their own tools for that. This approach enables network administrators to test if devices are affected while reducing the chance of someone abusing the released code.

Where are all the attack tools?

The code that has currently been released focusses on detecting vulnerable implementations. The proof-of-concepts scripts that perform actual attacks are not released to provide everyone with more time to implement and deploy patches. Once a large enough fraction of devices has been patched, and if deemed necessary and/or beneficial, the attack script will be publicly released as well.

Why is the LocalNet attack so hard to fix on iOS?

On iOS this can be done by using the includeAllNetworks and excludeLocalNetworks APIs, unfortunately, using these APIs may cause reliability issues, making some vendors hesitant to adopt this defense. Ideally, Apple should create a more robust API for VPNs on iOS, so that VPN apps can be implemented more securely and reliably.

How did you block selected traffic in the demo?

By assigning the IP addresses that we wanted to block to the local Wi-Fi network.

Why are so many implementations vulnerable to the LocalNet attack?

Most users want to be able to access their local network while using a VPN. Unfortunately, we found that this was nearly always implemented in an insecure manner.

Why do you use the same CVE for implementation issues in multiple different codebases?

Implementation-specific vulnerabilities usually get their own independent CVE identifier for each different codebase. However, because the same implementation issues seem to be present across multiple vendors it would make more sense to have a single CVE identifier for each common implementation issue. After all, the main purpose of CVE identifiers is to provide a single, common ID to be used across vendors to identify the same vulnerability. We therefore think it makes sense to assign only a single CVE identifier to each implementation issues. This enables vendors and customers to easily reference an implementation vulnerability and, for instance, check whether certain products are affected by one of the discovered vulnerabilities.

Why were not all VPN vendors notified in advance?

We collaborated with CERT/CC to disclose our results in a coordinated manner. On top of that, we personally also notified VPN vendors that had an explicit security contact and/or a bug bounty program. Unfortunately, it was practically infeasible to notify all VPN vendors. Additionally, notifying a large number of VPN vendors increase the risk of the vulnerabilities becoming public during the embargo, and increases the risk that malicious actors might learn about the vulnerabilities and abuse them in targeted attacks.

Based on our previous experience with disclosing Wi-Fi vulnerabilities, it would have been very useful if there would have been an equivalent of the Wi-Fi Alliance but for VPN vendors. Such an organization could then help with multi-party coordinated disclosures that involve widespread security issues in VPN software.

Are these vulnerabilities being exploited in practice?

Not that we are aware of. But it is difficult to monitor whether one of the discovered vulnerabilities have been exploited in the past or are currently being exploited. So it is hard to give a definite answer to this question.

Why did some VPN vendors silently release fixes before the disclosure?

During the coordinated disclosure, we gave VPN vendors the option to already release fixes roughly two weeks before the disclosure, as long as no details of the vulnerability would be made available. Although this creates a risk that someone might reverse engineer the patches and rediscover certain attacks, we considered this to be unlikely. The vulnerabilities have been present in VPN clients for more than two decades, and the advantage of getting patches out on time appeared to outweigh the risk that someone would rediscover the attacks.

Isn't nyu.edu using HSTS to prevent these kinds of attacks?

Websites can use HSTS to force browsers to always use HTTPS encryption when visiting a website. This prevents the attack that was shown in our demo. Unfortunately, the website of NYU at the time did not properly configure HSTS. More technically, some subdomains such as globalhome.nyu.edu do instruct the browser to use HSTS by including the following header in responses: 

strict-transport-security: max-age=31536000 ; includeSubDomains

Unfortunately, other subdomains such as shibboleth.nyu.edu remove HSTS by including the following header in responses: 

Strict-Transport-Security: max-age=0

Combined with other configuration decisions, this meant that when a user would type nyu.edu in their browser, the initial request was sent in plaintext and therefore could be intercepted by an adversary.

Note that NYU was already informed of this HSTS configuration behavior on 4 May 2021.