Watch out for rogue DHCP servers decloaking your VPN connections
Avoid traffic-redirecting snoops who have TunnelVision
A newly discovered vulnerability undermines countless VPN clients in that their traffic can be quietly routed away from their encrypted tunnels and intercepted by snoops on the network.
Dubbed TunnelVision by the eggheads at Leviathan Security Group who uncovered and documented it, the technique (CVE-2024-3661) can result in a VPN user believing their connection is properly secured, and being routed through an encrypted tunnel as usual, while an attacker on their network has instead redirected their connections so that it can be potentially inspected.
To make matters worse, the issue involves DHCP, meaning it mostly doesn't matter which VPN is being used or what OS it's running on - you're probably vulnerable. Unless you're on Android; more on that later.
"Furthermore, the strength of the encryption algorithm a VPN uses makes no difference," Leviathan Security noted. "TunnelVision's effect is independent of the underlying VPN protocol because it reconfigures the operating system network stack the VPN relies on."
Anyone who is able to operate a DHCP server on the same network as someone using a VPN, and get that VPN client's machine to use that DHCP server, can decloak their traffic because of a particular feature in the configuration protocol: option 121, which allows administrators to add classless static routes to client routing tables.
As Leviathan Security put it, to exploit someone's VPN client:
The targeted host must accept a DHCP lease from the attacker-controlled server.
The targeted host’s DHCP client must implement DHCP option 121.
Said DHCP server could be on a public network, such as some airport or hotel Wi-Fi. That DHCP system could be run by a crooked net administrator although the Leviathan team explained how anyone else on the network could set up a DHCP server to undermine VPN clients on that LAN, by suggesting the following three scenarios:
1. A rogue DHCP server using a DHCP starvation attack against the true DHCP, then responding to new clients. We have achieved this in lab environments and are working on a follow-up blog post.
2. A rogue DHCP server racing to respond to DHCPDISCOVER broadcasts to abuse DHCP clients’ common behavior where they implement first-offer lease selection.
3. ARP spoofing to intercept traffic between the true DHCP server and client, then waiting for a client to renew their lease.
Once a miscreant is in a position to issue DHCP leases to a target's machine, they can use option 121 to force all data - even traffic that's supposed to be destined for a VPN tunnel - through a gateway set up by the DHCP server and then read whatever traffic they can.
As always with VPN security issues, if an eavesdropper intercepts your, say, HTTPS/TLS or SSH encrypted connections, that snoop can't easily read the content of those connections; anything going plain text through your tunnel can be accessed by the snoop, though.
"Most users who use commercial VPNs are sending web traffic which is mostly HTTPS," as Leviathan's Dani Cronce and Lizzie Moratti put it. "HTTPS traffic looks like gibberish to attackers using TunnelVision. But they know who you are sending that gibberish to which can be an issue."
In Cronce and Moratti's testing, their VPN software never reported an issue with the connection, and kill switches that were supposed to flip when the VPN routes were interrupted were never triggered.
This isn't a particularly new issue, either. "We … believe this technique may have been possible as far back as 2002 and could have already been discovered and potentially used in the wild," the duo said, adding that their work is an evolution of the TunnelCrack exploit we covered last year among other prior research.
Very Public Networks
As mentioned above, the type of VPN targeted by TunnelVision doesn't really matter, and in all but a single case the operating system doesn't matter either. Android users are safe because the OS doesn't support DHCP option 121.
So, what can be done to protect VPN users, who are seeming quite vulnerable in light of this discovery? That's tricky.
"TunnelVision doesn't rely on violating any security properties of the underlying technologies," the researchers noted. "From our perspective, TunnelVision is how DHCP, routing tables, and VPNs are intended to work."
The only true solution, for Linux folk anyway, is to enable network namespaces; everything else is a workaround that's not entirely guaranteed to work, it's said. Non-Linux OS makers are urged to implement network namespaces if they haven't already.
- Curious tale of broken VPNs, the Year 2038, and certs that expired 100 years ago
- Microsoft confesses April Windows update breaks some VPN connections
- Google One VPN axed for everyone but Pixel loyalists ... for now
- There's a good chance your VPN is vulnerable to privacy-menacing TunnelCrack attack
The duo offer some firewall-level mitigations but warn these "create a selective denial of service for traffic using the DHCP route and introduce a side-channel." Check out the above write-ups for more details.
If it's possible to tell your system to ignore DHCP rule 121 while a VPN is active, that would be a good plan, and Leviathan also recommends using a VPN through a dedicated, password-protected wireless hotspot for an added layer of security. Their suggestions for VPN users is:
Do not use untrusted networks (public Wi-Fi).
Consider using a hotspot with your VPN.
Consider using a VPN inside a virtual machine that does not have a bridged network adapter.
And for VPN providers:
Review and update your marketing: do not claim untrusted networks can be secured by you.
Where possible, use network namespaces features in your product.
Consider host-based firewall protections to partially mitigate local network attacks.
The bottom line is that when using a VPN client on a public or untrusted network with a host machine that supports DHCP option 121, consider preventing that option from being used or take steps to protect the client, such as by putting it on its own network.
Putting in place measures to detect and block rogue DHCP servers would be helpful too on more serious networks.
"All mitigations we've observed still expose a serious issue for users who rely on total privacy of their connection, and the issue can also be abused for censorship," Cronce and Moratti said. "We feel that [fixing this is] a shared responsibility, and the people who suffer from this are VPN users." ®