"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 :)
Novel attack against virtually all VPN apps neuters their entire purpose
21–30 of 77 posts
Re: Novel attack against virtually all VPN apps neuters their entire purpose
#22It 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?
Re: Novel attack against virtually all VPN apps neuters their entire purpose
#23"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 :)
Sadly, I've read similar comments for 10+ years now and yet, here we still are.
Re: Novel attack against virtually all VPN apps neuters their entire purpose
#24So 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 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 i…
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)
Re: Novel attack against virtually all VPN apps neuters their entire purpose
#25And 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?
Re: Novel attack against virtually all VPN apps neuters their entire purpose
#26So 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!
They could send a /32 route for a single IP, just to decloak you.
Re: Novel attack against virtually all VPN apps neuters their entire purpose
#27It 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…
> 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.
Re: Novel attack against virtually all VPN apps neuters their entire purpose
#28Earlier quoted context omitted.
How hard is it for a firewall to block option 121 (and 33)? Cloudflare WARP made a robust VPN but is not cheap.
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")
Forgive my ignorance, but what could a malicious gateway do in this instance?
Re: Novel attack against virtually all VPN apps neuters their entire purpose
#29Earlier quoted context omitted.
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")
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.
Re: Novel attack against virtually all VPN apps neuters their entire purpose
#30Would isolating a Wireguard interface using namespaces as described here[0] mitigate this? [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:
default via 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.