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

121–130 of 238 posts

Re: Attackers can decloak routing-based VPNs

#121

Post by foobiekr »

banister wrote: post #112
lathiat wrote: post #110

This is a slight variation on the "Poison Tap" attack from Samy Kamkar in 2016, where you do the same thing but with a USB/Thunderbolt network adapter. You plug it into the victim device, advertise two more specific routes of 0.0.0.0/1 and 128.0.0.0/1 and then you get all the traffic in preference to other system interfaces despite interface ordering: https://github.com/samyk/poisontap I imagine there is also probabl…

Well said. This is a nothing-burger for all VPNs except the ones that are likely heavily leaking already due to the absence of basic firewall rules. Their "side channel attack" also made me spit out my drink. EDIT: looks like NordVPN (at least on mac) doesn't have those basic firewall rules and so IS vulnerable to this exploit.

A general rule for life is that companies making a big deal about military grade encryption or about how they are affiliated with Nordic countries are scams.

Re: Attackers can decloak routing-based VPNs

#123

Post by Dylan16807 »

banister wrote: post #92
Dylan16807 wrote: post #90

Earlier quoted context omitted.

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

Well to be fair I'm not sure if they kill the programs before or after disconnecting the VPN interface.

I'd sure hope it's before.

Re: Attackers can decloak routing-based VPNs

#125

Post by madars »

CommitSyn wrote: post #76
AnotherGoodName wrote: post #50

Earlier quoted context omitted.

I highly encourage dedicated VPN routers at home with each router having it's own wifi network as a way to connect to VPNs. It's easier to connect and more reliable than locally running VPN software on each device imho. Eg. I have a router sharing wifi for 'work' with a permanently maintained vpn connection to the workplace intranet. Another sharing wifi as 'Australia' that I connect to whenever I want to watch TV fr…

Is there a simple DIY? Is it as simple as running a custom router firmware or software on a small mini PC? Last I looked into this a couple years ago, it basically wasn't possible to chain multiple VPN providers on the same machine, even using VPNs, but maybe I'm misremembering. You could of course just use the built-in VPN connection of your router, but that lacks all the benefits of updated software/firewall, and I…

https://kiljan.org/2021/12/14/vpn-as-wan-for-guest-network-o... is a great start for how to set up a WiFi network with an always-on VPN

Re: Attackers can decloak routing-based VPNs

#127

Post by codetrotter »

foobiekr wrote: post #121
banister wrote: post #112

Earlier quoted context omitted.

Well said. This is a nothing-burger for all VPNs except the ones that are likely heavily leaking already due to the absence of basic firewall rules. Their "side channel attack" also made me spit out my drink. EDIT: looks like NordVPN (at least on mac) doesn't have those basic firewall rules and so IS vulnerable to this exploit.

A general rule for life is that companies making a big deal about military grade encryption or about how they are affiliated with Nordic countries are scams.

Yeah. But Mullvad VPN, based in Sweden, is an actual good one.

Re: Attackers can decloak routing-based VPNs

#128

Post by tgsovlerkhgsel »

mindslight wrote: post #120
dylan604 wrote: post #93

Earlier quoted context omitted.

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.

I hate tweet culture as much as anybody, but this is not the alternative. This article is so painfully long, I got bored even just trying to skim it. Reading it word for word will turn any noob into a seasoned greybeard through the sheer passage of time. If you really like words and reading them this much, I'd recommend adding some dictionaries to your reading list.

ChatGPT is great for providing endless reading material too!

Re: Attackers can decloak routing-based VPNs

#129

Post by Borealid »

banister wrote: post #116
Borealid wrote: post #113

Earlier quoted context omitted.

If you're connected to a random network, whose configuration you don't know in advance, how do you route packets to your VPN server? The usual answer is that the network's router tells you how to do that, by supplying DHCP options. The point I'm making here is that you can't just configure a firewall rule and have it work properly. What actually needs to happen is that the VPN client software is using one routing tab…

Let's walk through this step by step because there's a lot of confusion on your end. * Step one - You connect your computer to a network - yes you'll get a DHCP lease, and you'll get an ip address, and a default gateway. This default route will be added to your routing table. * Step two - If the TunnelVision exploit (DHCP option 121) is at play you'll also get a few MORE SPECIFIC routes than the default gateway. Thes…

I think you missed a step in your progression.

Step one, you connect to the network and get routes.

Step two, you connect your VPN.

Step three, your host starts sending traffic. At this point, your firewall rules are now active and dropping any traffic you've told them to.

Step four, you renew your DHCP lease and get new routes via option 121. Those routes might be malicious, or they might not.

One of three things is true at step four. Either:

A. Your firewall rules will block all traffic over the new routes

B. Your firewal rules will not block any traffic over the new routes

C. Your firewall rules will block some subset of traffic over the new routes

If A is true, then your VPN tunnel goes down (undesirable), as the VPN server can no longer be contacted.

If B is true, then you are vulnerable to the TunnelVision exploit.

If C is true, and the subset of traffic blocked is exactly the subset intended to route over the VPN but maliciously diverted, then the VPN tunnel goes down because the firewall rules are blocking its traffic.

If C is true, and somehow the firewall rule is rewriting the traffic that's pointed not-over-the-VPN to be instead routed over the VPN (by using NAT?), then the VPN tunnel stays up and there is no problem.

I'd be interested in seeing the set of firewall rules that will let the VPN tunnel stay up, with management traffic going over the added-after-the-tunnel-was-brought-up next-hop, and tunneled traffic continuing to flow ignoring the new route. I haven't seen those rules in the past so if you have experience writing them, please show me.

Personally I've only used Linux multiple routing tables to plug this leak.

EDIT: formatting

Re: Attackers can decloak routing-based VPNs

#130

Post by varenc »

tristor wrote: 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.

The attack is only possible when you have untrusted devices on your local LAN. If you’re already bringing your own gateway with a VPN on it then I’m guessing untrusted LAN devices aren’t much of a concern. But if you did have something untrusted on your LAN and you’re using DHCP, then that untrusted device could snoop your unencrypted* traffic with this trick, albeit it couldn’t find your real IP since your gateway is concealing that.

The attack seems most feasible in a coffee shop wifi situation, where you’re unlikely to be bringing your own router.

*by “unencrypted traffic” I mean traffic that’s not encapsulated for transport to your VPN provider. Most everything is HTTPS nowadays so the contents of that traffic would still be encrypted of course.

Post reply on HN