TunnelVision: Routing Mechanisms Allows Hijacking of VPN Traffic

A recently discovered method that allows attackers to bypass the secure encapsulation typically provided by VPNs. This method exploits the Dynamic Host Configuration Protocol (DHCP) to divert a user’s VPN traffic, resulting in unencrypted data packets that can be intercepted. This phenomenon is known as “decloaking.” Notably, the VPN’s control channel remains intact, meaning that safety features like kill switches do not activate, and the VPN appears to be functioning correctly.

Researchers have dedicated considerable effort to understanding this technique and notifying all relevant parties. Given the potential that this vulnerability has been exploitable since as early as 2002, and might have already been used covertly. We feel a strong responsibility to inform both the cybersecurity community and the public.

Although security researchers have identified one possible mitigation, it presents a risk of being exploited for targeted attacks, such as denial-of-service or traffic analysis, which could have severe consequences for VPN users in high-risk environments, like journalists or whistleblowers.

Eliminating DHCP support is not a viable solution as it could disrupt legitimate internet connections. Instead, it is recommended that VPN providers adopt network namespaces, a feature available on Linux systems as described in WireGuard’s documentation, which separates interface and routing controls from the broader network. Other operating systems should evaluate the feasibility of implementing similar features.

To ensure findings are accessible, we’ve structured this article to introduce readers to the basics of networking, VPN technology, and DHCP, leading up to a detailed discussion of the decloaking behavior.

What is a Network?

A computer network consists of multiple computing devices that are interconnected, allowing them to exchange data. An elementary example is connecting two laptops using an Ethernet cable, which allows them to communicate directly with each other.

Yet, there is more complexity to networking than what initially appears. These devices communicate through a structured set of rules known as protocols. Each protocol serves a specific function and operates at a distinct layer within the network.

These layers address different networking challenges through a process known as encapsulation. This means that each layer operates independently without needing to know the specifics of other layers. For instance, while using a web browser (which operates at the HTTP layer), there’s no need to understand the underlying processes that manage the transmission of electrical signals through a cable (Coax), address the correct recipient (Ethernet, IP), or ensure accurate data delivery (TCP). This is analogous to writing a letter, where the writer focuses on the message, not on the logistics of mail delivery.

Exploring Network Interfaces

A network interface refers to the hardware or software that connects a computer to a network. The simplest form of a network interface is a physical device like a wireless card or a network card, which is installed on a computer’s motherboard. These devices facilitate the transmission of data bits across a physical medium, such as copper wires, fiber optic cables, or through radio frequencies. They are essential for enabling computers to communicate across distances.

Network interfaces are categorized into two main types:

Physical Network Interfaces – These are tangible devices connected to or embedded in the computer, like Ethernet or Wi-Fi cards.
Virtual Network Interfaces – These are software-based interfaces that do not rely on physical connections. They simulate a network connection using a file descriptor that software applications can read from or write to. This makes them particularly valuable in virtualized environments where data transmission does not necessarily require physical media.

Both types of interfaces are designed to support encapsulation, allowing them to interact seamlessly with higher layers of the network architecture. Virtual network interfaces play a pivotal role in VPN clients and servers, enabling secure and efficient network operations without the need for physical network components.

However, there are instances where it might be necessary for a virtual interface to send traffic over a physical medium. For such cases, the virtual interface can be supported by a physical network interface. In this arrangement, the virtual interface routes outbound traffic to the physical network interface, functioning behind the scenes to bridge the digital and physical networking environments.

What is a VPN?

A Virtual Private Network (VPN) enables users to create a secure network tunnel between their device and a remote server. This forms a virtual network that is unrestricted by geographic boundaries and functions much like a traditional physical network.

To accomplish this, VPN clients establish a virtual network interface that uses an underlying file descriptor to encrypt and decrypt traffic at a higher layer before it is sent through a physical network interface. VPNs are designed for ease of use, usually requiring users to simply log in and click a button to connect to their server.

Here are the typical steps a user follows:

Choose settings on the VPN client.
Click a button to initiate the connection.
Log in (this step may be optional, depending on the VPN client).
Receive confirmation that they are connected to the VPN.
Access remote resources through the VPN.

Critically, VPNs can increase the host’s vulnerability to cyber attacks because they send traffic from lower networking layers over the internet. VPNs operate by encapsulating these lower layers within higher ones to create virtual local area networks (LANs) across the internet. LAN traffic is generally more sensitive than standard internet traffic, giving attackers with LAN access greater opportunities for both passive and active attacks. By extending the LAN over the internet, VPNs potentially expose these networks to external threats. To counteract this, VPNs often employ security measures like packet encryption.

This aspect of VPNs is commonly misunderstood: the primary purpose of encryption is not to enhance the security of the physical LAN itself, but to reduce the risks introduced by creating a virtual LAN over the internet.VPNs do not secure you from local network attacks on the physical LAN despite common VPN marketing material and widely given advice.

How VPNs use virtual network interfaces

The VPN client process encrypts the packet it initially receives from the file descriptor linked to its virtual network interface. It then embeds this encrypted data into the layer specific to its VPN protocol and uses this protocol to communicate with the VPN server.

There is a detailed process by which a VPN sends packets to its server, and for those interested in the specifics, we have included a comprehensive list of steps in the Appendix aimed at security researchers and developers seeking more detailed information.

Here’s a simplified overview of that process:

The VPN client establishes a “control channel” with the VPN server. If equipped with a kill switch, any disruption in this channel will trigger a network lockdown.
The VPN client sets up a virtual network interface.
Optionally, the VPN client may execute a startup script to configure various settings on the host, such as routing rules, DNS settings, firewall rules, and other relevant configurations.
A process on the host sends network traffic toward a destination, like when browsing the internet.
Routing rules direct this traffic through the VPN’s interface.
The VPN client encrypts this traffic.
The encrypted traffic is then sent through a physical network interface to the VPN server.
The VPN server receives and decrypts the traffic from the VPN client.
The VPN server then forwards this traffic to its intended destination. This action is commonly referred to by VPN providers as “IP cloaking” or “IP hiding,” making it appear as though the traffic originates from the VPN server.
The destination responds to the VPN server, which encrypts this reply and sends it back to the VPN client.
The VPN client decrypts the response, completing the cycle as the originating process on the host receives the traffic.

When a user connects to a VPN server, the VPN client on their device adjusts the device’s settings to direct traffic through the established tunnel. If all traffic is sent through this VPN tunnel, it’s known as a “full-tunnel VPN.” If only certain types of traffic are routed through the VPN, allowing some exceptions like local network traffic, this is called a “split-tunnel VPN.” Additionally, the VPN client may modify other settings on the device, such as the firewall settings. Later in this discussion, we will explore a specific mitigation technique we observed that uses the device’s firewall.

What is DHCP?

DHCP was originally designed to dynamically assign IP addresses to devices on a local network, eliminating the need for manual configuration. Every modern operating system includes a DHCP client that automatically requests an IP address.

The key concept with DHCP is that it assigns IP addresses with a timed lease and offers additional configurable features through various options. These options can remotely and dynamically set device configurations. Notable among these are the options to designate a default gateway, which serves as the primary pathway to the Internet, and DNS (Domain Name System) servers, which translate domain names like “google.com” into IP addresses.

To obtain an IP address, a client sends a DHCPDISCOVER packet via broadcast to all devices on the local subnet. Only the DHCP server responds, sending back a DHCPOFFER packet unicast directly to the client with an offer of a time-limited IP lease.

However, if the client already knows the DHCP server’s address, it can directly unicast the DHCPDISCOVER packet to the server, usually to renew its lease.

What is DHCP option 121?

In 1997, the DHCP RFC included option 33, which enabled network administrators to configure static routes in a client’s routing table using classful static routes. However, as public IP space grew scarce, these classful routes became less popular. In response, RFC 3442 was released in 2002, introducing option 121 for classless static routes and rendering option 33 obsolete, although its support varies depending on the source. Unlike its predecessor, option 121 allows the addition of static routes with classless ranges to a client’s routing table, with the only limitation being the packet size for the number of routes that can be set up simultaneously.

A notable aspect of DHCP option 121 is its inability to specify the network interface device for the routes it configures; this is not determined by the DHCP server. As illustrated in the captured Wireshark DHCPOFFER packet below, the CIDR range and the designated router are specified, but the interface device is not. Instead, the DHCP client automatically selects the network interface it uses to communicate with the DHCP server for installing the routing rules associated with this option.

Requirements for decloaking VPN traffic

The targeted host needs to accept a DHCP lease from a server controlled by the attacker and must have a DHCP client that supports DHCP option 121.

We want to highlight some methods an attacker on the same network can use to pose as the DHCP server:

Setting up a rogue DHCP server that performs a DHCP starvation attack to deplete the real DHCP server’s address pool, followed by responding to new client requests. We have successfully conducted this in lab settings and are preparing a detailed blog post on the subject.
A rogue DHCP server that quickly responds to DHCPDISCOVER messages, exploiting the common DHCP client behavior of accepting the first lease offer received.
Using ARP spoofing to intercept communications between the real DHCP server and the client, particularly waiting for the client to renew its lease.

Performing the attack

This attack involves operating a DHCP server on the same network as a targeted VPN user and configuring it to designate itself as the gateway. When traffic reaches the gateway, an attacker employs traffic forwarding rules on the DHCP server to reroute the traffic to a legitimate gateway while monitoring it.

The routes an attacker may set can be chosen arbitrarily, and they have the flexibility to configure multiple routes as necessary. By introducing routes that are more specific than the /0 CIDR range typically used by VPNs, would-be attackers can prioritize these routing rules above those established by the VPN’s virtual interface. For instance, setting multiple /1 routes allows for effective mimicry of the 0.0.0.0/0 route that is commonly set by VPNs to handle all traffic.

Introducing such a route also ensures that network traffic is directed over the same interface as the DHCP server rather than the VPN’s virtual network interface. This functionality, though not explicitly detailed in the RFC, is deliberate. Consequently, the traffic routed through the paths an adversary may establish is not encrypted by the VPN’s virtual interface but is instead sent through the network interface communicating via DHCP server. This allows for the attacker to choose which IP addresses are routed through the VPN tunnel and which are handled by the network interface connected to a DHCP server.

Fixes: Network Namespaces

Employing network namespaces on Linux can effectively resolve this issue, although it is not commonly implemented.

WireGuard’s documentation illustrates the possibility of using a namespace to isolate all applications whose traffic should go through a VPN, directing it to another namespace linked to a physical network interface. This approach, though, seems to be specific to Linux, and it remains uncertain whether equally robust solutions exist for Windows, MacOS, or other operating systems.

Mitigations

Firewall Rules Overview in VPN Services

VPN services typically set firewall rules to block all incoming and outgoing traffic on the physical network interface, except for traffic to and from DHCP and VPN server IP addresses, which is necessary to maintain connections to the LAN and the VPN server. Alternatively, employing deep packet inspection could allow only DHCP and VPN protocols, but this might lead to a reduction in performance.

Limitations of Firewall Rule Mitigations

Firewall mitigations often selectively block traffic using the DHCP route, thereby introducing a side-channel vulnerability. Attackers can exploit this side-channel to ascertain the destination of encrypted VPN traffic by comparing traffic volumes under normal conditions to those after malicious route configurations that block traffic are introduced.

With sufficient data, it is possible to statistically determine a targeted user’s traffic destination. However, since most internet traffic is secured by TLS, the intercepted traffic would predominantly reveal only the destinations and protocols, making the side-channel less effective.

Possible uses of the side-channel include:

Screening traffic against a specific list.
Selectively denying traffic as a form of censorship.
Utilizing IP space denial and binary search techniques to quickly map all active connections.

Ignoring DHCP Option 121

Another mitigation strategy involves disabling DHCP option 121 while a VPN is active. Notably, Android devices, which do not support DHCP option 121, are inherently protected from this issue. Nonetheless, disabling option 121 can disrupt network connectivity, which is a significant consideration for its implementation on platforms like Android. This mitigation would need to be compulsory, as attackers could force network access to be re-enabled by the VPN or user.

Using a Hotspot or Virtual Machine

Creating a temporary Wi-Fi network via a hotspot, controlled by a cellular device with password protection and automatic network address translation, ensures a secure LAN environment free from unauthorized local network access. Similarly, using a virtual machine with its network adapter set to non-bridged mode can provide an additional layer of security.

Do not use untrusted networks if you need absolute confidentiality of your traffic.