I mentioned attacks using DHCP option 121 (aka "classless static routes") nearly 9 years ago in my blog post about attacks on OpenVPN: <a href="https://www.agwa.name/blog/post/hardening_openvpn_for_def_con" rel="nofollow">https://www.agwa.name/blog/post/hardening_openvpn_for_def_co...</a> (under "Attacks on redirect-gateway")<p>It's really hard to make a robust VPN.
Would isolating a Wireguard interface using namespaces as described here[0] mitigate this?<p>[0] <a href="https://www.wireguard.com/netns/#the-new-namespace-solution" rel="nofollow">https://www.wireguard.com/netns/#the-new-namespace-solution</a>
"there are no ways to prevent such attacks except when the user's VPN runs on Linux or Android"<p>I guess it really is the year of the Linux desktop :)
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.
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?
Encapsulate and encrypt in the app itself, or in the browser.<p>App (via the openziti sdk):
<a href="https://blog.openziti.io/no-listening-ports" rel="nofollow">https://blog.openziti.io/no-listening-ports</a><p>Browser (the openziti js sdk loads on the fly):
<a href="https://blog.openziti.io/introducing-openziti-browzer" rel="nofollow">https://blog.openziti.io/introducing-openziti-browzer</a><p>Disclosure: openziti (apache v2) maintainer
It's because networks/routing tables aren't really designed with security principles in mind.<p>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".
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.<p>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?
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?<p>You basically have to trust everyone on the remote LAN to not act like a malicious DHCP server.<p>Reading the other thread, this wouldn't even be just the gateway.. Sounds bad!
My VPN provider claims I'm not vulnerable to this by default (running this VPN endpoint on a spare ASUS Router (<a href="https://www.expressvpn.com/blog/tunnelvision-expressvpns-statement-and-assessment-of-the-technique/" rel="nofollow">https://www.expressvpn.com/blog/tunnelvision-expressvpns-sta...</a>)
TLDR explanation:<p>- User connects to an untrusted network (public wifi).<p>- That network uses DHCP to assign IP address for the user.<p>- 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.<p>- User connects to his/her VPN thinking his/her traffic is secured over the insecure network.<p>- 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. :(