Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Novel attack against virtually all VPN apps neuters their entire purpose

arstechnica.com

Post reply on HN
Print view View original

11–20 of 77 posts

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

#11

Post by skywhopper »

avsteele wrote: post #5

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!

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.

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

#12

Post by prmoustache »

mschuster91 wrote: post #8
prmoustache wrote: post #6

Earlier quoted context omitted.

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.

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

#13

Post by this_user »

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.

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

#15

Post by gipsies »

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.

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

#16

Post by mycall »

agwa wrote: post #2

I mentioned attacks using DHCP option 121 (aka "classless static routes") nearly 9 years ago in my blog post about attacks on OpenVPN: https://www.agwa.name/blog/post/hardening_openvpn_for_def_co... (under "Attacks on redirect-gateway") It's really hard to make a robust VPN.

How hard is it for a firewall to block option 121 (and 33)?

Cloudflare WARP made a robust VPN but is not cheap.

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

#17

Post by dspillett »

avsteele wrote: post #5

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

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.

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

#18

Post by agwa »

mycall wrote: post #16
agwa wrote: post #2

I mentioned attacks using DHCP option 121 (aka "classless static routes") nearly 9 years ago in my blog post about attacks on OpenVPN: https://www.agwa.name/blog/post/hardening_openvpn_for_def_co... (under "Attacks on redirect-gateway") It's really hard to make a robust VPN.

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

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

#19

Post by agwa »

this_user wrote: post #13

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

Post reply on HN