“TunnelVision” attack leaves almost all VPNs vulnerable to espionage

Researchers have developed 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 to protect it from snooping or tampering.

TunnelVision, as the researchers called their attack, largely negates the entire purpose and selling point of VPNs, which is to encapsulate incoming and outgoing Internet traffic in an encrypted tunnel and obfuscate the user’s IP address. The researchers believe that all VPN applications are affected when connected to a hostile network and that there is no way to prevent such attacks unless the user’s VPN is running 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 “the victim’s traffic is now unmasked and routed directly through the attacker,” a video demonstration explains. “The attacker can read, delete or modify the leaked 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 that attempt to connect to the local network. A setting known as Option 121 allows the DHCP server to override standard 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 redirects the 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 set our DHCP configuration to use itself as a gateway. When traffic reaches our gateway, we use the traffic forwarding rules on the DHCP server to forward the traffic to a legitimate gateway while spying on it.

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

Pushing a route also means that network traffic is sent over the same interface as the DHCP server and not over the virtual network interface. This is intended functionality and is not clearly stated in the RFC. Therefore, the routes we push are never encrypted over the VPN’s virtual interface, but instead are transmitted over the network interface that communicates with the DHCP server. As an attacker, we can choose which IP addresses go over the tunnel and which go over the network interface and communicate with our DHCP server.

Traffic now travels outside the encrypted VPN tunnel. This technique can also be used for an already existing VPN connection if the VPN user’s host needs to renew a lease from our DHCP server. We can artificially create this scenario by setting a short lease time in the DHCP lease so that 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 a connection and the kill switch was never activated to terminate our VPN connection.

The attack can be carried out most effectively by a person who has administrative control of the network to which the target connects. In this scenario, the attacker configures the DHCP server to use option 121. It is also possible that people who can connect to the network as an unprivileged user carry out the attack by setting up their own rogue DHCP server.

The attack can cause some or all of the traffic to pass through the unencrypted tunnel. In both cases, the VPN application reports that all data is being sent over the protected connection. Any traffic redirected from this tunnel is not encrypted by the VPN and the Internet IP address visible to the remote user belongs to the network to which the VPN user is connected, rather than to a network owned by the VPN app has been set.

Interestingly, Android is the only operating system that fully protects VPN apps from the attack as it does not implement option 121. There are no complete fixes for all other operating systems. When apps are running on Linux, there is a setting that minimizes the impact, but even then TunnelVision can be used to exploit a side channel that can be used to deanonymize target traffic and carry out targeted denial of service attacks. Network firewalls can also be configured to block inbound and outbound 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 way of controlling the firewall, and (2) it opens the same side channel as the Linux Defense is present.

The most effective solutions are to run the VPN in a virtual machine whose network adapter is not in bridged mode or to connect the VPN to the Internet via a mobile device’s Wi-Fi network. The study by Leviathan Security researchers Lizzie Moratti and Dani Cronce is available here.

This story originally appeared on Ars Technica.