‘TunnelVision’ attack leaves nearly all VPNs vulnerable to espionage

Researchers have devised an attack against nearly all of them virtual private network applications force them to send and receive some or all of their traffic outside an 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. Encrypt and hide user IP addresses. Researchers believe it affects all VPN applications when they are connected to a hostile network, and there is no way to prevent such attacks except when the user’s VPN runs on Linux or Android. They also said their attack technique may have been in place since 2002 and may have been discovered and used in the wild since then.

Read, scrape, or modify VPN traffic

The effect of TunnelVision is that “the victim’s traffic is now decrypted and passed directly through to the attacker.” video demonstration explain. “An attacker can read, delete, or modify the leaked traffic, and the victim still maintains their connection to both the VPN and the internet.”

The attack works by manipulation DHCP server allocates IP addresses to devices trying to connect to the local network. An installation is called option 121 allows the DHCP server to override default routing rules sending VPN traffic through the local IP address that initiates the encrypted tunnel. By using option 121 to route VPN traffic through a DHCP server, the attack redirects data to the DHCP server itself. Researchers from Leviathan Security explain:

Our technique is to run the DHCP server on the same network as the targeted VPN user and also configure our DHCP to use itself as a gateway. When traffic hits our gateway, we use traffic forwarding rules on the DHCP server to redirect traffic to a legitimate gateway while we monitor it.

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

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

We now have traffic transmitted outside the VPN’s encrypted tunnel. This technique can also be used on an established VPN connection after the VPN user’s server needs to renew its lease from our DHCP server. We can artificially create that scenario by setting a short lease period in the DHCP lease, so that users update their routing tables more frequently. Additionally, the VPN control channel remains intact because it used a physical interface for communication. In our testing, the VPN always continued to report as connected, and the kill switch never engaged to disconnect our VPN.

The attack can be most effectively carried out by someone who has administrative control over the network to which the target is connecting. In that case, the attacker configures the DHCP server to use option 121. People who can connect to the network as unprivileged users can also carry out the attack by setting set up their own fake DHCP server.

The attack allows some or all traffic to be routed through the unencrypted tunnel. In both cases, the VPN application will report that all data is being sent over the protected connection. Any traffic redirected out of this tunnel will not be encrypted by the VPN, and the Internet IP address that can be viewed by the remote user will belong to the network to which the VPN user is connected, rather than the address provided by the application. Use a designated VPN.

Interestingly, Android is the only operating system that completely immunizes VPN applications from the attack because it does not implement option 121. For all other operating systems, there is no complete fix available . When applications run on Linux there is a setting that minimizes the impact, but even then TunnelVision could still be used to exploit a security vulnerability. secondary channel can be used to de-anonymize destination traffic and carry out targeted denial of service attacks. Network firewalls can also be configured to deny inbound and outbound traffic to and from physical interfaces. This remedy is problematic for two reasons: (1) VPN users connecting to untrusted networks do not have firewall control, and (2) it opens the same side channel contained in the mitigation. minimal Linux.

The most effective fixes 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 through the mobile device’s Wi-Fi network. The study by Leviathan Security researchers Lizzie Moratti and Dani Cronce is now available. This.

This story originally appeared on Ars Technica.