‘TunnelVision’ attack leaves almost all VPNs vulnerable to spying

Researchers have devised an attack against almost all virtual private network applications that forces them to send and receive some or all of their traffic outside the encrypted tunnel designed to protect it from eavesdropping or tampering.

TunnelVision, as the researchers called their attack, largely negates the purpose and selling point of VPNs, which is to encapsulate incoming and outgoing Internet traffic in an encrypted tunnel and hide the user’s IP address. Researchers believe that it affects all VPN applications when connected to a hostile network and that there is no way to prevent such attacks except when the user’s VPN is running on Linux or Android. They also said that their attack technique may have been possible since 2002 and may have already been discovered and used in the wild since then.

Read, delete or modify VPN traffic

The effect of TunnelVision is that “victim traffic is now unmasked and routed directly through the attacker,” a video demonstration explained. “The attacker can read, discard or modify the filtered traffic and the victim maintains their connection to both the VPN and the Internet.”

The attack works by manipulating the DHCP server which assigns IP addresses to devices trying to connect to the local network. A scenario known as option 121 allows the DHCP server to override default routing rules that send VPN traffic through a local IP address that initiates the encrypted tunnel. By using option 121 to route VPN traffic through the DHCP server, the attack reroutes data to the DHCP server itself. Leviathan Security researchers explained:

Our technique is to run a DHCP server on the same network as a target VPN user and also configure our DHCP configuration to be used as a gateway. When traffic arrives at our gateway, we use traffic forwarding rules on the DHCP server to pass the traffic to a legitimate gateway while we spy on it.

We use DHCP option 121 to establish a route in the VPN user’s routing table. The route we configure is arbitrary and we can also configure multiple routes if necessary. By pushing routes that are more specific than a /0 CIDR range that most VPNs use, we can create routing rules that have a higher priority than the routes for the virtual interface that the VPN creates. We can configure multiple /1 routes to recreate the 0.0.0.0/0 all traffic rule set by most VPNs.

Sending a route also means that network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface. This is intended functionality that is not clearly stated in the RFC. Therefore, for the routes we send, they are never encrypted by the VPN’s virtual interface, but rather transmitted by the network interface that communicates with the DHCP server. As an attacker, we can select which IP addresses go through the tunnel and which addresses go through the network interface by talking to our DHCP server.

We now have traffic transmitting outside of 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 on our DHCP server. We can create that scenario artificially by setting a short lease time on the DHCP lease, so that the user updates their routing table more frequently. Furthermore, 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 itself as connected and the kill switch was never activated to kill our VPN connection.

The attack can be carried out most effectively by a person who has administrative control over the network to which the target connects. In that scenario, the attacker configures the DHCP server to use option 121. It is also possible for people who can connect to the network as unprivileged users to carry out the attack by configuring their own unauthorized DHCP server.

The attack allows some or all of the traffic to be routed through the unencrypted tunnel. In either case, the VPN app will report that all data is being sent over the protected connection. The VPN will not encrypt any traffic diverted from this tunnel, and the Internet IP address visible to the remote user will belong to the network the VPN user is connected to, rather than one designated by the VPN application.

Interestingly, Android is the only operating system that completely immunizes VPN apps against the attack because it does not implement option 121. For all other operating systems, there are no complete solutions. When applications are running on Linux, there is a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel which can be used to anonymize target traffic and perform targeted denial of service attacks. Network firewalls can also be configured to deny incoming and outgoing traffic to and from the physical interface. This solution is problematic for two reasons: (1) a VPN user connecting to an untrusted network has no ability to control the firewall, and (2) it opens the same side channel present with Linux mitigation.

The most effective solutions are to run the VPN inside a virtual machine whose network adapter is not in bridge mode or to connect the VPN to the Internet over a cellular device’s Wi-Fi network. The research, from Leviathan Security researchers Lizzie Moratti and Dani Cronce, is available here.

This story originally appeared on Ars Technique.