Novel attack against virtually all VPN apps neuters their entire purpose
This article is really talking about privacy VPNs rather than all VPNs. If the attack is deployed, your traffic is no longer going through the tunnel so in a typical VPN scenario you would quickly discover that you’re unable to connect to any of the private resources you’re supposed to be able to access.
In order to work on a typical VPN setup the attacker would need to control a lot more than a rogue DHCP server to make things work—they’d have to have knowledge of the other end you’re connecting to and spin up shadow infrastructure to mimic those resources to e.g. phish your work credentials or something. It’s a lot more work that requires a lot more research, and if not executed flawlessly is easily detectable due to things you should be able to access timing out or due to TLS errors because they don’t have valid certs.
If your VPN endpoint systems are compromisd, required for this to work, the VPN is the least of your problems.
Is the attack just buying all the data the VPN providers vacuum up?
Uh, how?
$ ip ru show
0: from all lookup local
...
5270: from all lookup 52
32766: from all lookup main
32767: from all lookup default
dhcp option 121 on my system affects table main, ie ip ro show table main.
But my system will try to perform a routing lookup against table 52 first, which contains my tailscale routes and uses dev tailscale0.
Now if they knew one of my tailnet IPs, they could force a DOS by setting the dhcp router IP to one of the entries on my tailnet, which would try to force routing through the tailscale0 (effectively blocking all traffic). But that implies the attack is tailored specifically for me.
Maybe they mean if I was trying to route all of my traffic through a particular tailnet node, then the attacker could provide a more specific route to that destination and it would try to default to their route? But I am using an httpproxy without a route for that.
If I understand the exploit correctly, for the hotel use case a travel router should be able to mitigate this so long as you run your VPN on the clients behind the router and not the router itself.
This way your traffic is already encrypted when it transits the router and it doesn’t matter if traffic from the router itself is being manipulated. The attacker would just get a pile of ciphertext.
That still kind of sucks since one of the major benefits of using a travel router is that everything connected to it should be protected, but unless I’m mistaken it solves the immediate issue of fooling a client OS into bypassing VPN.
Could this be an even larger issue with routing tables - more than just VPN interfaces?
I wonder if an attacking DCHP server can insert a rogue rule to redirect traffic off of the loopback interface. If the kernel sets a rule for 127.0.0.0/8 but the attacker sets one for 127.0.0.1, then won’t the packets follow the attackers route?
“… there are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android”…
And reason # 23,758 to not run Windows…
This is as old as redteaming is.
Pushing routes through dhcp to redirect traffic and then sslstrip to get the traffic.
Even with HSTS and tls everywhere it you can spot plain text servers in corp networks because browsers made local certificates very difficult to use.
Going to point out the level of effort for this attack - including standing up a second DHCP server on the network.
While interesting, the level of effort makes this an unlikely attack in most scenarios. Your network is already compromised for this attack to work, you have bigger problems than your VPN
If you have admin access on a server already, you can probably move laterally anyway. Also, who’s to say you don’t just change the DNS server too and redirect to malicious sites.
Yea, this is a problem, but the VPN is the least of them at that point.
I use IPsec point to point and then ssh tunnel over the top. Good luck snooping on that.
A lot of people use HTTP which would be vulnerable. Route their DNS http path to your phishing login portal and you’ll be able to steal their local hosted info
That’s why when the question comes up every month or so I recommend HTTPS even though VPNs are encrypted. It serves as host validation.
So what about people who use VPNs at hotels or other public places? Those could all apply the exploit.
yeah:
~ Our technique is to run a DHCP server on the same network as a targeted VPN user
if someone can do that, then they can capture more than just VPN traffic.