We now have traffic being transmitted outside the VPN’s encrypted tunnel. This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server. We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.

Proof of Concept

Video proof of concept: https://www.youtube.com/watch?v=ajsLmZia6UU

Lab Setup Code: https://github.com/leviathansecurity/TunnelVision

DHCP Server image: https://drive.google.com/file/d/1WLJGs3ZUypf6hLh5WL4AJmsKdUOZo5yZ

The lab scenarios are built to represent:

An attacker compromises a DHCP server/access point

A rogue administrator owns the infrastructure themselves and maliciously configures it

An attacker sets up an evil twin wireless AP in a physical location such as a coffee shop or corporate office

One we release our tool, ArcaneTrickster, the lab can also be used to mimic an attacker who has an adjacent host on the network na dis otherwise not in a privileged network position

Fixes

Network Namespaces

Using network namespaces on Linux can completely fix this behavior. However, in our experience, it is less commonly implemented.

WireGuard’s documentation shows how it’s possible to use a namespace for all applications with traffic that should be using a VPN before sending it to another namespace that contains a physical interface. However, this appears to be Linux-specific functionality and it’s not clear if there is a solution for Windows, MacOS, or other operating systems with the same amount of robustness.

Mitigations

Firewall Rules

We’ve observed VPN providers denying all inbound and outbound traffic to and from the physical interface via firewall rules. An exception was necessary for the DHCP and VPN server IPs because they are necessary to remain connected to the LAN and VPN server. Deep packet inspection could also allow only the DHCP and VPN protocols instead but would likely incur a performance penalty.

Problems with Firewall Rule Mitigations

Firewall mitigations create a selective denial of service for traffic using the DHCP route and introduce a side-channel. An attacker can use this side-channel to determine the destination of traffic. To determine the traffic’s destination, an attacker could perform traffic analysis on the volume of VPN encrypted traffic a user sends. The attacker would need a baseline volume of traffic where no malicious are installed. Then the attacker would need to modify the lease configuration to install routes that deny traffic and observe the difference in volume.

With enough samples, it would be possible to statistically prove whether the targeted user is sending traffic to a specific destination. For the average internet user, most internet traffic is already secured by TLS. Therefore, traffic intercepted by TunnelVision will mostly be unreadable except for the destination and protocols. This means that this side-channel has nearly the same impact and should be considered insufficient.

The side-channel is flexible in use:

The traffic can be checked against a predefined list.

The traffic can be selectively denied as a censorship mechanism.

The attacker can use IP space denial with binary search to determine all current connections in logarithmic time.

Ignore Option 121

Another possible mitigation is ignoring option 121 while the VPN is on. We noted that because Android does not implement support for DHCP option 121, it was uniquely unaffected. The downside is that option 121 exists for a reason, and ignoring these routes can break network connectivity (something that is frequently brought up as a reason to implement it on Android). If this mitigation is implemented, it must be mandatory because attackers could simply deny network access until the VPN or user re-enables option 121.

Use a Hot Spot or VM

Hot spots are temporary Wi-Fi networks controlled by a cellular device. They create a password-locked LAN with automatic network address translation. Because this network is completely controlled by the cellular device and requires a password, an attacker should not have local network access. A virtual machine would also work similarly as long as the VM’s network adapter is not in bridged mode.

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

Industry Impact

Is TunnelVision a vulnerability?

This is debatable. We’re calling it a technique because TunnelVision doesn’t rely on violating any security properties of the underlying technologies. From our perspective, TunnelVision is how DHCP, routing tables, and VPNs are intended to work.

However, it contradicts VPN providers’ assurances that are commonly referenced in marketing materials; in our opinion, TunnelVision becomes a vulnerability when a VPN provider makes assurances that their product secures a customer from an attacker on an untrusted network. There’s a big difference between protecting your data in transit and protecting against all LAN attacks. VPNs were not designed to mitigate LAN attacks on the physical network and to promise otherwise is dangerous.

In our technique, we have not broken the VPN’s cryptographically secured protocol, and the VPN is still fully functional. An attacker is instead forcing a target user to not use their VPN tunnel. Regardless of whether we classify this as a technique, VPN users are affected when they rely on assurances that a VPN can secure them from attackers on their local network.

Affected Operating Systems

In our testing, we observed that any operating system that implements a DHCP client according to its RFC specification and has support for DHCP option 121 routes is affected. This includes Windows, Linux, iOS, and MacOS. Notably, it does not affect Android as they do not have support for DHCP option 121.

Affected VPN Providers and VPN Protocols

We found that VPNs that solely rely on routing rules to secure the host’s traffic are vulnerable. Those who are hosting their own VPN servers (e.g., system administrators) and are not hardening their VPN client configurations will likely be vulnerable as well. We have observed a mitigation from some VPN providers that drops traffic to non-VPN interfaces via firewall rules. It’s possible there are other methods that we did not encounter during testing to mitigate or fix this.

As previously mentioned, we observed the same behavior on each operating system we tested, save one. Furthermore, the strength of the encryption algorithm a VPN uses makes no difference. TunnelVision’s effect is independent of the underlying VPN protocol (e.g., WireGuard, OpenVPN, or IPsec) because it reconfigures the operating system network stack the VPN relies on.

Conclusion

Call to Action

We have a limitation as a research team of two– there are simply too many VPNs on the market to test each one individually. The first approach we took was to notify companies via bug bounties or security disclosure email, but that quickly became unscalable. We’ve also engaged the EFF and CISA to help disclose as broadly as possible prior to publicly releasing this research. We thank them tremendously for their help. Our hope is that by publishing our work, we can reach more affected parties, especially because we believe the technique has been feasible since as early as 2002.

Although the public disclosure of this technique affects each party differently, ultimately there is a shared responsibility.

Users should be made aware of this technique and for sensitive traffic they should be warned against using untrusted networks. If they must use an untrusted network, they should use a VPN provider that has an effective mitigation against this technique. To determine if a provider has an effective mitigation or fix, our lab setup is available for testing and VPN providers themselves will be able to speak to the specifics of their existing mitigations in their documentation. If a VPN decloak does occur, most user data will not be visible to local network attackers assuming they are accessing websites with HTTPS, which has become increasingly common.

It is common for corporate VPNs to be used in areas such as coffee shops, hotels, or airports. Network administrators should inform employees that working from such places carries risks and should be avoided when possible. If such a policy is not practical, then administrators should advise using VPNs that enable the previously mentioned mitigations or fixes. Some alternatives would be to use a trusted hot spot and then connect to the VPN. Lastly, running the VPN inside of a VM that obtains a lease from a virtualized DHCP server would prevent the local networks DHCP server from installing routes altogether.

Companies that control their own networks or have site-to-site VPNs should review the switches they use and enable features such as DHCP snooping and ARP protections. These layer 2 protections help prevent rogue DHCP servers but do not eliminate a rogue administrator scenario. In addition, implementing HTTPS or other protocols with encryption for internal resources will prevent data leakage from VPN users connecting from untrusted networks.

VPN providers can add features to clients to configure firewall rules that drop outbound packets to network interfaces. However, such a setting will mean that a VPN user will be isolated from interacting with local network resources. If the VPN client is for Linux and is intended to be a full tunnel, using network namespaces for isolation. As such, VPN providers should publicly provide documentation about any mitigations or fixes they have for TunnelVision and warn their end users about TunnelVision’s existence. We also recommend reviewing their marketing material and cease marketing claims that VPNs protect customers on untrusted networks until it can be proven.

Operating system maintainers (outside of Linux) should determine whether adding or enhancing features related to network namespaces is feasible.

Upcoming Research

During the disclosure process, we encountered multiple cases in which the entities we disclosed to did not see this as a serious problem. They assumed that the prerequisite conditions included privileged positions or accounts, despite the only prerequisite being local network access. This assumption was partially fueled by our intentionally simplistic lab setup where we were the only DHCP server, and what we perceive as the entity’s lack of familiarity with low-level networking.

With this feedback, we decided to develop a robust adversarial infrastructure library to enable further LAN security research and demonstrate practical attacks. For example, we can demonstrate that it’s possible to consistently perform TunnelVision while simply being adjacent to the target host on the same LAN. We’re calling it “ArcaneTrickster” and plan on releasing it at a later date. However, we feature a demo in our videos, which are available in the proof of concept section.