Live data from Hacker News

Attackers can decloak routing-based VPNs

leviathansecurity.com

51–60 of 238 posts

Re: Attackers can decloak routing-based VPNs

#51
post #25

There are numerous ways to defeat a VPN on a client device, this is why I prefer to put a router that terminates VPN tunnels with no other available routes between my clients and the Internet when I feel the need for a VPN. You can trivially set up one of these "travel routers" and carry it with you everywhere, which is exactly what I do.

If you could list some hardware and software, it would save us the effort ...

Re: Attackers can decloak routing-based VPNs

#52
post #9

VPN can be trivially defeated any number of ways. I was shocked when I first learned this ten fifteen years ago through a site that showed my internet provider and location despite being on a VPN. I forgot the name of the site. A huge problem that doesn't even require defeating is, most OSs and VPN clients, if the connection is shaky, just reverts to the default connection. Even a single packet is enough for your VPN…

Are there any router/cheap "bridge" devices that can sit between your router and the internet and force outbound communication to go through the VPN, as if it were your ISP?

There have been a bunch of these, although if you’re really that concerned, you might as well go all in with tor

A modern version of this: https://github.com/grugq/portal

Re: Attackers can decloak routing-based VPNs

#53

Earlier quoted context omitted.

I think a public wifi network effectively being able to disable someone's VPN is pretty bad.

There are lots of ways to disable vpn : basic firewall on the router, if you have access ARP poisoning if you do not.

Yes, but this disables a user's VPN without alerting the user.

Firewalling off their VPN service would cause a visible connection failure.

Re: Attackers can decloak routing-based VPNs

#54
post #15

So for this attack does the attacker need to control your internet router? Or does it only need to control ISP infrastructure?

Pretty sure the attacker has to control your DHCP server, which in ex. a home environment is usually the router.

Many networking switches/systems (e.g. UniFi from Ubiquiti) let you enable DHCP Snooping which drops Layer 2 traffic from rogue DHCP servers to prevent this:

https://en.wikipedia.org/wiki/DHCP_snooping

Re: Attackers can decloak routing-based VPNs

#55
post #10

The threat model is that an arbitrary attacker can somehow become the DHCP server on your LAN, which is unlikely but not impossible. On the other hand, if you are using an ISP provided gateway device..

> arbitrary attacker can somehow become the DHCP server on your LAN, which is unlikely but not impossible Coffee shop wi-fi? A.k.a merely the no. 1 selling point for most VPN offerings. The proper course of action in this case is to use your 4G/5G connection and not to connect to shady networks you don't trust.

> A.k.a merely the no. 1 selling point for most VPN offerings.

I thought the selling point was protection against hackers. No, was it your ISP seeing your (basically always HTTPS encrypted) traffic? Or facebook/google harvesting your data? Or russian hackers? Or watching netflix from other countries? Or data-harvesters watching your traffic? Or if you just really like downloading linux ISOs? I also think I heard something about snowden and NSA tracking in a few ads. Something something cheaper airplane tickets?

Either way, it's all scary and for the low fee of 5$ per month (sign up for 3 years and you get 3 months free with my code!) you don't have to worry your pretty little head about it anymore. Don't worry about that our company is registered in Bermuda and is just 3 months old.

Re: Attackers can decloak routing-based VPNs

#56
You can also mitigate this by placing the VPN interface in a VRF on Linux. I.e. systemd-networkd have support for doing that out of the box. One thing to watch out or is that when enabling VRF, the ip rule entry for l3mdev is listed as 1000 but rule for local traffic is listed as 0, the local rule should be moved to 1000+.

Re: Attackers can decloak routing-based VPNs

#58
I haven't seen anywhere that said there can be a "fix" for this outside of not allowing "option 121" to be in use at all the DHCP server. Is there no way to mitigate this in the VPN client, or is it simply too fundamental to the way the networks work that there is and never can be a "fix" on the VPN client? I wouldn't expect a malware laden network's "admin" to ever fix this or even hear about it.

Re: Attackers can decloak routing-based VPNs

#59
post #6

I don't know why this article is so long. DHCP Option 121 allows the DHCP server to set routing rules for a given CIDR range, which end up having a higher priority than the default 0.0.0.0/0 rule due to higher specificity (longer prefix).

One of the authors here, the intention was to provide a primer of the topics since we figured this would draw people from a nontechnical background too. That and half the information on the internet about VPNs is from VPN providers and is incorrect or not technical enough to describe how they _actually_ work. We had a sentence in the intro that was supposed to be a hyperlink to the “hey if you know this stuff you sho…

I looked at this in detail. This exploit is a nothing-burger for most decent VPNs.

A simple "leak protection" (aka Killswitch) firewall rule completely negates this attack.

All decent VPNs implement such a rule by default.

Dealing with undesirable routes (whether pre existing or pushed by a DHCP server) is nothing new or in the slightest bit hard to defend against.

If a VPN does not implement such a firewall rule already then it's likely already leaking so all this exploit demonstrates is that "A VPN without leak protection, leaks".

(I won't even mention the "side channel" attack as it's completely ridiculous)

I liked your write-up and option 121 is a little known option, so it's good to know about. But let's not pretend this thing is bigger than it is.

Re: Attackers can decloak routing-based VPNs

#60
post #10

The threat model is that an arbitrary attacker can somehow become the DHCP server on your LAN, which is unlikely but not impossible. On the other hand, if you are using an ISP provided gateway device..

"the DCHP server" implies it is somehow a special device on your network, which is a flawed assumption. DHCP works on an broadcast protocol and your device will accept the first offer. The fact that the most common residential configuration is for your DHCP to be hosted on your router and thus likely the first to respond is inconsequential to the fact that any hostile device on your network could use this exploit.
Post reply on HN