Novel attack against virtually all VPN apps neuters their entire purpose(arstechnica.com)
arstechnica.com
Novel attack against virtually all VPN apps neuters their entire purpose
https://arstechnica.com/security/2024/05/novel-attack-against-virtually-all-vpn-apps-neuters-their-entire-purpose/
76 comments
Your writeup is IMO much better than the way this is being reported.
FWIW, I remember reading something similar years ago (I'm not certain it was your specific post, but it might have been). It's strange to see this being described as "novel" now, unless there's something new to it that I am missing.
FWIW, I remember reading something similar years ago (I'm not certain it was your specific post, but it might have been). It's strange to see this being described as "novel" now, unless there's something new to it that I am missing.
How hard is it for a firewall to block option 121 (and 33)?
Cloudflare WARP made a robust VPN but is not cheap.
Cloudflare WARP made a robust VPN but is not cheap.
It's probably more straightforward to have the firewall block all traffic from using the non-VPN interfaces (ie. blacklist approach) instead. In the other thread[1] there was disagreement about whether commercial VPN services actually implement their 'killswitch" in this way. Apparently NordVPN does not (hearsay), but neither side provided a good survey of other providers.
[1] https://news.ycombinator.com/item?id=40279632
[1] https://news.ycombinator.com/item?id=40279632
Ignoring or blocking these options is trivial but ineffective since the DHCP server can still send a malicious subnet mask.
(Edited to replace "default gateway" with "subnet mask")
(Edited to replace "default gateway" with "subnet mask")
Forgive my ignorance, but what could a malicious gateway do in this instance?
Whoops, I posted too early in the morning, I meant to say "malicious subnet mask" :-)
Basically, the DHCP server sends a subnet mask for an absolutely huge subnet (e.g. a /2), and the route for that subnet takes precedence over the VPN route. The attacker can only intercept 25% of the IPv4 address space with a /2 but that's still pretty bad.
Basically, the DHCP server sends a subnet mask for an absolutely huge subnet (e.g. a /2), and the route for that subnet takes precedence over the VPN route. The attacker can only intercept 25% of the IPv4 address space with a /2 but that's still pretty bad.
Clever, thanks!
Cloudflare Warp is free, I think - if you create a Zero Trust Organisation for free and configure the Warp client to use it, you can use unmetered Warp+ with Argo routing without charge.
Would isolating a Wireguard interface using namespaces as described here[0] mitigate this?
[0] https://www.wireguard.com/netns/#the-new-namespace-solution
[0] https://www.wireguard.com/netns/#the-new-namespace-solution
Yes, namespaces are the gold standard solution.
In addition, wg-quick appears to use the rule-based solution with multiple tables by default. As I understand it this should make Wireguard (with wg-quick) users on Linux immune to this attack. My default route sends traffic to my gateway, not my VPN:
The issue described in the article is what happens if you take the most basic approach, which is described in the Wireguard article: "instead of replacing the default route, we can just override it with two more specific rules that add up in sum to the default, but match before the default". This is historically what OpenVPN has done, and it's vulnerable to this issue.
default via <gateway ip> dev host0 proto static
The issue described in the article is what happens if you take the most basic approach, which is described in the Wireguard article: "instead of replacing the default route, we can just override it with two more specific rules that add up in sum to the default, but match before the default". This is historically what OpenVPN has done, and it's vulnerable to this issue.
In general, rule-based solutions are good if they use fwmark, but this gives me pause:
> And finally we add a convenience feature for still accessing the local network, whereby we allow packets without the fwmark to use the main routing table, not the WireGuard interface's routing table, if it matches any routes in it with a prefix length greater than zero, such as non-default local routes. [https://www.wireguard.com/netns/#improved-rule-based-routing]
Doesn't that completely neutralize the protection against a DHCP server sending malicious routes or a gigantic subnet mask?
> And finally we add a convenience feature for still accessing the local network, whereby we allow packets without the fwmark to use the main routing table, not the WireGuard interface's routing table, if it matches any routes in it with a prefix length greater than zero, such as non-default local routes. [https://www.wireguard.com/netns/#improved-rule-based-routing]
Doesn't that completely neutralize the protection against a DHCP server sending malicious routes or a gigantic subnet mask?
its just a default convenience feature from wg-quick, its not intended to be something that fits all usecases; on trusted networks split-tunneling like that makes lot of sense
"there are no ways to prevent such attacks except when the user's VPN runs on Linux or Android"
I guess it really is the year of the Linux desktop :)
I guess it really is the year of the Linux desktop :)
Sadly, I've read similar comments for 10+ years now and yet, here we still are.
Do we want Linux going mainstream?
Do you want every distro turning into Ubuntu with cloud services and telemetry all over the place ?
Do you want every distro turning into Ubuntu with cloud services and telemetry all over the place ?
As long as Trisquel, Hyperbola or Guix exist, who cares.
> who cares.
Oh most of us will definitely care once linux developers start targeting the Ubuntus instead of the Trisquels (like how developers now target "android" instead of AOSP). I mean just look at how Gnome behaves now that it is the default DE.
A truly mainstream distro would be the death of the Linux desktop. I hope that year never comes.
Oh most of us will definitely care once linux developers start targeting the Ubuntus instead of the Trisquels (like how developers now target "android" instead of AOSP). I mean just look at how Gnome behaves now that it is the default DE.
A truly mainstream distro would be the death of the Linux desktop. I hope that year never comes.
As long as the code is libre, the Ubuntu LTS releases will perfectly map the Trisquel ones.
Today, if some service needs propietary code, it's doomed to rot.
For firmware with desktop users and programmers/devops using Ubuntu at work -not an issue on servers- , it's preferable to use the Xanmod kernel with Trisquel than falling into thw whole cascade of propietary code in Ubuntu.
At least nonfree firmware it's a non burnt hardware ROM; that setup it's 90% free according to the FSF values. Also, you don't get overlayed taxing crap as snaps.
Today, if some service needs propietary code, it's doomed to rot.
For firmware with desktop users and programmers/devops using Ubuntu at work -not an issue on servers- , it's preferable to use the Xanmod kernel with Trisquel than falling into thw whole cascade of propietary code in Ubuntu.
At least nonfree firmware it's a non burnt hardware ROM; that setup it's 90% free according to the FSF values. Also, you don't get overlayed taxing crap as snaps.
Don't worry: Apples desktop quality is degrading so quickly it will be The Year of Linux on the Desktop by the end of the decade!
And yet the article goes on to say that Linux doesn't fully mitigate the issue. Confusing.
Linux doesn’t mitigate it out of the box, but you can do this: https://www.wireguard.com/netns/#the-new-namespace-solution
The real problem with all of this is that DHCP has a lot of weird legacy options that most people are not aware off and that may or may not be fully implemented on most clients, but some of which that are pretty powerful. And in practice, clients trust DHCP servers implicitly, because it's an old protocol that didn't really consider the possibility that you may be on a LAN where the DHCP cannot be trusted.
That's not really the problem - DHCP's subnet mask option is definitely not weird or legacy but can also be used to execute these attacks.
The real problem is that encrypted packets from the VPN client use the same routing table as unencrypted packets from applications. This makes it very difficult to create a robust routing policy that says "all unencrypted packets are routed via the VPN, and all encrypted packets are routed via the physical network interface".
The real problem is that encrypted packets from the VPN client use the same routing table as unencrypted packets from applications. This makes it very difficult to create a robust routing policy that says "all unencrypted packets are routed via the VPN, and all encrypted packets are routed via the physical network interface".
> The real problem is that encrypted packets from the VPN client use the same routing table as unencrypted packets from applications
worth noting that this really is very dependent on the specifics of your VPN implementation. For example StrongSwan (ipsec) and WireGuard by default afaik use separate route tables. In general using separate route tables for virtual vs physical networks is not exactly rocket science.
worth noting that this really is very dependent on the specifics of your VPN implementation. For example StrongSwan (ipsec) and WireGuard by default afaik use separate route tables. In general using separate route tables for virtual vs physical networks is not exactly rocket science.
It seems that this is only an issue if there is a malicious actor present on the remote network. I've always considered VPN services to be snakeoil, and this doesn't really seem like a problem with VPN technology at all. If you are connecting to an untrusted network, then you are at risk. This has always been true. From the VPN service providers perspective, can't this be mitigated by blocking direct traffic between clients?
But VPNs are sold as the solution for when you are on an untrusted network, like at Starbucks.
But, because of this someone can have a Pineapple with a Starbucks SSID, push option 121 and capture a WHOLE bunch of traffic, even though the person using it has configured NordVPN on their iPhone with the killswitch on.
But, because of this someone can have a Pineapple with a Starbucks SSID, push option 121 and capture a WHOLE bunch of traffic, even though the person using it has configured NordVPN on their iPhone with the killswitch on.
My VPN is for my tunnel out of my home network, not for remote networks. This is definitely a major issue if mitigations aren't implemented, but it's not relevant to all use cases for VPNs.
> It seems that this is only an issue if there is a malicious actor present on the remote network.
As I understand it, the problem comes not from the remote network provided by the VPN, but by the local network - the physical link over which the user accesses the Internet.
As I understand it, the problem comes not from the remote network provided by the VPN, but by the local network - the physical link over which the user accesses the Internet.
Ah, thanks for explaining. So this is only an issue if there is a malicious actor present on the local network. I would say that you are already compromised at that point. Say you are using public WIFI, a VPN service is pointless, you already have an anonymous public IP. Anything sensitive is encrypted end-to-end. And most public WIFI has client isolation. I suppose it could be a problem in certain countries, if your ISP can find out that you're visiting banned sites with a VPN.
eg. malicious wifi hotspot
Encapsulate and encrypt in the app itself, or in the browser.
App (via the openziti sdk): https://blog.openziti.io/no-listening-ports
Browser (the openziti js sdk loads on the fly): https://blog.openziti.io/introducing-openziti-browzer
Disclosure: openziti (apache v2) maintainer
App (via the openziti sdk): https://blog.openziti.io/no-listening-ports
Browser (the openziti js sdk loads on the fly): https://blog.openziti.io/introducing-openziti-browzer
Disclosure: openziti (apache v2) maintainer
Agree. The stated attack is not against an end to end solution.
It's because networks/routing tables aren't really designed with security principles in mind.
If they were, it would be a simple setting to set an ACL on the network interface to say "DENY all traffic except from VPN application".
If they were, it would be a simple setting to set an ACL on the network interface to say "DENY all traffic except from VPN application".
You seem to be conflating routing and firewalling/access control.
You can control your routing table using standard tools (ip route add). You can have helper applications work on it, and get hints from external sources like dhcp, where you can listen to its suggestions (IP, subnet, DNS, extra routes, and other options), or ignore them.
If you take those hints then that's your choice.
With icmp redirects you can choose to allow them or not with settings like net.ipv4.conf.all.accept_redirects.
Then as a belt and braces you have iptables. If you want an ACL on the network interface to say "DENY all traffic except from VPN application", then set your input/output/forward chains to default deny and have a rule to allow from pid=$vpn_pid. I believe you can use pid in pre/postrouting chains.
Personally when I'm travelling I have rules which only allow access to my vpn targets, and from memory just DHCP and arp. Have to temporarily disable it for captive portals but then it's back on. Sometimes a network won't accept UDP, so I generally have to tether for normal response.
You can control your routing table using standard tools (ip route add). You can have helper applications work on it, and get hints from external sources like dhcp, where you can listen to its suggestions (IP, subnet, DNS, extra routes, and other options), or ignore them.
If you take those hints then that's your choice.
With icmp redirects you can choose to allow them or not with settings like net.ipv4.conf.all.accept_redirects.
Then as a belt and braces you have iptables. If you want an ACL on the network interface to say "DENY all traffic except from VPN application", then set your input/output/forward chains to default deny and have a rule to allow from pid=$vpn_pid. I believe you can use pid in pre/postrouting chains.
Personally when I'm travelling I have rules which only allow access to my vpn targets, and from memory just DHCP and arp. Have to temporarily disable it for captive portals but then it's back on. Sometimes a network won't accept UDP, so I generally have to tether for normal response.
It is pretty simple to set routing like that on Linux.
Not my area of expertise — can somebody clarify if the DHCP server runs on your router, or your local machine? The article keeps mentioning it needs to be on the “same network” but the graphic seems like it’s all on one device.
edit: ahh I’m dumb, it’s the router (correct me if I’m wrong!). So as others have said, you have to already be on a compromised network, yes?
edit: ahh I’m dumb, it’s the router (correct me if I’m wrong!). So as others have said, you have to already be on a compromised network, yes?
DHCP is bit like hotel front and key slip. When a laptop connects to a Wi-Fi, it broadcasts DHCPDISCOVER message using the Wi-Fi card's MAC address, to which local DHCP server responds with IP address + option strings, such as subnet mask, gateway IP, local timezone(but not time), local X Window Manager address, network FQDN, and so on. Every consumer Wi-Fi router has DHCP server program included and set to auto configure, and that is how it's normally operated, but technically multiple servers can coexist within the same subnet, and the server computer doesn't have to be itself the default gateway.
Among the options strings that DHCP server may provide is DHCP option 121 Classless Static Routes, added in 2002, that can "push" routing information to clients for convenience. Apparently this option 121 can be abused to trick your laptop into set and prioritize `route add [google.com] via [malicious_host] dev wlan0` over `route add [google.com] via [vpn_right] dev vpn0` which routes traffic to [google.com], or 0.0.0.0/0 for that matter, through [malicious_host].
DHCP is more of a convenience feature for private IP address LANs, not strictly necessary for operating IP LAN. I've heard generations prior to ours sometimes leased clothespins labeled with IPs off the wall to guests, along instruction papers. DHCP completely automates that.
Among the options strings that DHCP server may provide is DHCP option 121 Classless Static Routes, added in 2002, that can "push" routing information to clients for convenience. Apparently this option 121 can be abused to trick your laptop into set and prioritize `route add [google.com] via [malicious_host] dev wlan0` over `route add [google.com] via [vpn_right] dev vpn0` which routes traffic to [google.com], or 0.0.0.0/0 for that matter, through [malicious_host].
DHCP is more of a convenience feature for private IP address LANs, not strictly necessary for operating IP LAN. I've heard generations prior to ours sometimes leased clothespins labeled with IPs off the wall to guests, along instruction papers. DHCP completely automates that.
DHCP is a client-server protocol, so it "runs" both on the router (as a server program vending available IP addresses) and the local machine (as a client program initiating the request for an IP address, and ultimately accepting the given IP address from the DHCP server on the router).
Android phones running VPNs are apparently still secure. They're recommending using phone as hotspots if you can.
There needs to be extra evidence before claiming that "virtually all VPNs apps" are vulnerable. From my understanding, they tested WireGuard on multiple platforms. However, other VPN clients may install extra firewall rules, I've seen that happen with VPNs on Windows/macOS/Linux.
So every company who uses VPNs to allow their people to get into the network from offsite (customer site, airport, hotel) now can't safely?
You basically have to trust everyone on the remote LAN to not act like a malicious DHCP server.
Reading the other thread, this wouldn't even be just the gateway.. Sounds bad!
You basically have to trust everyone on the remote LAN to not act like a malicious DHCP server.
Reading the other thread, this wouldn't even be just the gateway.. Sounds bad!
Presumably most corporate VPNs are used to access specific resources on internal company networks, so if you were affected by this, those resources would fail to load entirely.
But also, if you were using more specific routes for your corporate VPN traffic and not just forwarding all traffic through it, then the simple attack of sending two /1 rules wouldn’t interfere.
You’d still leak some metadata, but you leak a lot by using public networks anyway.
But also, if you were using more specific routes for your corporate VPN traffic and not just forwarding all traffic through it, then the simple attack of sending two /1 rules wouldn’t interfere.
You’d still leak some metadata, but you leak a lot by using public networks anyway.
> You basically have to trust everyone on the remote LAN to not
More than that when connecting via WiFi as almost everyone on a laptop does these days: you have to be careful of “evil twin” attacks from random APs nearby.
Though if you are accessing a VPN to get access to internal network resources, and someone uses this hack to redirect you, you are not going to see those resources anyway and you'll know something is wrong. Accessing any insecure resources is a risk (HTTP traffic can be monitored, fake servers could collect authentication credentials such as SSH user+pass info if not using key-based auth) but only if they are otherwise public because your redirected connection won't be able to route to your corporate network's internal hosts.
Unless I'm misreading (possible, I've only skimmed the details) those using VPNs because they already don't trust their outgoing connection, or are otherwise wanting to disguise their ID and/or location, are more at risk than road-worriers (or these days “home warriors” more likely) connecting to DayJob's VPN.
More than that when connecting via WiFi as almost everyone on a laptop does these days: you have to be careful of “evil twin” attacks from random APs nearby.
Though if you are accessing a VPN to get access to internal network resources, and someone uses this hack to redirect you, you are not going to see those resources anyway and you'll know something is wrong. Accessing any insecure resources is a risk (HTTP traffic can be monitored, fake servers could collect authentication credentials such as SSH user+pass info if not using key-based auth) but only if they are otherwise public because your redirected connection won't be able to route to your corporate network's internal hosts.
Unless I'm misreading (possible, I've only skimmed the details) those using VPNs because they already don't trust their outgoing connection, or are otherwise wanting to disguise their ID and/or location, are more at risk than road-worriers (or these days “home warriors” more likely) connecting to DayJob's VPN.
When I connect on SSH it verify the host-key. So, that would warn before submitting user/pass (but also, user-key should be used)
If doing SSH properly, yes.
Though for new hosts people often don't verify the initial host key at all, just blindly accepting it, so that would be an extra risk vector.
Heck, I'm sure many don't bother verifying a new key when they get the warning, instead just removing the old from .ssh/known_hosts (or equivalent) to quiet the complaining! Though to be honest, with that security posture nothing is going to save them and our efforts are better spent securing others! I know at least one of our clients has automated systems that ignore key changes, because we once had a temporary config cockup that sent some connections to a host with the wrong key and some data was received there without any reported issues…
Though for new hosts people often don't verify the initial host key at all, just blindly accepting it, so that would be an extra risk vector.
Heck, I'm sure many don't bother verifying a new key when they get the warning, instead just removing the old from .ssh/known_hosts (or equivalent) to quiet the complaining! Though to be honest, with that security posture nothing is going to save them and our efforts are better spent securing others! I know at least one of our clients has automated systems that ignore key changes, because we once had a temporary config cockup that sent some connections to a host with the wrong key and some data was received there without any reported issues…
On the other hand, it is fairly easy to obtain an ip, change your config to static ip reusing same ip, then and only then connect to the VPN.
It's incredibly brittle. The more frequented a network is the shorter the DHCP leases will be, I've seen public hotspots with 10 minutes of lease time.
That doesn't mean the dhcp reuse the ip if it sees it used. Some old clients do not behave correctly and I believe DHCP servers take that into account.
“Fairly easy” for those of us with a technical background. I'm not volunteering to explain that to the CEO when he hears about this and asks how he can access internal company resources safely while mobile!
They could send a /32 route for a single IP, just to decloak you.
Attack assumes that someone already controls DHCP. If bad actor controls DHCP you have a bigger problem.
It's a common scenario. Bars, coffee shops, trains, universities, etc. all offer free public wifi with DHCP outside your control.
If one is working from a non trusted network (idk, a coffee shop), isn't that true?
I would break it down in two parts.
1. Coffee shop Wi-Fi router is compromised. Than that's a possible vector.
2. Bad actor sitting in the coffee shop and trying to carry out attack similar to the one described on the link. Fortunately that won't work on any decent WiFi infra from Meraki, Ubiquiti or similar.
DHCP attacks are always a problem on dumb wired switches though.
1. Coffee shop Wi-Fi router is compromised. Than that's a possible vector.
2. Bad actor sitting in the coffee shop and trying to carry out attack similar to the one described on the link. Fortunately that won't work on any decent WiFi infra from Meraki, Ubiquiti or similar.
DHCP attacks are always a problem on dumb wired switches though.
If you dont run your network, you should assume there is a bad actor. Many wifi/router combos have a password of 'admin' or just as easy. Even if the coffee shop giving you wifi is innocent, the person that reconfigured their network in 10 seconds might not be.
DHCP servers aren't connected to any IP routing mechanisms, so there can be arbitrary numbers of so long there aren't duplicate assignments(but even that isn't DHCP problem). IIRC the client randomly chooses one if multiple offers were received.
Doesn't this blow up the attack surface area to any isp and to any place that offers free wifi? With this attack, I can't assume that it's safe to bring my laptop to a coffee shop and enable the VPN.
It's worse than that - an attacker on the same local network as the target machine can tie up the legitimate DHCP server by reserving all available addresses and then start advertising themselves as an alternate DHCP server (to inject the malicious routing to the target).
My VPN provider claims I'm not vulnerable to this by default (running this VPN endpoint on a spare ASUS Router (https://www.expressvpn.com/blog/tunnelvision-expressvpns-sta...)
One thing ive seen overlooked is the mention of trusted vs untrusted networks.
Adding routes via DHCP does nothing to my VPN that is activated by fwmark.
TLDR explanation:
- User connects to an untrusted network (public wifi).
- That network uses DHCP to assign IP address for the user.
- A malicious DHCP would push static routes via DHCP that are more specific than a common default route, and send traffic via a malicious gateway.
- User connects to his/her VPN thinking his/her traffic is secured over the insecure network.
- The malicious static routes, being more specific, take precedence over the default route added by the VPN.
- User connects to an untrusted network (public wifi).
- That network uses DHCP to assign IP address for the user.
- A malicious DHCP would push static routes via DHCP that are more specific than a common default route, and send traffic via a malicious gateway.
- User connects to his/her VPN thinking his/her traffic is secured over the insecure network.
- The malicious static routes, being more specific, take precedence over the default route added by the VPN.
And yet another time when a strict policy of "Always Ban the OhSoCoolConvenientKludgeTech for anything that could matter" turns out to look like a genius move. :(
I don't understand your comment, can you explain? What is the "OhSoCoolConvenientKludgeTech" that should be banned in this case? VPN?
I was thinking of DHCP - though the VPN tech certainly doesn't look good either.
It's really hard to make a robust VPN.