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

Attackers can decloak routing-based VPNs

leviathansecurity.com

Post reply on HN
Print view View original

91–100 of 238 posts

Re: Attackers can decloak routing-based VPNs

#91

Post by jcrawfordor »

banister wrote: post #88
jcrawfordor wrote: post #81

Earlier quoted context omitted.

Most practical VPN services don't actually implement it this way, it's a somewhat difficult and rather OS-specific problem depending on the firewall services offered by the OS. On some popular OS like mobile ones it's just not possible at all. So just to grab an example, NordVPN's implementation does indeed work as the article presents: it monitors the VPN and disables network access for applications if the VPN conne…

Mobile is an exception (but they already state android is immune), let's stick to desktop for the sake of discussion, the 3 major desktop platforms: mac, win, linux :) On mac - just implement a block everything rule with pf and then just allow traffic on the tunnel and whitelist the VPN endpoint. Boom, a kill switch that defends against this exploit. And there's no racey nordvpn-style "control channel" (if nord reall…

I'm not saying how it should be implemented, I'm saying how it is implemented by a number of popular VPN services. Take up the argument with them. There are VPN providers that do it right on at least some platforms, but unfortunately the way most document it it's very hard to tell without experimenting with the client to verify.

As far as I know, use of the term "kill switch" closely correlates with an untrustworthy implementation. Consider the case of Mullvad who handle this a lot better and also decline to call it a "kill switch" for that reason. And that's not to say that Mullvad is perfect, easy to find forum threads by people who had traffic leakage for various reasons. I wouldn't trust anything you didn't set up yourself.

Re: Attackers can decloak routing-based VPNs

#92

Post by banister »

Dylan16807 wrote: post #90
banister wrote: post #75

Earlier quoted context omitted.

They don't know what they're talking about. Kill switches are not "tripped" there is no "control channel". A kill switch is just a firewall rule that is ALWAYS engaged and all it does is blocks off-VPN traffic. It 100% will defend against this exploit.

> A kill switch is just Not always. Some VPNs have a kill switch feature for closing specified programs. Hopefully in addition to the firewall rule.

"closing specified programs" has to be the silliest thing i've ever heard. By the time you close it, it's probably already leaked thousands of packets. The leak of a SINGLE packet is already too much.

Such an "application killing kill switch" is just marketing fluff, it makes zero sense from a security standpoint.

Re: Attackers can decloak routing-based VPNs

#93

Post by dylan604 »

tgsovlerkhgsel wrote: post #40
morattisec wrote: post #20

Earlier quoted context omitted.

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…

The PoC section doesn't explain the issue. I think a one-line TL;DR similar to the summary above would be best, e.g. "A malicious DHCP server can use DHCP Option 121 to set routing rules, which can override the routing rule used by VPNs and cause traffic to be routed outside the VPN" (I like it that you provide the background for people who need it, but also found the actually relevant information extremely annoying…

Just accept you were not the target audience and skim like the rest of the world. Not every article is written for you. It's available for you to read, but was more than likely not with you in mind. Some of us still like words and the reading of them when they provide details and more in-depth understanding than a tweet.

Re: Attackers can decloak routing-based VPNs

#94

Post by k0ss_net »

gnabgib wrote: post #49
k0ss_net wrote: post #35

I swore I had already read about this attack from some other author, so I went searching and after sifting through tons of VPN provider spam in search results I found the prior work [1]. This new article goes into some more depth on how to exploit the flaw and has some code to help PoC it though. 1: https://www.usenix.org/conference/usenixsecurity23/presentat...

That article is referenced in the Appendix: However, neither technique described in the August 2023 paper leveraged DHCP option 121 to push routes. Pushing routes through DHCP has a significantly higher impact from the same attacker vantage point (the ability to hand out IP leases for a non-RFC1918 range or spoofing DNS replies).

Ah good find, I totally missed the appendix when reading on mobile.

Re: Attackers can decloak routing-based VPNs

#95

Post by _0ffh »

bedobi wrote: post #30
Hikikomori wrote: post #22

Earlier quoted context omitted.

Just use iptables and only allow the vpn traffic. Or do the same with a small Linux box.

apparently lots of folks who do this still have problems that a lot of software that promises to do this actually only does it for ipv4, so ipv6 traffic still exposes them, lol

It's not unusual to get the recommendation to deactivate ipv6, which isn't hard (on Linux at least).

Re: Attackers can decloak routing-based VPNs

#96

Post by fargle »

Aloisius wrote: post #24
fargle wrote: post #14

always the breathless sensationalized vulnerability headlines... it's interesting, but of limited usefulness - the device has to accept responses from a dhcp server. if an attacker controls a dhcp server, he's either on the network already or has already had to do a lot worse than installing a couple static routes to get there. it's not nothing - a compromised home gateway could use this technique to sneak into a cor…

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

if you are on a public wifi, particularly if you can control an evil dhcp server, there are sooo many other ways to attack someone's pc client and network. this is just another. it doesn't even seem that unexpected.

Re: Attackers can decloak routing-based VPNs

#97

Post by acdha »

SahAssar wrote: post #55
smarx007 wrote: post #29

Earlier quoted context omitted.

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

There are super shady VPN providers but that doesn’t mean local network risks can be ignored. For example, how frequently do you hear about compromised networks of routers and access points? Attackers could be using those for far more stealthy means.

Also, remember when Verizon decided to helpfully inject cross-domain tracking cookies into their customers’ traffic? Do you really want to gamble that some MBA wouldn’t start to think about ways to monetize activity collection from VPN users? Some provider won’t sell schools, coffee shops, etc. a service which will block the “wrong” traffic and that just quietly expands to cover, say, women looking for family planning advice or college students in Florida looking for trans support?

Re: Attackers can decloak routing-based VPNs

#98

Post by rahimnathwani »

yjftsjthsd-h wrote: post #5
acer4666 wrote: post #3

Is there a tl;dr so we don't have to wade through swathes of AI generated text explaining what a network is?

An attacker who controls the DHCP server can give your device more specific routes and this apparently can cause traffic to go over those routes instead of the VPN. So if your VPN says that it's taking traffic for 0.0.0.0/0, and the DHCP server says 0.0.0.0/1 and 1.0.0.0/1 route over 10.1.1.1, then all your traffic gets sent over 10.1.1.1 because those routes are more specific so they "win". (Please feel free to corr…

> can cause traffic to go over those routes instead of the VPN

AIUI the vulnerability is more about forcing traffic via a specific interface than it is about the setting the route. The host's routing table contains at least these fields:

A) destination (IP or subnet)

B) gateway (aka route, aka next hop)

C) interface

The article says that when the route is set using DHCP Option 21, the interface field is set to the interface on which the DHCP response was received. So, if I've understood the article correctly, even if the route/gateway address is correct and not malicious, the host will send out packets for that destination via the regular (wifi or ethernet) interface, instead of the VPN interface.

Imagine a coffee shop scenario: a malicious DHCP server responds to your DHCP request. It includes Option 121, making certain traffic go to the 10.0.0.1 (the coffee shop router address). Now, even though that gateway isn't malicious, the fact that the traffic is now going over the wifi interface instead of VPN, means someone can snoop on it.

Re: Attackers can decloak routing-based VPNs

#99

Post by kccqzy »

mrbluecoat wrote: post #71

> because Android does not implement support for DHCP option 121, it was uniquely unaffected Curious if that was a deliberate decision because Google knew about this or completely coincidental..

Looking at https://issuetracker.google.com/issues/117544989 seems like Google mostly just ignored this feature request without giving any reason. I wonder the same. Perhaps someone who works at Google with access to the internal Buganizer will know more.

But if you want me to speculate, my speculation is that the team behind Android networking is highly pro-IPv6. They don't really care about missing niche features in IPv4. Even for IPv6 they have a specific vision for how IPv6 should be used, resulting in deliberate non-support of features like stateful DHCPv6.

Re: Attackers can decloak routing-based VPNs

#100

Post by ajsnigrutin »

Aloisius wrote: 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).

...and the attacker needs to be in the same L2 network as the victim to trigger the attack.

(i guess... didn't read the article, just the post above)

Post reply on HN