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

81–90 of 238 posts

Re: Attackers can decloak routing-based VPNs

#81

Post by jcrawfordor »

banister wrote: post #75
CommitSyn wrote: post #72

Earlier quoted context omitted.

FTA: Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.

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.

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 connection drops. This is indeed vulnerable to any number of potential problems, and depending on the OS and user savvy you can set up better protection using e.g. the iptables owner module. It's very non-portable though, sometimes even between Linux distributions, and hard to support at scale. Actually I'd say a true "no access except through the VPN" rule is easiest to implement on Windows, but NordVPN doesn't seem to do it there either, I'm not sure why.

To be fair, it's right in the name: a kill switch is a switch that kills things. It isn't proper network policy like per-process routing tables that are, unfortunately, difficult to implement for consumer machines.

Re: Attackers can decloak routing-based VPNs

#82

Post by megous »

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

Android doesn't even implement the new DHCP version defined first 21 years ago:

https://www.rfc-editor.org/rfc/rfc3315

So not really a surprise.

Re: Attackers can decloak routing-based VPNs

#83

Post by banister »

morattisec wrote: post #80
banister wrote: post #70

Earlier quoted context omitted.

The "side channel" is silly. You assume someone is hitting the same endpoint over and over and over and with significantly high traffic that it rises above the noise. Did u even do any of the math required to demonstrate it can actually work in a reasonable time frame? Did u clearly list the very onerous assumptions required to pull it off? This whole thing is silly.

So in the example we gave for the side-channel you’d be correct that “it depends”. We also wrote that it was flexible. I do want to point out that you could deny all traffic except allow a single IP address to test the inverse in a low traffic setting. With a low DHCP lease time it’s feasible that could look like a shaky connection. This is only possible because the kill switches don’t actually disconnect the user. T…

The side channel attack is silly and impractical. You know it's silly. I know it's silly. Let's quit pretending.

The firewall rule is 100% sufficient to defend against this exploit. All good VPNs already provide it by default. It's not deep. They're just routes.

Please stop the FUD.

Re: Attackers can decloak routing-based VPNs

#84

Post by 0x457 »

CommitSyn wrote: post #72
banister wrote: post #59

Earlier quoted context omitted.

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

FTA: Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.

Let me explain how a _very_ basic setup works: you set up a firewall rules allowing only connection to VPN on all interfaces except your VPN interface.

If you're running a torrent box, then you can do whatever your OS equivalent of "this process uses this routing table". My seed box was using interfaces that were set up in dom0 and guests didn't even know about a ways to reach outside without a VPN connection being established by the host.

The point is - "such" attacks have no legs against anything beyond "OpenVPN: Getting Started" kind of server.

Re: Attackers can decloak routing-based VPNs

#85

Post by dpifke »

wepple wrote: post #52
dinobones wrote: post #17

Earlier quoted context omitted.

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

You do not want to mix your non-anonymous and anonymous traffic over the same Tor connection, especially if you don't control the bridge (first hop) to which you're connecting.

Re: Attackers can decloak routing-based VPNs

#86

Post by tinco »

ls612 wrote: post #47
tinco wrote: post #39

Earlier quoted context omitted.

No, the attacker just has to be on the network. When on the network the attacker can deploy various techniques to become the DHCP server. Since it's (relatively) easy to become a DHCP server on a network, it's considered a big deal when the DHCP server can trick you into doing something like in this case decloaking your VPN traffic.

What is the fix for this vulnerability? Is it the router that needs to get a software update, the VPN client, the OS, or some/all of the above?

The OS needs an extra feature, and then clients need to make use of that feature. There's other workarounds listed in the "Mitigations" section of the post. But the problem is basically that everything is working as intended, for example if you disable the "Option 121" feature then under certain circumstances you might not have internet connection. Apparently Android devices don't support Option 121 at all, and it makes them unaffected by this vulnerability, but also causes to sometimes not be able to connect to networks.

Re: Attackers can decloak routing-based VPNs

#87

Post by 0x457 »

jcrawfordor wrote: post #81
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.

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…

Let's be honest, there're 2 OSs on desktop that matter to VPN providers that provide "all-in-one app" - Windows and macOS. Both have easy to configure from your application.

On linux, well, you have to choose:

- use iptables style rules regardless of the backend

or

- use nftables style rules regardless of the backend.

So it's 3 firewalls that you have to think about.

On mobile, well, on mobile you're mostly at the mercy of the platform owner and generally can't do much. Hence, why connecting phone to "SoftAP/ether_g + VPN" device is better than a direct connection.

Re: Attackers can decloak routing-based VPNs

#88

Post by banister »

jcrawfordor wrote: post #81
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.

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 really works like this i have an even lower opinion of them than i do currently).

On linux - iptables (for example) - just implement a general DROP policy then override with a specific ALLOW on the tunnel interface.

On Windows - Use WFP to implement a block everything rule, then provide a higher priority rule to allow on the tunnel interface.

All three of these techniques are the recommended way to implement a kill switch and it's used heavily in the VPN industry by anyone sensible. It completely defends against this TunnelVision exploit too.

The way that you suggest kill switch is implemented (reactive and monitoring the connection?) is very fragile, racey and prone to leak, i absolutely would not trust it and it shouldn't even be called a kill switch. It's an embarrassment. :)

Re: Attackers can decloak routing-based VPNs

#89

Post by pushedx »

threePointFive wrote: post #60
pushedx wrote: 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.

not implying anything in that regard, I can imagine a clever attack which involves a local malicious dhcp implementation

Re: Attackers can decloak routing-based VPNs

#90

Post by Dylan16807 »

banister wrote: post #75
CommitSyn wrote: post #72

Earlier quoted context omitted.

FTA: Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.

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.

Post reply on HN