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.
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.
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.
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.
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:
default via <gateway ip> dev host0 proto static
So there's nothing for an attacker to do here. They could make themselves my gateway perhaps, but the `ip rule` would still send my traffic to Wireguard and the result would not be readable.
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?
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
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.
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
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.
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.
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.
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.
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?
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.
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).
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.
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.
> 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.
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…
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!
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.
Are there workarounds VPN clients can use to prevent this attack from working (or in the worst case, disconnect rather than send traffic outside the tunnel on a hostile network)?
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.
but you're using a vpn at the coffee shop for privacy reasons, and the compromised dhcp server will allow a malicious actor to read all of your packets anyway
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).
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. :(
It's really hard to make a robust VPN.