This is a slight variation on the "Poison Tap" attack from Samy Kamkar in 2016, where you do the same thing but with a USB/Thunderbolt network adapter. You plug it into the victim device, advertise two more specific routes of 0.0.0.0/1 and 128.0.0.0/1 and then you get all the traffic in preference to other system interfaces despite interface ordering: https://github.com/samyk/poisontap

I imagine there is also probably some other prior art. But that's a very well known one.

They also claim that it affects all VPN clients in the headline, yet so many such clients setup firewall rules to block traffic to/from the physical interface as they acknowledge in the write-up. Most of the VPNs that are claiming to hide your identity or where such cloaking is important tend to implement that. I'm sure plenty of setups don't have it enabled by default, but I think it would have been productive to document what percentage of leading personal/commercial and corporate VPN solutions have this enabled by default.

A good write-up and explanation for the lay person, but I think the headline over-sells it a little bit given the number of clients that would prevent most of the data leak with those firewall rules and not acknowledging the prior art in this area.

I don't know why this article is so long.

DHCP Option 121 allows the DHCP server to set routing rules for a given CIDR range, which end up having a higher priority than the default 0.0.0.0/0 rule due to higher specificity (longer prefix).

I swore I had already read about this attack from some other author, so I went searching and after sifting through tons of VPN provider spam in search results I found the prior work [1].

This new article goes into some more depth on how to exploit the flaw and has some code to help PoC it though.

1: https://www.usenix.org/conference/usenixsecurity23/presentat...

The threat model is that an arbitrary attacker can somehow become the DHCP server on your LAN, which is unlikely but not impossible.

On the other hand, if you are using an ISP provided gateway device..

You can also mitigate this by placing the VPN interface in a VRF on Linux. I.e. systemd-networkd have support for doing that out of the box. One thing to watch out or is that when enabling VRF, the ip rule entry for l3mdev is listed as 1000 but rule for local traffic is listed as 0, the local rule should be moved to 1000+.

The "attack" is just a clever use of DHCP option 121. It's a valid attack against a badly broken client configuration. Just replacing the default route (or overwriting it with two /1 routes) and adding a host route to the VPN endpoint is not secure. To properly isolate the encapsulated traffic from the underlaying network you have to use proper policy based routing (e.g. Linux network namespaces, FreeBSD vnet, OpenBSD rdomains). Attempting to cobble together something with packet filters and a userspace "kill switch" is broken by design and just shows how little the common VPN hosters understand or care about their supposed core competency. Good old enumerating badness strikes again.

What else is new?

I'm more worried about people using VPN services that are IP4 only while having IP6 enabled in the system.

That can go terribly wrong...

There are numerous ways to defeat a VPN on a client device, this is why I prefer to put a router that terminates VPN tunnels with no other available routes between my clients and the Internet when I feel the need for a VPN. You can trivially set up one of these "travel routers" and carry it with you everywhere, which is exactly what I do.

This should have been pretty obvious for more technical people, but it's a nice introduction into networking and VPNs. I have configured a Linux VPN gateway VM a couple of times now and the reliance on the routing table only always felt brittle, especially when paired with running on the same machine that uses the connection.

In addition to network namespaces and physical VPN gateway routers, an architecture based on VMs can thus also solve this. In my homelab, the firewall blocks any unexpected traffic from the VPN gateway VM (devices in the VPN VLAN are not allowed any outgoing connections, the gateway VM has a separate VLAN for outgoing ones). As a personal solution, QubesOS makes configuring a similar setup quite friction-less, but once again requires more technical knowledge than a regular OS.

> because Android does not implement support for DHCP option 121, it was uniquely unaffected

Curious if that was a deliberate decision because Google knew about this or completely coincidental..

I haven't seen anywhere that said there can be a "fix" for this outside of not allowing "option 121" to be in use at all the DHCP server. Is there no way to mitigate this in the VPN client, or is it simply too fundamental to the way the networks work that there is and never can be a "fix" on the VPN client? I wouldn't expect a malware laden network's "admin" to ever fix this or even hear about it.

An interesting (and portable) alternative to network namespaces is to bypass kernel networking entirely and use a userspace network stack.

I've got an example of doing just that with my project Noisy Sockets, https://github.com/noisysockets/noisysockets/blob/main/examp...

Not a rethoric question:

Has anyone here compared western VPN services to Russian and Chinese available VPN?

I know you are trading one spy for another, but those two countries are, supposedly, not cooperating with the west. You are also raising a tall flag whem connecting to one of those two countries via VPN.

Appart from that, would it be more "Private" for the regular small time evildoer?

linux not affected if network namespaces are used to separate vpn and physical interfaces.

> We noted that because Android does not implement support for DHCP option 121, it was uniquely unaffected.

Phew, that was my biggest concern. This would've been pretty difficult to work around (as are Android's well-known VPN bypasses through system apps, but those need local execution privileges).

I saw a github project that tries to make wireguard+netns more easy to setup: https://github.com/kalken/eznetns

So for this attack does the attacker need to control your internet router? Or does it only need to control ISP infrastructure?

> We want to stress that there are ways an attacker who is on the same network as a targeted user might be able to become their DHCP server

Does this mean your ISP could also perform this attack on you?

IE: If there is a warrant for a wiretap, or otherwise your ISP is malicious?

Improvement suggestion: This article could do with an executive summary for professionals.

I have a mixed feeling about that Android keeps itself safe from this attack by not implementing DHCP option 121. IIRC Android also chooses not to support DHCPv6 intentionally.

tldr DHCP can add routes, so it can add routes for the internal network of a VPN. It’s not obvious to me why this works, because VPNs set metric 1 on their routes, that’s why traffic goes into them regardless of what IP the surrounding network used. DHCP option 121 has no metric field, so it should get a high default metric and shouldn’t have any impact on a VPN with specific routes. If you only “set the default gateway” (0.0.0.0/0 route), then this probably works. But that also seems particularly amateurish, even for enterprise VPN admins.

I recall 20 years ago: statistical attack on TOR network, namely with enough man-in-the-middle agents on TOR nodes, you actually "know"...

Well written, I appreciated the background. Far more enjoyable to read than a good deal of the incoherent articles posted on here.

When connected to a hostile network.

Is disabling DHCP a mitigation?

Cisco ASAs don't seem to support option 121. Are they immune to this one?

Same like on device vpns are pretty sketchy.

Good thing I don't use DHCP.

[dead]

Is there a tl;dr so we don't have to wade through swathes of AI generated text explaining what a network is?

This is a perfect example of the CVE mining.

There is nothing novel in the attack nor it's a security problem. DHCP environment must be trusted. We do have IP Source Guard and DHCP Snooping for decades to avoid scenarios from that link ( and many other).

always the breathless sensationalized vulnerability headlines...

it's interesting, but of limited usefulness - the device has to accept responses from a dhcp server. if an attacker controls a dhcp server, he's either on the network already or has already had to do a lot worse than installing a couple static routes to get there.

it's not nothing - a compromised home gateway could use this technique to sneak into a corporate VPN via a users' laptop, but if you have a compromised home gateway, you have a lot of other problems that could lead to the same result.

VPN can be trivially defeated any number of ways. I was shocked when I first learned this ten fifteen years ago through a site that showed my internet provider and location despite being on a VPN. I forgot the name of the site.

A huge problem that doesn't even require defeating is, most OSs and VPN clients, if the connection is shaky, just reverts to the default connection. Even a single packet is enough for your VPN to be worth nothing. In Ubuntu, it required setting up elaborate firewall rules and activate them after you get a stable VPN connection to avoid this. (and even that doesn't protect you from DNS and other stuff being able to track you) (let alone cookies which reveal who you are etc etc)