Attackers may be using TunnelVision to snoop on users’ VPN traffic (CVE-2024-3661)
Researchers have brought to light a new attack method – dubbed TunnelVision and uniquely identified as CVE-2024-3661 – that can be used to intercept and snoop on VPN users’ traffic by attackers who are on the same local network.
“This is particularly dangerous for people who rely on VPNs to keep them safe, such as journalists and political dissidents,” Leviathan Security researchers Dani Cronce and Lizzie Moratti explained.
The attack is imperceptible to the regular VPN user and it’s possible that there are individuals or entities out there that have been using the technique covertly for years.
“Luckily, most users who use commercial VPNs are sending web traffic which is mostly HTTPS (about 85%, actually). HTTPS traffic looks like gibberish to attackers using TunnelVision, but they know who you are sending that gibberish to which can be an issue,” the researchers noted.
“If a website is using HTTP, then it becomes possible to view everything you are saying as well as who you are saying it to.”
How the TunnelVision (CVE-2024-3661) attack works
Attackers using the TunnelVision technique effectively exploit a built-in feature of the Dynamic Host Configuration Protocol (DHCP): DHCP option 121, which allows a DHCP server to supply classless static routes for the VPN software’s routing tables.
They force the user’s VPN traffic to the local network by setting up a rogue DHCP server on the users’ local network and forcing the targeted host (with VPN client) to accept a temporary IP address from it.
“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,” the researchers explained.
They also shared a video demo of the attack and lab setup code that can work in different scenarios (compromised DHCP server/access point, the attacker owning the underlying infrastructure, “evil twin” access point).
What can be done to stymie TunnelVision attacks?
The researchers noted that TunnelVision is a more general attack technique than the previously demonstrated TunnelCrack, which relies on abusing non-RFC1918 IP ranges to leak traffic or DNS spoofing to trick the VPN client into adding a routing rule exception for an IP address. “Pushing routes through DHCP has a significantly higher impact from the same attacker vantage point,” they opined.
TunnelVision attacks don’t violating security properties of DHCP, routing tables, or VPNs.
“In our technique, we have not broken the VPN’s cryptographically secured protocol, and the VPN is still fully functional. An attacker is instead forcing a target user to not use their VPN tunnel,” Cronce and Moratti noted.
“Regardless of whether we classify this as a technique, VPN users are affected when they rely on assurances that a VPN can secure them from attackers on their local network.”
The “vulnerability” affects operating systems that implement a DHCP client according to its RFC specification and have support for DHCP option 121 routes. This list includes Windows, Linux, iOS, and macOS, but not Android because it does not support DHCP option 121.
Most (if not all) VPN solutions that rely on routing rules are affected, though some mitigate the issue by implementing firewall rules that block users’ traffic to non-VPN interfaces.
Advice for VPN providers and users
The researchers have outlined fixes and mitigations that are currently available and urged VPN providers, OS maintainers, and enterprises to implement them.
“It is common for corporate VPNs to be used in areas such as coffee shops, hotels, or airports. Network administrators should inform employees that working from such places carries risks and should be avoided when possible,” they said.
“If such a policy is not practical, then administrators should advise using VPNs that enable (…) mitigations or fixes. Some alternatives would be to use a trusted hot spot and then connect to the VPN. Lastly, running the VPN inside of a VM that obtains a lease from a virtualized DHCP server would prevent the local networks DHCP server from installing routes altogether.”
Similarly, VPN users on the consumer site should consider not using untrusted (such as public Wi-Fi) networks, using a hotspot with their VPN or using the VPN inside a virtual machine that does not have a bridged network adapter.