10 ms·

Attackers can decloak routing-based VPNs

446 points by dsr_ 2y ago

the8472 2y ago
linux not affected if network namespaces are used to separate vpn and physical interfaces.
acer4666 2y ago
Is there a tl;dr so we don't have to wade through swathes of AI generated text explaining what a network is?
- rahimnathwani 2y ago
  Scroll down to "What is DHCP option 121?" and start reading there.
- yjftsjthsd-h 2y ago
  An attacker who controls the DHCP server can give your device more specific routes and this apparently can cause traffic to go over those routes instead of the VPN. So if your VPN says that it's taking traffic for 0.0.0.0/0, and the DHCP server says 0.0.0.0/1 and 1.0.0.0/1 route over 10.1.1.1, then all your traffic gets sent over 10.1.1.1 because those routes are more specific so they "win". (Please feel free to correct if I've missed something; this was my interpretation of https://arstechnica.com/security/2024/05/novel-attack-against-virtually-all-vpn-apps-neuters-their-entire-purpose/ https://arstechnica.com/security/2024/05/novel-attack-agains... )
  - sixothree 2y ago
    Will static IP and gateway alleviate this threat? I guess at what level too.
    - jofla_net 2y ago
      I tend to think yes. If the initial attack as i understand it, is from a dhcp server handing out poisoned options, then if a client is set-up as static from the get-go it'll never request a lease to begin with and, well, there you have it.
  - rahimnathwani 2y ago
    > can cause traffic to go over those routes instead of the VPN AIUI the vulnerability is more about forcing traffic via a specific interface than it is about the setting the route. The host's routing table contains at least these fields: A) destination (IP or subnet) B) gateway (aka route, aka next hop) C) interface The article says that when the route is set using DHCP Option 21, the interface field is set to the interface on which the DHCP response was received. So, if I've understood the article correctly, even if the route/gateway address is correct and not malicious, the host will send out packets for that destination via the regular (wifi or ethernet) interface, instead of the VPN interface. Imagine a coffee shop scenario: a malicious DHCP server responds to your DHCP request. It includes Option 121, making certain traffic go to the 10.0.0.1 (the coffee shop router address). Now, even though that gateway isn't malicious, the fact that the traffic is now going over the wifi interface instead of VPN, means someone can snoop on it.
- krebsonsecurity 2y ago
  I interviewed some smart people about their research in story published today: https://krebsonsecurity.com/2024/05/why-your-vpn-may-not-be-as-secure-as-it-claims/ https://krebsonsecurity.com/2024/05/why-your-vpn-may-not-be-...
- morattisec 2y ago
  You probably followed the advice to read from the 121 section already but if you’re sharing this others it might be helpful to link our website that serves as a TLDR + FAQ. https://tunnelvisionbug.com/ https://tunnelvisionbug.com/ There’s also a general public advisory there that’s supposed to be for anyone non-technical but who wants to understand the issue. All this content was also written by hand over 8ish months too, no AI was used
  - wrs 2y ago
    This is a great explanation of basic networking mechanisms that most people know almost nothing about. Don’t listen to the haters. I feel that I’m in a high percentile for networking knowledge, but I didn’t know about option 121!
Aloisius 2y ago
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).
- morattisec 2y ago
  One of the authors here, the intention was to provide a primer of the topics since we figured this would draw people from a nontechnical background too. That and half the information on the internet about VPNs is from VPN providers and is incorrect or not technical enough to describe how they _actually_ work. We had a sentence in the intro that was supposed to be a hyperlink to the “hey if you know this stuff you should skip to the POC section”. I’ll make sure that gets updated/more obvious.
  - nonrandomstring 2y ago
    Good call. For a general IT audience you are speaking to, context building really helps refresh the scene before dropping the exploit. Well communicated.
  - bimguy 2y ago
    Great write up by the way. Even some technical people might not know about this, not all technical people are network experts after all.
  - tgsovlerkhgsel 2y ago
    The PoC section doesn't explain the issue. I think a one-line TL;DR similar to the summary above would be best, e.g. "A malicious DHCP server can use DHCP Option 121 to set routing rules, which can override the routing rule used by VPNs and cause traffic to be routed outside the VPN" (I like it that you provide the background for people who need it, but also found the actually relevant information extremely annoying to find.)
    - wolverine876 2y ago
formerly_proven 2y ago
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.
- ikiris 2y ago
  because unless you have matching routes, most specific wins
  - deleted 2y ago
    [deleted]
- Aloisius 2y ago
  More specific routes are higher priority than less specific ones, so 0.0.0.0/1 is chosen over one for 0.0.0.0/0 even with metric 1.
bedobi 2y ago
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)
- lxgr 2y ago
  What is a trivial way to reveal a VPN-using website visitor’s actual IP these days? Browsers have improved a lot over the last ten years. > 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. This is mostly a function of the VPN client, not the OS. Some clients will reinstate default routes pretty quickly when they lose connectivity, others are pretty sticky. At least Android even offers a specific “always-on VPN” option to prevent leaks like that.
- dinobones 2y ago
  Are there any router/cheap "bridge" devices that can sit between your router and the internet and force outbound communication to go through the VPN, as if it were your ISP?
  - bedobi 2y ago
    apparently lots of folks use Raspberry Pi's for this, which has added benefit of PiHole filtering out of ads etc no personal experience but sounds nifty, maybe there are other options too
  - Hikikomori 2y ago
    Just use iptables and only allow the vpn traffic. Or do the same with a small Linux box.
pushedx 2y ago
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..
- CodeWriter23 2y ago
  You mean like a pwned home router?
- radiowave 2y ago
  Or become the DHCP server on whatever third party wifi you're connected to.
- smarx007 2y ago
  > arbitrary attacker can somehow become the DHCP server on your LAN, which is unlikely but not impossible Coffee shop wi-fi? A.k.a merely the no. 1 selling point for most VPN offerings. The proper course of action in this case is to use your 4G/5G connection and not to connect to shady networks you don't trust.
  - SahAssar 2y ago
    > A.k.a merely the no. 1 selling point for most VPN offerings. I thought the selling point was protection against hackers. No, was it your ISP seeing your (basically always HTTPS encrypted) traffic? Or facebook/google harvesting your data? Or russian hackers? Or watching netflix from other countries? Or data-harvesters watching your traffic? Or if you just really like downloading linux ISOs? I also think I heard something about snowden and NSA tracking in a few ads. Something something cheaper airplane tickets? Either way, it's all scary and for the low fee of 5$ per month (sign up for 3 years and you get 3 months free with my code!) you don't have to worry your pretty little head about it anymore. Don't worry about that our company is registered in Bermuda and is just 3 months old.
    - acdha 2y ago
      There are super shady VPN providers but that doesn’t mean local network risks can be ignored. For example, how frequently do you hear about compromised networks of routers and access points? Attackers could be using those for far more stealthy means. Also, remember when Verizon decided to helpfully inject cross-domain tracking cookies into their customers’ traffic? Do you really want to gamble that some MBA wouldn’t start to think about ways to monetize activity collection from VPN users? Some provider won’t sell schools, coffee shops, etc. a service which will block the “wrong” traffic and that just quietly expands to cover, say, women looking for family planning advice or college students in Florida looking for trans support?
fargle 2y ago
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.
- Aloisius 2y ago
  I think a public wifi network effectively being able to disable someone's VPN is pretty bad.
  - JackSlateur 2y ago
    There are lots of ways to disable vpn : basic firewall on the router, if you have access ARP poisoning if you do not.
    - Aloisius 2y ago
      Yes, but this disables a user's VPN without alerting the user. Firewalling off their VPN service would cause a visible connection failure.
  - fargle 2y ago
    if you are on a public wifi, particularly if you can control an evil dhcp server, there are sooo many other ways to attack someone's pc client and network. this is just another. it doesn't even seem that unexpected.
    - vel0city 2y ago
      But this heavily undermines one major selling point VPN providers use: safety on public wifi and other untrusted networks.
ls612 2y ago
So for this attack does the attacker need to control your internet router? Or does it only need to control ISP infrastructure?
- yjftsjthsd-h 2y ago
  Pretty sure the attacker has to control your DHCP server, which in ex. a home environment is usually the router.
  - tinco 2y ago
    No, the attacker just has to be on the network. When on the network the attacker can deploy various techniques to become the DHCP server. Since it's (relatively) easy to become a DHCP server on a network, it's considered a big deal when the DHCP server can trick you into doing something like in this case decloaking your VPN traffic.
    - ls612 2y ago
      What is the fix for this vulnerability? Is it the router that needs to get a software update, the VPN client, the OS, or some/all of the above?
      - tinco 2y ago
        The OS needs an extra feature, and then clients need to make use of that feature. There's other workarounds listed in the "Mitigations" section of the post. But the problem is basically that everything is working as intended, for example if you disable the "Option 121" feature then under certain circumstances you might not have internet connection. Apparently Android devices don't support Option 121 at all, and it makes them unaffected by this vulnerability, but also causes to sometimes not be able to connect to networks.
  - morattisec 2y ago
    This is mostly correct, in our POC video we showcase a lab where we go from being an adjacent host on the network to being the DHCP server. We did this by DHCP starving the true DHCP server and hoarding all the leases. Then we serve our own and do not have to compete with the true DHCP. There’s network protections against this such as guest network isolation or switches with DHCP snooping protections. However, those are usually on enterprises and relying on those being in place kind of removes the point of “securing an untrusted network” like many VPN providers claim.
tristor 2y ago
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.
- AnotherGoodName 2y ago
  I highly encourage dedicated VPN routers at home with each router having it's own wifi network as a way to connect to VPNs. It's easier to connect and more reliable than locally running VPN software on each device imho. Eg. I have a router sharing wifi for 'work' with a permanently maintained vpn connection to the workplace intranet. Another sharing wifi as 'Australia' that I connect to whenever I want to watch TV from Australia with a VPN to an Australian server and lastly the standard home Internet wifi. It's super easy to do if you have a couple of old wifi routers and even cheap home ones seem to have some VPN support these days. A big advantage, aside from centralizing the VPN setup so you don't screw it up is that it's trivial to connect any device to the VPN. Just join the relevant wifi address! Boom I'm now in a VPN to Australia from any device without messing around setting up that device specifically because I connected to the 'Australia' wifi. I do this with multiple old routers but I actually think there's probably a market for a single home router that vpns to multiple locations in the world with a different wifi network for each of those just for the sake of easily having your TV/Roku/iPad appearing to be from somewhere else trivially.
  - CommitSyn 2y ago
    Is there a simple DIY? Is it as simple as running a custom router firmware or software on a small mini PC? Last I looked into this a couple years ago, it basically wasn't possible to chain multiple VPN providers on the same machine, even using VPNs, but maybe I'm misremembering. You could of course just use the built-in VPN connection of your router, but that lacks all the benefits of updated software/firewall, and I want my family to be able to watch Netflix, browse the web without running a CAPTCHAthon, etc.
k0ss_net 2y ago
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/presentation/xue https://www.usenix.org/conference/usenixsecurity23/presentat...
- gnabgib 2y ago
  That article is referenced in the Appendix: However, neither technique described in the August 2023 paper leveraged DHCP option 121 to push routes. Pushing routes through DHCP has a significantly higher impact from the same attacker vantage point (the ability to hand out IP leases for a non-RFC1918 range or spoofing DNS replies).
  - k0ss_net 2y ago
    Ah good find, I totally missed the appendix when reading on mobile.
- sambazi 2y ago
  the "attack" is widely known and is used as a config option for the openvpn client (redirect-gateway def1)
isodude 2y ago
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+.
- sargun 2y ago
  Is there a way to run an app in a specific VRF nowadays?
  - tuetuopay 2y ago
    Just like with netns using ip: `ip vrf exec <vrf> <command>`. It’s been available for a while now
  - isodude 2y ago
    Look here: https://jerryxiao.cc/archives/1004 https://jerryxiao.cc/archives/1004 Yes, it's eBPF but the solution is quite neat to be honest. And you can integrate it into systemd units.
  - deleted 2y ago
    [deleted]
EasyMark 2y ago
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.
- morattisec 2y ago
  The only fix we’ve observed in the wild was limited to Linux hosts. WireGuard has documentation about how to implement that properly using network namespaces which can be used to isolate network stacks. https://www.wireguard.com/netns/ https://www.wireguard.com/netns/ however, the VPN provider must implement it this way. In our demo we use WireGuard that is implemented without namespaces. The other operating systems do not support that feature. The mitigations we saw were firewall based rules, which create a side-channel that be used to leak the destination of traffic.
  - banister 2y ago
    The "side channel" is silly. You assume someone is hitting the same endpoint over and over and over and with significantly high traffic that it rises above the noise. Did u even do any of the math required to demonstrate it can actually work in a reasonable time frame? Did u clearly list the very onerous assumptions required to pull it off? This whole thing is silly.
    - morattisec 2y ago
      So in the example we gave for the side-channel you’d be correct that “it depends”. We also wrote that it was flexible. I do want to point out that you could deny all traffic except allow a single IP address to test the inverse in a low traffic setting. With a low DHCP lease time it’s feasible that could look like a shaky connection. This is only possible because the kill switches don’t actually disconnect the user. There’s also mitigation bypasses that are likely to be discovered, we have a few we’re working on.
jeroenhd 2y ago
> 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).
isodude 2y ago
I saw a github project that tries to make wireguard+netns more easy to setup: https://github.com/kalken/eznetns https://github.com/kalken/eznetns
- rnewme 2y ago
  What would be the opposite approach, to make sure all traffic goes through VPN, and only VPN, even if user didn't start the VPN connection (default to no connectivity)? Is there better approach then just disabling all other network interfaces?
  - isodude 2y ago
    AFAIK Wireguard will always listen in the default namespace, thus you need to isolate everything else. A fun way of doing it though is to do an ip rule that uses the VRF table, and matches on the user id. That way all traffic from certain users will always end up in the same routing table. You can go further and match on everything except the Wireguard endpoint. With iptables you can MARK the traffic you want to be differently and then catch that traffic with ip rule.
    - rnewme 2y ago
      Cool, thank you!
mrbluecoat 2y ago
> 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..
- skissane 2y ago
  There are so many DHCP options, for something like Android it makes sense to start with only supporting the bare minimum and then only enable support for an additional option if there is a requirement raised for it. Given this DHCP option isn’t commonly used, such a strategy would likely result in it not being supported, irrespective of any security concerns with it.
- megous 2y ago
  Android doesn't even implement the new DHCP version defined first 21 years ago: https://www.rfc-editor.org/rfc/rfc3315 https://www.rfc-editor.org/rfc/rfc3315 So not really a surprise.
- kccqzy 2y ago
  Looking at https://issuetracker.google.com/issues/117544989 https://issuetracker.google.com/issues/117544989 seems like Google mostly just ignored this feature request without giving any reason. I wonder the same. Perhaps someone who works at Google with access to the internal Buganizer will know more. But if you want me to speculate, my speculation is that the team behind Android networking is highly pro-IPv6. They don't really care about missing niche features in IPv4. Even for IPv6 they have a specific vision for how IPv6 should be used, resulting in deliberate non-support of features like stateful DHCPv6.
deleted 2y ago
[deleted]
betaby 2y ago
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).
- StressedDev 2y ago
  I have never heard anyone claim that VPNs only work if DHCP can be trusted. Note that that means trusting all devices on a network because any device can be a DHCP server. This is a great find and a real security bug. I cannot believe how many people are downplaying this work.
  - betaby 2y ago
    It has nothing to do with VPN. Attack on the mined CVE is a general type of the malicious DHCP attack described in any CCNA level book since 90s.
    - hughesjj 2y ago
      it does expose a nuance in VPN configuration though. If we all as an industry perfectly implemented things to be 100% to the spec, and 100% understand all security considerations in the spec from the start, this would be a nothing burger. From TFA it seems like nordvpn at minimum is affected by this, as per the user report. Lots of users assuming a lot of trust just got violated. I'm sure there's all lots of devs at the VPN vendors and network admins in corporate settings looking around to ensure the hole is plugged.
Grimeton 2y ago
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...
more_corn 2y ago
When connected to a hostile network.
- avery17 2y ago
  All networks will become hostile. Airport/airplane wifi is no longer safe as a simple example.
lathiat 2y ago
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 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.
- banister 2y ago
  Well said. This is a nothing-burger for all VPNs except the ones that are likely heavily leaking already due to the absence of basic firewall rules. Their "side channel attack" also made me spit out my drink. EDIT: looks like NordVPN (at least on mac) doesn't have those basic firewall rules and so IS vulnerable to this exploit.
  - foobiekr 2y ago
    A general rule for life is that companies making a big deal about military grade encryption or about how they are affiliated with Nordic countries are scams.
    - codetrotter 2y ago
      Yeah. But Mullvad VPN, based in Sweden, is an actual good one.
ranger_danger 2y ago
Good thing I don't use DHCP.
throwaway984393 2y ago
[dead]
exabrial 2y ago
Same like on device vpns are pretty sketchy.
throw156754228 2y ago
Well written, I appreciated the background. Far more enjoyable to read than a good deal of the incoherent articles posted on here.
caeruleus 2y ago
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.
dpeckett 2y ago
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/examples/gateway/main.go https://github.com/noisysockets/noisysockets/blob/main/examp...
throwinway 2y ago
Is disabling DHCP a mitigation?
deskr 2y ago
Improvement suggestion: This article could do with an executive summary for professionals.
crest 2y ago
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.
incomingpain 2y ago
Cisco ASAs don't seem to support option 121. Are they immune to this one?
sylware 2y ago
I recall 20 years ago: statistical attack on TOR network, namely with enough man-in-the-middle agents on TOR nodes, you actually "know"...
catlikesshrimp 2y ago
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?
gwbas1c 2y ago
> 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?
diskdance 2y ago
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.

446 points by dsr_ 2y ago

the8472 2y ago

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

acer4666 2y ago

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

rahimnathwani 2y ago
Scroll down to "What is DHCP option 121?" and start reading there.
yjftsjthsd-h 2y ago
An attacker who controls the DHCP server can give your device more specific routes and this apparently can cause traffic to go over those routes instead of the VPN. So if your VPN says that it's taking traffic for 0.0.0.0/0, and the DHCP server says 0.0.0.0/1 and 1.0.0.0/1 route over 10.1.1.1, then all your traffic gets sent over 10.1.1.1 because those routes are more specific so they "win". (Please feel free to correct if I've missed something; this was my interpretation of https://arstechnica.com/security/2024/05/novel-attack-against-virtually-all-vpn-apps-neuters-their-entire-purpose/ https://arstechnica.com/security/2024/05/novel-attack-agains... )
- sixothree 2y ago
  Will static IP and gateway alleviate this threat? I guess at what level too.
  - jofla_net 2y ago
    I tend to think yes. If the initial attack as i understand it, is from a dhcp server handing out poisoned options, then if a client is set-up as static from the get-go it'll never request a lease to begin with and, well, there you have it.
- rahimnathwani 2y ago
  > can cause traffic to go over those routes instead of the VPN AIUI the vulnerability is more about forcing traffic via a specific interface than it is about the setting the route. The host's routing table contains at least these fields: A) destination (IP or subnet) B) gateway (aka route, aka next hop) C) interface The article says that when the route is set using DHCP Option 21, the interface field is set to the interface on which the DHCP response was received. So, if I've understood the article correctly, even if the route/gateway address is correct and not malicious, the host will send out packets for that destination via the regular (wifi or ethernet) interface, instead of the VPN interface. Imagine a coffee shop scenario: a malicious DHCP server responds to your DHCP request. It includes Option 121, making certain traffic go to the 10.0.0.1 (the coffee shop router address). Now, even though that gateway isn't malicious, the fact that the traffic is now going over the wifi interface instead of VPN, means someone can snoop on it.
krebsonsecurity 2y ago
I interviewed some smart people about their research in story published today: https://krebsonsecurity.com/2024/05/why-your-vpn-may-not-be-as-secure-as-it-claims/ https://krebsonsecurity.com/2024/05/why-your-vpn-may-not-be-...
morattisec 2y ago
You probably followed the advice to read from the 121 section already but if you’re sharing this others it might be helpful to link our website that serves as a TLDR + FAQ. https://tunnelvisionbug.com/ https://tunnelvisionbug.com/ There’s also a general public advisory there that’s supposed to be for anyone non-technical but who wants to understand the issue. All this content was also written by hand over 8ish months too, no AI was used
- wrs 2y ago
  This is a great explanation of basic networking mechanisms that most people know almost nothing about. Don’t listen to the haters. I feel that I’m in a high percentile for networking knowledge, but I didn’t know about option 121!

Aloisius 2y ago

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

morattisec 2y ago
One of the authors here, the intention was to provide a primer of the topics since we figured this would draw people from a nontechnical background too. That and half the information on the internet about VPNs is from VPN providers and is incorrect or not technical enough to describe how they _actually_ work. We had a sentence in the intro that was supposed to be a hyperlink to the “hey if you know this stuff you should skip to the POC section”. I’ll make sure that gets updated/more obvious.
- nonrandomstring 2y ago
  Good call. For a general IT audience you are speaking to, context building really helps refresh the scene before dropping the exploit. Well communicated.
- bimguy 2y ago
  Great write up by the way. Even some technical people might not know about this, not all technical people are network experts after all.
- tgsovlerkhgsel 2y ago
  The PoC section doesn't explain the issue. I think a one-line TL;DR similar to the summary above would be best, e.g. "A malicious DHCP server can use DHCP Option 121 to set routing rules, which can override the routing rule used by VPNs and cause traffic to be routed outside the VPN" (I like it that you provide the background for people who need it, but also found the actually relevant information extremely annoying to find.)
  - wolverine876 2y ago

formerly_proven 2y ago

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.

ikiris 2y ago
because unless you have matching routes, most specific wins
- deleted 2y ago
  [deleted]
Aloisius 2y ago
More specific routes are higher priority than less specific ones, so 0.0.0.0/1 is chosen over one for 0.0.0.0/0 even with metric 1.

bedobi 2y ago

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)

lxgr 2y ago
What is a trivial way to reveal a VPN-using website visitor’s actual IP these days? Browsers have improved a lot over the last ten years. > 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. This is mostly a function of the VPN client, not the OS. Some clients will reinstate default routes pretty quickly when they lose connectivity, others are pretty sticky. At least Android even offers a specific “always-on VPN” option to prevent leaks like that.
dinobones 2y ago
Are there any router/cheap "bridge" devices that can sit between your router and the internet and force outbound communication to go through the VPN, as if it were your ISP?
- bedobi 2y ago
  apparently lots of folks use Raspberry Pi's for this, which has added benefit of PiHole filtering out of ads etc no personal experience but sounds nifty, maybe there are other options too
- Hikikomori 2y ago
  Just use iptables and only allow the vpn traffic. Or do the same with a small Linux box.

pushedx 2y ago

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

CodeWriter23 2y ago
You mean like a pwned home router?
radiowave 2y ago
Or become the DHCP server on whatever third party wifi you're connected to.
smarx007 2y ago
> arbitrary attacker can somehow become the DHCP server on your LAN, which is unlikely but not impossible Coffee shop wi-fi? A.k.a merely the no. 1 selling point for most VPN offerings. The proper course of action in this case is to use your 4G/5G connection and not to connect to shady networks you don't trust.
- SahAssar 2y ago
  > A.k.a merely the no. 1 selling point for most VPN offerings. I thought the selling point was protection against hackers. No, was it your ISP seeing your (basically always HTTPS encrypted) traffic? Or facebook/google harvesting your data? Or russian hackers? Or watching netflix from other countries? Or data-harvesters watching your traffic? Or if you just really like downloading linux ISOs? I also think I heard something about snowden and NSA tracking in a few ads. Something something cheaper airplane tickets? Either way, it's all scary and for the low fee of 5$ per month (sign up for 3 years and you get 3 months free with my code!) you don't have to worry your pretty little head about it anymore. Don't worry about that our company is registered in Bermuda and is just 3 months old.
  - acdha 2y ago
    There are super shady VPN providers but that doesn’t mean local network risks can be ignored. For example, how frequently do you hear about compromised networks of routers and access points? Attackers could be using those for far more stealthy means. Also, remember when Verizon decided to helpfully inject cross-domain tracking cookies into their customers’ traffic? Do you really want to gamble that some MBA wouldn’t start to think about ways to monetize activity collection from VPN users? Some provider won’t sell schools, coffee shops, etc. a service which will block the “wrong” traffic and that just quietly expands to cover, say, women looking for family planning advice or college students in Florida looking for trans support?

fargle 2y ago

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.

Aloisius 2y ago
I think a public wifi network effectively being able to disable someone's VPN is pretty bad.
- JackSlateur 2y ago
  There are lots of ways to disable vpn : basic firewall on the router, if you have access ARP poisoning if you do not.
  - Aloisius 2y ago
    Yes, but this disables a user's VPN without alerting the user. Firewalling off their VPN service would cause a visible connection failure.
- fargle 2y ago
  if you are on a public wifi, particularly if you can control an evil dhcp server, there are sooo many other ways to attack someone's pc client and network. this is just another. it doesn't even seem that unexpected.
  - vel0city 2y ago
    But this heavily undermines one major selling point VPN providers use: safety on public wifi and other untrusted networks.

ls612 2y ago

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

yjftsjthsd-h 2y ago
Pretty sure the attacker has to control your DHCP server, which in ex. a home environment is usually the router.
- tinco 2y ago
  No, the attacker just has to be on the network. When on the network the attacker can deploy various techniques to become the DHCP server. Since it's (relatively) easy to become a DHCP server on a network, it's considered a big deal when the DHCP server can trick you into doing something like in this case decloaking your VPN traffic.
  - ls612 2y ago
    What is the fix for this vulnerability? Is it the router that needs to get a software update, the VPN client, the OS, or some/all of the above?
    - tinco 2y ago
      The OS needs an extra feature, and then clients need to make use of that feature. There's other workarounds listed in the "Mitigations" section of the post. But the problem is basically that everything is working as intended, for example if you disable the "Option 121" feature then under certain circumstances you might not have internet connection. Apparently Android devices don't support Option 121 at all, and it makes them unaffected by this vulnerability, but also causes to sometimes not be able to connect to networks.
- morattisec 2y ago
  This is mostly correct, in our POC video we showcase a lab where we go from being an adjacent host on the network to being the DHCP server. We did this by DHCP starving the true DHCP server and hoarding all the leases. Then we serve our own and do not have to compete with the true DHCP. There’s network protections against this such as guest network isolation or switches with DHCP snooping protections. However, those are usually on enterprises and relying on those being in place kind of removes the point of “securing an untrusted network” like many VPN providers claim.

tristor 2y ago

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.

AnotherGoodName 2y ago
I highly encourage dedicated VPN routers at home with each router having it's own wifi network as a way to connect to VPNs. It's easier to connect and more reliable than locally running VPN software on each device imho. Eg. I have a router sharing wifi for 'work' with a permanently maintained vpn connection to the workplace intranet. Another sharing wifi as 'Australia' that I connect to whenever I want to watch TV from Australia with a VPN to an Australian server and lastly the standard home Internet wifi. It's super easy to do if you have a couple of old wifi routers and even cheap home ones seem to have some VPN support these days. A big advantage, aside from centralizing the VPN setup so you don't screw it up is that it's trivial to connect any device to the VPN. Just join the relevant wifi address! Boom I'm now in a VPN to Australia from any device without messing around setting up that device specifically because I connected to the 'Australia' wifi. I do this with multiple old routers but I actually think there's probably a market for a single home router that vpns to multiple locations in the world with a different wifi network for each of those just for the sake of easily having your TV/Roku/iPad appearing to be from somewhere else trivially.
- CommitSyn 2y ago
  Is there a simple DIY? Is it as simple as running a custom router firmware or software on a small mini PC? Last I looked into this a couple years ago, it basically wasn't possible to chain multiple VPN providers on the same machine, even using VPNs, but maybe I'm misremembering. You could of course just use the built-in VPN connection of your router, but that lacks all the benefits of updated software/firewall, and I want my family to be able to watch Netflix, browse the web without running a CAPTCHAthon, etc.

k0ss_net 2y ago

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/presentation/xue https://www.usenix.org/conference/usenixsecurity23/presentat...

gnabgib 2y ago
That article is referenced in the Appendix: However, neither technique described in the August 2023 paper leveraged DHCP option 121 to push routes. Pushing routes through DHCP has a significantly higher impact from the same attacker vantage point (the ability to hand out IP leases for a non-RFC1918 range or spoofing DNS replies).
- k0ss_net 2y ago
  Ah good find, I totally missed the appendix when reading on mobile.
sambazi 2y ago
the "attack" is widely known and is used as a config option for the openvpn client (redirect-gateway def1)

isodude 2y ago

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

sargun 2y ago
Is there a way to run an app in a specific VRF nowadays?
- tuetuopay 2y ago
  Just like with netns using ip: `ip vrf exec <vrf> <command>`. It’s been available for a while now
- isodude 2y ago
  Look here: https://jerryxiao.cc/archives/1004 https://jerryxiao.cc/archives/1004 Yes, it's eBPF but the solution is quite neat to be honest. And you can integrate it into systemd units.
- deleted 2y ago
  [deleted]

EasyMark 2y ago

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.

morattisec 2y ago
The only fix we’ve observed in the wild was limited to Linux hosts. WireGuard has documentation about how to implement that properly using network namespaces which can be used to isolate network stacks. https://www.wireguard.com/netns/ https://www.wireguard.com/netns/ however, the VPN provider must implement it this way. In our demo we use WireGuard that is implemented without namespaces. The other operating systems do not support that feature. The mitigations we saw were firewall based rules, which create a side-channel that be used to leak the destination of traffic.
- banister 2y ago
  The "side channel" is silly. You assume someone is hitting the same endpoint over and over and over and with significantly high traffic that it rises above the noise. Did u even do any of the math required to demonstrate it can actually work in a reasonable time frame? Did u clearly list the very onerous assumptions required to pull it off? This whole thing is silly.
  - morattisec 2y ago
    So in the example we gave for the side-channel you’d be correct that “it depends”. We also wrote that it was flexible. I do want to point out that you could deny all traffic except allow a single IP address to test the inverse in a low traffic setting. With a low DHCP lease time it’s feasible that could look like a shaky connection. This is only possible because the kill switches don’t actually disconnect the user. There’s also mitigation bypasses that are likely to be discovered, we have a few we’re working on.

jeroenhd 2y ago

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

isodude 2y ago

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

rnewme 2y ago
What would be the opposite approach, to make sure all traffic goes through VPN, and only VPN, even if user didn't start the VPN connection (default to no connectivity)? Is there better approach then just disabling all other network interfaces?
- isodude 2y ago
  AFAIK Wireguard will always listen in the default namespace, thus you need to isolate everything else. A fun way of doing it though is to do an ip rule that uses the VRF table, and matches on the user id. That way all traffic from certain users will always end up in the same routing table. You can go further and match on everything except the Wireguard endpoint. With iptables you can MARK the traffic you want to be differently and then catch that traffic with ip rule.
  - rnewme 2y ago
    Cool, thank you!

mrbluecoat 2y ago

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

skissane 2y ago
There are so many DHCP options, for something like Android it makes sense to start with only supporting the bare minimum and then only enable support for an additional option if there is a requirement raised for it. Given this DHCP option isn’t commonly used, such a strategy would likely result in it not being supported, irrespective of any security concerns with it.
megous 2y ago
Android doesn't even implement the new DHCP version defined first 21 years ago: https://www.rfc-editor.org/rfc/rfc3315 https://www.rfc-editor.org/rfc/rfc3315 So not really a surprise.
kccqzy 2y ago
Looking at https://issuetracker.google.com/issues/117544989 https://issuetracker.google.com/issues/117544989 seems like Google mostly just ignored this feature request without giving any reason. I wonder the same. Perhaps someone who works at Google with access to the internal Buganizer will know more. But if you want me to speculate, my speculation is that the team behind Android networking is highly pro-IPv6. They don't really care about missing niche features in IPv4. Even for IPv6 they have a specific vision for how IPv6 should be used, resulting in deliberate non-support of features like stateful DHCPv6.

deleted 2y ago

[deleted]

betaby 2y ago

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

StressedDev 2y ago
I have never heard anyone claim that VPNs only work if DHCP can be trusted. Note that that means trusting all devices on a network because any device can be a DHCP server. This is a great find and a real security bug. I cannot believe how many people are downplaying this work.
- betaby 2y ago
  It has nothing to do with VPN. Attack on the mined CVE is a general type of the malicious DHCP attack described in any CCNA level book since 90s.
  - hughesjj 2y ago
    it does expose a nuance in VPN configuration though. If we all as an industry perfectly implemented things to be 100% to the spec, and 100% understand all security considerations in the spec from the start, this would be a nothing burger. From TFA it seems like nordvpn at minimum is affected by this, as per the user report. Lots of users assuming a lot of trust just got violated. I'm sure there's all lots of devs at the VPN vendors and network admins in corporate settings looking around to ensure the hole is plugged.

Grimeton 2y ago

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

more_corn 2y ago

When connected to a hostile network.

avery17 2y ago
All networks will become hostile. Airport/airplane wifi is no longer safe as a simple example.

lathiat 2y ago

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

banister 2y ago
Well said. This is a nothing-burger for all VPNs except the ones that are likely heavily leaking already due to the absence of basic firewall rules. Their "side channel attack" also made me spit out my drink. EDIT: looks like NordVPN (at least on mac) doesn't have those basic firewall rules and so IS vulnerable to this exploit.
- foobiekr 2y ago
  A general rule for life is that companies making a big deal about military grade encryption or about how they are affiliated with Nordic countries are scams.
  - codetrotter 2y ago
    Yeah. But Mullvad VPN, based in Sweden, is an actual good one.

ranger_danger 2y ago

Good thing I don't use DHCP.

throwaway984393 2y ago

[dead]

exabrial 2y ago

Same like on device vpns are pretty sketchy.

throw156754228 2y ago

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

caeruleus 2y ago

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.

dpeckett 2y ago

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/examples/gateway/main.go https://github.com/noisysockets/noisysockets/blob/main/examp...

throwinway 2y ago

Is disabling DHCP a mitigation?

deskr 2y ago

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

crest 2y ago

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.

incomingpain 2y ago

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

sylware 2y ago

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

catlikesshrimp 2y ago

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?

gwbas1c 2y ago

> 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?

diskdance 2y ago

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.