this post was submitted on 07 May 2024
67 points (98.6% liked)

Privacy

38854 readers
836 users here now

A place to discuss privacy and freedom in the digital world.

Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.

In this community everyone is welcome to post links and discuss topics related to privacy.

Some Rules

Related communities

much thanks to @gary_host_laptop for the logo design :)

founded 5 years ago
MODERATORS
 

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.

top 13 comments
sorted by: hot top controversial new old
[–] Slotos 37 points 1 year ago (2 children)

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.

[–] ArcaneSlime@lemmy.dbzer0.com 4 points 1 year ago* (last edited 1 year ago) (1 children)

Do we know which VPNs do have routing guards or an indirection layer? Especially out of the "good" ones; mullvad, proton, air, and IVPN?

[–] NeuronautML@lemmy.ml 6 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] ArcaneSlime@lemmy.dbzer0.com 4 points 1 year ago

Damn I might have to go back to them. I just want port forwarding, is that so much to ask?!

[–] catloaf@lemm.ee 3 points 1 year ago (1 children)

Control of a DHCP server. An attacker could run their own and get lucky enough for your client to choose theirs.

[–] Slotos 1 points 1 year ago (1 children)

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.

[–] catloaf@lemm.ee 2 points 1 year ago (1 children)

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.)

[–] Slotos 1 points 1 year ago

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”)

[–] narc0tic_bird@lemm.ee 30 points 1 year ago (3 children)

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?

[–] 0xtero@beehaw.org 13 points 1 year ago* (last edited 1 year ago)

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.

[–] floofloof@lemmy.ca 3 points 1 year ago (1 children)
[–] krolden@lemmy.ml 2 points 1 year ago

Only if you dont have tunnel dns configured

[–] delirious_owl@discuss.online 1 points 1 year ago

Its only half of the systems that are affected lol