On July 16, former Citizen Lab Open Technology Fund (OTF) Information Controls Fellowship Program fellow Benjamin Mixon-Baca will be presenting “Attacking Connection Tracking Frameworks as used by Virtual Private Networks”, whose co-authors include Citizen Lab researcher Jeffrey Knockel. In this study, the authors explore the connection tracking frameworks used in major operating systems and identify a unique exploit technique known as port shadow, making a user less secure and vulnerable to attackers outside their normal administrative boundaries.
The authors also have recommendations for VPN servers and service providers. They suggest that VPN providers randomize source port selection, prevent clients from using the VPN server’s listening port as a source port, and limit concurrent VPN connections. From a user perspective, they should connect to private VPN servers to which only they have access, or use a non-vulnerable encryption protocol.
More details on the event can be found on the symposium website and the paper is available for download here. The authors of the paper have produced an accompanying FAQ which is available below.
Explainer: Attacking Connection Tracking Frameworks as used by Virtual Private Networks
By Benjamin Mixon-Baca (Arizona State University/Breakpointing Bad), Jeffrey Knockel (The Citizen Lab, University of Toronto), Diwen Xue (University of Michigan), Tarun Ayyagari (Arizona State University), Deepak Kapur (University of New Mexico), Roya Ensafi (University of Michigan), and Jedidiah R. Crandall (Arizona State University)
Key findings
- VPN software (OpenVPN, WireGuard, OpenConnect) underlying most VPN services can actually make you less secure, allowing an attacker to act as an in-path router between you and the VPN server, deanonymize your connection, redirect your DNS requests, or port scan you.
- In a newly published paper, we have identified a new vulnerability, which we call a port shadow, that can extend the range of attackers to targets in countries outside their normal administrative boundaries and launch machine-in-the-middle attacks.
- This vulnerability affects OpenVPN, WireGuard, and OpenConnect running on Linux or FreeBSD. FreeBSD is less vulnerable, but the most serious attacks are still possible.
- We disclosed this vulnerability to the VPN software developers, Linux, and FreeBSD, but, because of the way the vulnerability works, the mitigation strategy is limited to using specific firewalls rules as opposed to a code fix.
- We recommend that VPN developers/providers ensure that source port selection is randomized, block VPN clients from selecting the listening port of the VPN server as a source port, and limit the number of concurrent VPN connections by a single user. For end users, the most foolproof mitigation is to connect to private VPN servers to which only they have access or to switch to non-vulnerable protocols such as Shadowsocks or Tor instead of OpenVPN or WireGuard.
What is a VPN?
A VPN, or virtual private network, is a software system originally designed to access private resources on another network, such as office file servers and other remote resources from home. Modern VPNs have been repurposed to circumvent censorship and obfuscate a person’s identity online. VPNs accomplish this by using encryption and by using a proxy (an intermediary device) to manage their online activity. Unfortunately, we found that, counter to users’ intentions behind using VPNs, common VPN software has multiple weaknesses that can severely compromise the confidentiality, integrity, and availability of VPN client connections, particularly if the attack is targeted and the attacker is well resourced.
What is your new discovery?
Our investigation uncovered a new attack method called a port shadow, which leverages vulnerabilities in VPN software that can extend the range of an attacker and permit them to act as a network router, even if they are nowhere near the target. This attack represents a new threat model that VPN users and security experts who advocate for the use of VPNs need to consider.
How does a “port shadow” attack work?
If you share a WiFi connection with an attacker at a coffee shop, for example, there are certain attacks they can execute to see the unencrypted parts of your Internet communications (e.g., the domain names of the websites you visit) and interfere with your communications to carry out other advanced attacks against you. Typically, security experts recommend the use of a VPN to protect against attackers with whom you share a WiFi connection. Our research reveals that using a VPN opens you up to similar attacks from other VPN users with whom you share your VPN server. In the same way that the WiFi radio signal is a shared resource that makes users vulnerable to attacks, there is a shared resource on VPN servers called a port (each connection through the VPN server is assigned to a port). By carefully crafting packets from within the attacker’s own connection to the VPN server and from a remote Internet location controlled by the attacker, it is possible to carry out attacks on other VPN users who are using the same VPN server in a manner that is very similar to the attacks that could be carried out on shared WiFi. We call this attack primitive a port shadow because the attacker shadows their own information on a victim’s port as a shared resource, and this attack primitive can lead to snooping of unencrypted data, port scans, or connection hijacking.
What VPNs were analyzed in the study and how were they selected?
VPN services (e.g., NordVPN, ExpressVPN, and Surfshark) offer a range of protocols (e.g., OpenVPN and WireGuard) to connect to their service. Their VPN servers are typically deployed on Linux. Instead of focusing on particular VPN services (e.g., Nord, ExpressVPN, etc.), we chose to analyze the underlying protocol implementations upon which these services are built and how they interact with the operating system on which they typically run. We did this for two reasons. First, it allowed us to focus on common issues with VPN services without having to analyze each one independently, and services’ popularity can change with time. Second, the attacks can affect other VPN clients’ connections and, without informed consent, we were not comfortable performing tests directly on VPN services (though we did identify candidates passively using VPNAlyzer data). Instead our analysis focuses on the popular open source implementations of OpenVPN and WireGuard on GNU/Linux (Netfilter) and FreeBSD (IPFILTER, PF, IPFW, NATD).
We selected this set of VPNs and operating systems (OS) for our analysis because they facilitate identity obfuscation at a low level in the OS by using the OS’s connection tracking framework.
What is a connection tracking framework?
The connection tracking framework is the engine that drives the identity obfuscation and facilitates the VPN client application’s ability to forward a user’s transmissions to the VPN server. It also facilitates the VPN server’s ability to transmit users’ requests to the website and trick the website into thinking the VPN server sent the transmission instead of you, and transmit the website’s responses back to you.
The diagram below depicts a typical interaction between two VPN clients and a VPN server. Initially both Clients A and B are not connected to the VPN server. In Step 1, Client A connects to the VPN server. In Step 2, Client B connects to the VPN server. When the VPN server receives a packet from Client A in Step 3, the VPN server decrypts Client A’s packet, and sends the packet to the Web Server. When this happens, the VPN server’s connection tracking framework (the green boxes at the bottom) stores the source and destination IP and port numbers Client A selected for the connection to the Web Server. The connection tracking framework changes the IP of Client A’s packet and then sends it to the Web Server, in Step 4. The connection tracking framework has a lot of control over how the VPN server sends and receives packets. More importantly, it is shared by all VPN clients connected to the VPN server and can be modified by any VPN client. This makes it possible for a malicious client to force the VPN server to reroute packets in various ways.
We did not consider VPN protocols like Shadowsocks or HTTP proxies because they perform identity obfuscation in a different way and do not depend on the connection tracking framework like OpenVPN and WireGuard or other low-level VPNs. Finally, we did not perform a security analysis of specific VPN applications or encryption because we are focused on the lower level details of the connection tracking framework and how it operates in concert with these other components.
What vulnerabilities were identified in the VPN apps you analyzed?
An attacker can abuse the connection tracking framework using the vulnerability, i.e., the port shadow, in a variety of ways to subvert the privacy and security of VPN clients connected to VPN servers that use OpenVPN, WireGuard, or OpenConnect if they do not take proper precautions. Specifically, an attacker can use the port shadow to cause a victim’s packets to be rerouted to the attacker (including their VPN connection request), escalate from adjacent to in-path between the target and VPN server, inject DNS packets into the target, deanonymize their connections, cause denial-of-service, or port scan the target through the VPN server.
We found that Linux/Netfilter + (OpenVPN and WireGuard), which a large fraction of VPN services use, has the highest susceptibility to these attacks regardless of client platform (PC, Android, and iOS). FreeBSD is less susceptible to some of the attacks, but remains vulnerable to the worst of them.
What are the implications for the vulnerabilities discovered?
A VPN can actually make the user less secure in specific situations. For instance, an attacker can eavesdrop on or even hijack your connection to another server. As an example, if you are part of a targeted group, such as the Tibetan diaspora living abroad and using a VPN service, it might be possible for a hostile actor to take control over your connections, and cause a denial of server, snoop against your connections, or redirect you to an attacker controlled server.
Suppose you are a journalist critical of the Saudi Kingdom living in the United States and are using a VPN server in New York. If the server is vulnerable to the port shadow, then a hostile actor who is able to connect to the same VPN server as you can escalate privileges from adjacent (as another VPN client) to in-path between you and the VPN server. From this in-path position, the attacker can then leverage an additional attack to inject DNS responses into your connection and/or redirect you to an attacker-controlled website.
The attacker can also port scan you, redirect your packets in various ways, or spy on your connections.
What are your recommendations?
We tested different mitigation strategies using a two-pronged approach. First, we built a formal model to test different mitigation strategies and ensure that mitigations did not introduce new or unintended weaknesses. Then we tested the mitigations against real systems in a test environment. Most of the mitigations require action on the part of the VPN server and service provider. There are some mitigations that a client can use and/or that the VPN client application developers can implement to protect their user base.
The easiest option for users is to use a protocol such as ShadowSocks or Tor. The attacks we found do not affect those systems because ShadowSocks servers and Tor routers do not rely on the problematic connection tracking framework of the host operating system.
Recommendations for VPN server operators
The VPN service provider can implement firewall rules on VPN servers that prevent the attack from working. On Linux the following IPtables command will work:
On FreeBSD, configuring the firewall to restrict source ports your VPN clients can use will prevent these attacks.
For OpenVPN, the “ifconfig-pool-persist” configuration option can make the port scan attacks more difficult. For WireGuard, restricting/statically assigning the private IP addresses your clients use will mitigate the port scanning attacks.
Limiting the number of concurrent connections per client will make the eviction reroute attack more expensive for the attacker because they will require a large number of unique accounts to facilitate the attack.
To prevent the port scanning attack, the VPN server can remove stale entries from the connection tracking framework whenever a client disconnects from the VPN server. On Linux, the following command can be used:
Finally, if the VPN server has multiple IP addresses, the server can be configured to use both as follows:
Recommendations for VPN client developers
OpenVPN clients can use network name spaces, such as namespaced-openvpn, to increase their security when using an OpenVPN client on a Linux PC. This is only a partial mitigation and the user remains vulnerable to the most severe consequences. This is because the vulnerability primarily impacts the VPN server rather than the client software used by potential targets.
Recommendations for VPN end users
Since the vulnerabilities we discovered exist on the VPN server, not the VPN client. The easiest option for users is to use a protocol such as ShadowSocks or Tor. Furthermore, we found that some VPN services operating over OpenVPN or WireGuard protocols are not susceptible to CVE-2021-3773, including NordVPN, ExpressVPN, and Surfshark. However, we do not have a comprehensive list of VPN services that are not vulnerable. Finally, since this attack method requires the attacker to have access to the same server as the victim, users can protect themselves by using VPN servers that are only used by others who are trusted.
While the best thing a user can do is pick a VPN service or protocol that is not vulnerable, there are additional safety measures users can employ to safeguard connections. Port scanning, for instance, can be partially mitigated on Linux desktops using network namespaces.
Have you reported the vulnerabilities? What was the response?
We privately disclosed the vulnerability to the developers of OpenVPN and WireGuard, as well as the Linux security mailing list, over 45 days before publicly disclosing the vulnerability, following recommended disclosure guidelines for US-CERT. Both teams responded quickly to our inquiry. Because the vulnerability is not part of the OpenVPN or WireGuard software stacks, their developers have little recourse regarding mitigations. Upon disclosing the vulnerability to the Linux kernel mailing list and disclosing to the NVD, the vulnerability was assigned CVE-2021-3773 with CVSSv2 and CVSSv3 scores of 7.5 and 9.8, respectively.
Have the vulnerabilities been fixed?
The vulnerabilities appear to remain exploitable against the most recent version of Linux. Netfilter did commit and then revert a mitigation because it affected backwards compatibility with other use cases, offering an nftables rule as an alternative. The shared resources that give rise to this side channel vulnerability are shared by design. When one connects to a privacy enhancing VPN server used by other users, one shares a public IP and ports with other users to anonymize one’s communications. Such resource sharing is by design but also makes the attacks possible. If the VPN server were not shared with other VPN users, then the attacks would not be possible.