Researchers have detailed a Virtual Private Network (VPN) bypass technique dubbed TunnelVision that allows threat actors to snoop on victim’s network traffic by just being on the same local network.
The “decloaking” method has been assigned the CVE identifier CVE-2024-3661 (CVSS score: 7.6). It impacts all operating systems that implement a DHCP client and has support for DHCP option 121 routes.
At its core, TunnelVision involves the routing of traffic without encryption through a VPN by means of an attacker-configured DHCP server using the classless static route option 121 to set a route on the VPN user’s routing table.
It also stems from the fact the DHCP protocol, by design, does not authenticate such option messages, thus exposing them to manipulation.
DHCP is a client/server protocol that automatically provides an Internet Protocol (IP) host with its IP address and other related configuration information such as the subnet mask and default gateway so as to access the network and its resources.
It also helps reliably configure IP addresses via a server that maintains a pool of IP addresses and leases an address to any DHCP-enabled client when it starts up on the network.
Because these IP addresses are dynamic (i.e., leased) rather than static (i.e., permanently assigned), addresses that are no longer in use are automatically returned to the pool for reallocation.
The vulnerability, in a nutshell, makes it possible for an attacker with the ability to send DHCP messages to manipulate routes to redirect VPN traffic, thereby allowing them to read, disrupt, or possibly modify network traffic that was expected to be protected by the VPN.
“Because this technique is not dependent on exploiting VPN technologies or underlying protocols, it works completely independently of the VPN provider or implementation,” Leviathan Security Group researchers Dani Cronce and Lizzie Moratti said.
“Our technique is to run a DHCP server on the same network as a targeted VPN user and to also set our DHCP configuration to use itself as a gateway. When the traffic hits our gateway, we use traffic forwarding rules on the DHCP server to pass traffic through to a legitimate gateway while we snoop on it.”
In other words, TunnelVision tricks a VPN user into believing that their connections are secured and routed through an encrypted tunnel, when in reality it has been redirected to the attacker’s server so that it can be potentially inspected.
However, in order to successfully decloak the VPN traffic, the targeted host’s DHCP client must implement DHCP option 121 and accept a DHCP lease from the attacker-controlled server.
The attack is also similar to TunnelCrack, which is designed to leak traffic outside a protected VPN tunnel when connecting to an untrusted Wi-Fi network or a rogue ISP, resulting in adversary-in-the-middle (AitM) attacks.
The problem affects all major operating systems like Windows, Linux, macOS, and iOS with the exception of Android as it does not have support for DHCP option 121. It also affects VPN tools that solely rely on routing rules to secure the host’s traffic.
Mullvad has since confirmed that the desktop versions of its software have firewall rules in place to block any traffic to public IPs outside the VPN tunnel, but acknowledged that the iOS version is vulnerable to TunnelVision.
However, it’s yet to integrate and ship a fix owing to the complexity of the undertaking, which the Swedish company said has been working on for “some time.”
“The TunnelVision vulnerability (CVE-2024-3661) exposes a method for attackers to bypass VPN encapsulation and redirect traffic outside the VPN tunnel,” Zscaler researchers said, describing it as a technique that employs a DHCP starvation attack to create a side-channel.
“This technique involves using DHCP option 121 to route traffic without encryption through a VPN, ultimately sending it to the internet via a side-channel created by the attacker.”
To mitigate TunnelVision, organizations are recommended to implement DHCP snooping, ARP protections, and port security on switches. It’s also advised to implement network namespaces on Linux to fix the behavior.
