TunnelVision attack against VPNs breaks anonymity and bypasses encryption
Researchers from Leviathan Security have discovered a new vulnerability that affects virtual private networks (VPNs) on most platforms.
VPNs serve multiple purposes. They encrypt all traffic when connected to a VPN server to prevent eavesdropping and tampering. VPNs furthermore help users stay anonymous, as the VPNs IP address is revealed to websites and services.
TunnelVision is a new attack that manipulates traffic using rogue DHCP servers. All of this happens without dropping of the VPN connection or kill-switch functionality taking note and blocking all Internet connectivity. For the user, the VPN connection appears to work without issues.
TunnelVision Fact Sheet
- Works on all major platforms except for Android.
- A potential fix could be developed for Linux.
- Requires a rogue DHCP server.
- Vulnerability could date back to 2002.
TunnelVision in action
The attack requires access to a DHCP server that the target's device communicates with. The core purpose of DHCP servers is to provide and assign IP addresses to client devices.
DHCP servers support a preference called option code 121, which the attack uses to route the traffic of the target's device through the DHCP server.
The researches explain: "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."
For the attack to work, it is necessary that the target accepts "a DHCP lease" from the rogue DHCP server and that option 121 is implemented. The researches note that attackers who are on the same network as the target may "become their DHCP server" using a number of attack techniques.
Having administrative control over the network is another possibility to attack users who use VPNs to protect their data.
Some or all of a target's traffic may be routed through the unencrypted channel. The VPN program or app continues to report that all data is protected, even while that is not the case.
A proof of concept video was published on YouTube:
Potential fixes for the issue
The technical blog post lists several potential fixes or mitigations. Not all are without problems, however:
- Network Namespaces -- The feature could fix the vulnerability on Linux, but it "less commonly implemented".
- Firewall rules -- Denying all inbound and outbound traffic to and from the physical interface using firewall rules. This introduces " selective denial of service for traffic using the DHCP route" and "a side-channel".
- Ignore Option 121 -- A potential mitigation is to ignore option 121 while VPN connections are active. Android does not support the option at all, which is why it is unaffected by the vulnerability. This must be implemented on the OS level.
- Use of a hotspot or virtual machine -- Hotspots or virtual machines mitigate the vulnerability, as the attacker does not have access to this temporary network.
What about you? Do you use VPNs frequently or regularly?
I don’t trust the apps on the device itself. instead I run a client on a portable router like tplink or glinet.
While there’s that reference to Android not being affected there’s also the point that isn’t made obvious that apparently this exploit relates to WiFi connectivity. One very substantial dependency is a ‘rogue’ DHCP. So some cracker can use TunnelVision to compromise a VPN service but they also need to be able to get control of that same local network’s DHCP service. If they don’t have access to the target’s router, they can’t install their own altered DHCP configuration.
So yeah, TunnelVision is a significant and clever exploit, with a scary long-term history, But it attacks a weak point between an interaction with a VPN and the local router. So don’t let a stranger into your household and play around with your router unsupervised.
Everything but your own smartphone data is clearly unsafe. If it can fly it can be hunted. Thanks for the article!
Mullvad is immune to this attack and the previous TunnelCrack
https://mullvad.net/en/blog/evaluating-the-impact-of-tunnelvision
>”Requires a rogue DHCP server”
>”on the same network as a targeted VPN user”
>”except for Android”
That’s not an easy exploit to pull off. And the solution is simple – Don’t use coffee shop networks, just use your phone hotspot instead. But we’ve long known that for a variety of reasons, such as man-in-the-middle attacks. So this doesn’t really add any new threat that would appear to overcome existing commonsense defenses.
Doesn’t VPN software encrypt data locally on the machine before sending it off to network interfaces? I though the whole point of VPNs was to not care (for most everyday purposes at least) about which routes are taken because all the data is encrypted?
That is going to be a lot of trouble since people are unprepared.
Easy to exploit even for scriptkids.
Big thing to notice here is the generic principle, not just the “oh noes, my dirty porn habits are showing despite my VPN”. It’s also “oh no, my company IMAP emails / videoconferencing / RDP / …”.
It is not a VPN problem, it is a DHCP (and OS) security problem. But ok, easier to get attention by flagging VPN, a big victim that people have heard about and trust.
What is in play is the effects of malicious DCHP. And dhcp not being designed with security in mind. A bit like a malicious BGP message, just local you your pc instead.
A dirty DCHP can provide routing data that takes priority, diverting traffic away from the VPN or anything else you care to name (but often just to a quiet snooping MITM attacker that passes it transparently while saving data for analysis and break-in/blackmail later).
You are basically only safe if your dhcp client is not full-featured enough to just go along with that. Or you don’t use DHCP. Expect patches to roll out soon, to discard these ‘options’ and other tiresome things related to pulling off this sabotage so easily.
Other things that DHCP set up for you:
*) Your local IP address.
*) The default gateway and the subnet mask for that. I.e. where to throw internet packets and which ones are defines as subnet that do not need to go through the gateway. In realation to the article, VPNs are basically just a different and encrypted gateway.
*) It usually also sets up static address for DNS (primary and secondary).
In addition it can set up a bunch of other things. But those are the important basics.
Malicious DHCP, well, if your OS trusts messages from a DHCP server, and it does,… Then this “attack” can happen. It can point you at a snooping/evil dns server, it can direct traffic to a evil gateway.
Normally people think that VPN protect them from both. Not so with this attack. With the ‘other things’ like static routing entries – these will then have traffic directed to them before and instead of your VPN. In effect, not encrypted and not routed through the VPN gateway.
You may be thinking ‘haha, but I manually set my dns to 8.8.8.8’ well it can, by setting a routing entry, retarget that to whereever it wants and your OS will obey. You could try DOH, but that is another discussion with other drawbacks, like handing a lot of your browsing history to the DOH provider.
DCHP is not secure. And the client by definition has to be rather trusting.
It is Old Hat that this is a vulnerable situation, but sometimes the old becomes the new. DCHP was designed for closed trusted connections where the DCHP server was in trusted hands (a before lot of nasty tricks were easypeasy download you don’t even need the dark web for).
It was not for the the internet of today and the wild wild world of wifi, nor for the whole public and every criminal and spook being on the internet with you. Including every ex, every ‘frenemy’, every coworker who wants your job, every conman, blackmailer, industrial spy and nutjobs with an agenda or imagined grudge.
This is going to be big for a while, coming to every wifi hotspot near you, real-soon-now. Because now that these fools have blurted out how vulnerable dhcp really is for messing with peoples VPN then countless assholes will be out to try it in cafes, airport, on the train, …. anywhere they think people will be getting on wifi with their phone/laptop.
Not that it won’t happen on wired-only, you are just less likely to have an attacker hit this there without them already having a foothold on the network. With (public) wifi that attack surface is just much larger and the worry is (or should be) that the whole hotspot is evil.
“All of this happens without dropping of the VPN connection or kill-switch functionality taking note and blocking all Internet connectivity.”
Why did it hurt to read this sentence…?
Anyways how many people have rogue DHCP servers on their network? Sounds niche.
On paper it seems very interesting. But I think this is all theoretical nonsense played out in a controlled environment. In reality, I think, it would be impossible to actually pull that off without the VPN knowing, assuming they care at all. The question is, who would do it and why? The US federal government perhaps, to capture my porn watching habits and blackmail me info becoming a Russian spy?
We do use vpn regularly but do not use DHCP. All devices on the network have manually set ip’s bound to thier mac address.
I imagine most people don’t know what that first sentence means though.
> bound to thier mac address
DHCP reservation
Agreed. Static IP’s also prevent ARP spoofing. You can then further write firewall rules specifically for those IP’s. For all Windows users: Block ipify. Microsoft is gathering IP’s prior to you using your VPN’s! Block these: 173.231.0.0/18 65.9.66.0/24 64.185.227.156/32 104.237.62.0/24 104.26.13.205/32 172.67.74.152/32 104.26.12.205/32.