Live data from Hacker News

Novel attack against virtually all VPN apps neuters their entire purpose

arstechnica.com

61–70 of 77 posts

Re: Novel attack against virtually all VPN apps neuters their entire purpose

#61
post #19

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 a…

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

Re: Novel attack against virtually all VPN apps neuters their entire purpose

#62
post #34

"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 :)

So, it sounds like something that can be trivially implemented just as well on Windows, macOS, iOS, and xBSD? If Linux can do it, why not the others?

I'd imagine on openbsd rdomains might help here, but I'm not openbsd guru

Re: Novel attack against virtually all VPN apps neuters their entire purpose

#63

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

It is pretty simple to set routing like that on Linux.

Re: Novel attack against virtually all VPN apps neuters their entire purpose

#64
post #35
post #30

Earlier quoted context omitted.

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 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 t…

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

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

Re: Novel attack against virtually all VPN apps neuters their entire purpose

#65

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…

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.

Re: Novel attack against virtually all VPN apps neuters their entire purpose

#66
post #50
post #43

Earlier quoted context omitted.

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.

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

Yes. On Linux there are methods to put VPN in a namespace and thus avoid the issue.

Re: Novel attack against virtually all VPN apps neuters their entire purpose

#67
post #29

Earlier quoted context omitted.

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.

Clever, thanks!

Re: Novel attack against virtually all VPN apps neuters their entire purpose

#69

Earlier quoted context omitted.

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 the coffee shop is not offering VPN services, at least none that I would accept.

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

Re: Novel attack against virtually all VPN apps neuters their entire purpose

#70

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…

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.
Post reply on HN