Pulling this off requires high privileges in the network, so if this is done by intruder you’re probably having a Really Bad Day anyway, but might be good to know if you’re connecting to untrusted networks (public wifi etc). For now, if you need to be sure, either tether to Android - since the Android stack doesn’t implement DHCP option 121 or run VPN in VM that isn’t bridged.
Control of the DHCP server in the victim’s network is required for the attack to work.
This is not a VPN vulnerability, but a lower level networking setup manipulation that negates naive VPN setups by instructing your OS to send traffic outside of VPN tunnel.
In conclusion, if your VPN setup doesn’t include routing guards or an indirection layer, ISP controlled routers and public WiFis will make you drop out of the tunnel now that there’s a simple video instruction out there.
Do we know which VPNs do have routing guards or an indirection layer? Especially out of the “good” ones; mullvad, proton, air, and IVPN?
Mullvad has written a post about it Here.
FYI
The desktop versions (Windows, macOS and Linux) of Mullvad’s VPN app have firewall rules in place to block any traffic to public IPs outside the VPN tunnel. These effectively prevent both LocalNet and TunnelVision from allowing the attacker to get hold of plaintext traffic from the victim.
Android is not vulnerable to TunnelVision simply because it does not implement DHCP option 121, as explained in the original article about TunnelVision.
iOS is unfortunately vulnerable to TunnelVision, for the same reason it is vulnerable to LocalNet, as we outlined in our blog post about TunnelCrack. The fix for TunnelVision is probably the same as for LocalNet, but we have not yet been able to integrate and ship that to production.
I gotta say, i am really impressed with Mullvad. They’re not just a VPN seller. They write security compromise bulletins regularly and as soon as vulnerabilities show up and they actively lobby at the EU organs for more privacy laws. They really work and live their identity in every way.
Damn I might have to go back to them. I just want port forwarding, is that so much to ask?!
Control of a DHCP server. An attacker could run their own and get lucky enough for your client to choose theirs.
Native tongue doesn’t have articles, which makes me forget the implicative importance they hold in English >.<
IIRC a malicious DHCP server could also listen to ARP probes and respond to those it didn’t issue, making clients seek renegotiation, which could increase (guarantee?) the chance of client choosing malicious server.
I haven’t worked with low level networking for a good decade or two, however, so there’s that.
Yes, it could attempt ARP attacks too, though I’m not sure how that would affect DHCP traffic, since it’s broadcast, not routed. I haven’t had to work that angle.
(Also, “implicitive” should just be “implicit”; it’s already an adjective.)
I was going for “implicated”, but suffered a critical failure in my word formation attempt.
(Still better than that one time when I decided that past tense of “to bug [someone]” was “buggered”)
The title is misleading in that the attack isn’t against the VPN apps or even the VPN protocols, but against the networking stack of the operating system.
I also don’t get much value out of the statement that “every” OS except Android is vulnerable. Do they really mean all other OSes, or just what would come to mind for most people, i.e. Windows, macOS, Linux, iOS? What about the various BSDs for example?
I also don’t get much value out of the statement that “every” OS except Android is vulnerable. Do they really mean all other OSes, or just what would come to mind for most people, i.e. Windows, macOS, Linux, iOS? What about the various BSDs for example?
It’s a DHCP manipulation attack, so every RFC 3442 compliant DHCP implementation implementing option 121 would be “vulnerable” (it’s not vulnerability though). Android apparently doesn’t implement it, so it’s technically impossible to pull off against Android device. There might be others, but I’d guess most serious server/desktop OS’es implement it.
The title isn’t misleading at all, even though the “neutering their entire purpose” is a bit of a click-bait. This doesn’t affect ingress VPN at all.
It’s an attack that uses DHCP features (according to RFC).
It’s a clever way to uncloak egress VPN users, therefore it does have privacy impact since most of us use VPN for purposes of hiding out traffic from the local network and provider and there’s no “easy” fix since it’s just a clever use of existing RFC.
Slightly off topic, but it turns out Android has a different VPN vulnerability:
https://mullvad.net/en/blog/dns-traffic-can-leak-outside-the-vpn-tunnel-on-android
Only if you dont have tunnel dns configured
Its only half of the systems that are affected lol
