Researchers have devised an attack against nearly all virtual private network applications that forces them to send and receive some or all traffic outside of the encrypted tunnel designed to protect it from snooping or tampering.
TunnelVision, as the researchers have named 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 to cloak the user’s IP address. The researchers believe it affects all VPN applications when they’re connected to a hostile network and that there are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android. They also said their attack technique may have been possible since 2002 and may already have been discovered and used in the wild since then.
The effect of TunnelVision is that “the victim’s traffic is now decloaked and being routed through the attacker directly,” a video demonstration explained. “The attacker can read, drop or modify the leaked traffic and the victim maintains their connection to both the VPN and the internet.”
The assault involves tampering with the DHCP server, which assigns IP addresses to devices looking to connect to the local network. An option called option 121 enables the DHCP server to bypass default routing rules that direct VPN traffic through a local IP address, thereby establishing the encrypted tunnel. When option 121 is used to channel VPN traffic through the DHCP server, the data is redirected to the DHCP server itself. Leviathan Security Researchers have clarified this tactic:
The methodology we employ involves running a DHCP server on the same network as the targeted VPN user and configuring our DHCP server to function as a gateway. Upon receiving traffic, we use forwarding rules on our DHCP server to funnel the traffic to a valid gateway while simultaneously monitoring it.
We utilize DHCP option 121 to establish a route on the VPN user’s routing table. The set route can be arbitrary, and if necessary, we can set multiple routes. By implementing routes more specific than the /0 CIDR range typically used by VPNs, routing rules with higher priority than the virtual interface routes created by the VPN can be created. We can set several /1 routes to recreate the 0.0.0.0/0 rule that regulates all traffic set by most VPNs.
Setting a route also implies that the network traffic will be transmitted over the same interface as the DHCP server, bypassing the virtual network interface. This is an intended feature that the RFC does not expressly mention. Therefore, the routes we set are never encrypted by the VPN’s virtual interface; instead, they are sent by the network interface that communicates with the DHCP server. As attackers, we can select which IP addresses pass through the tunnel and which go over the network interface communicating with our DHCP server.
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.
The attack can most effectively be carried out by a person who has administrative control over the network the target is connecting to. In that scenario, the attacker configures the DHCP server to use option 121. It’s also possible for people who can connect to the network as an unprivileged user to perform the attack by setting up their own rogue DHCP server.
This story originally appeared on Ars Technica, a trusted source for technology news, tech policy analysis, reviews, and more. Ars is owned by WIRED’s parent company, Condé Nast.
The attack permits some or all traffic to be routed through the unencrypted tunnel. In either case, the VPN application will report that all data is being sent through the protected connection. Any traffic that’s diverted away from this tunnel will not be encrypted by the VPN and the internet IP address viewable by the remote user will belong to the network the VPN user is connected to, rather than one designated by the VPN app.
Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn’t implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks. Network firewalls can also be configured to deny inbound and outbound traffic to and from the physical interface. This remedy 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 the Linux mitigation.
The most effective fixes are to run the VPN inside of a virtual machine whose network adapter isn’t in bridged mode or to connect the VPN to the internet through the Wi-Fi network of a cellular device. The research, from Leviathan Security researchers Lizzie Moratti and Dani Cronce, is available here.
This story originally appeared on Ars Technica.
Kate Knibbs
Matt Simon
Dell Cameron
Medea Giordano
