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

131–140 of 238 posts

Re: Attackers can decloak routing-based VPNs

#131

Post by ikiris »

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.

What was the side channel attack? There’s no way I’m reading 20 pages of networking for absolute toddlers to try to find it.

Re: Attackers can decloak routing-based VPNs

#132

Post by pests »

codetrotter wrote: post #127
foobiekr wrote: post #121

Earlier quoted context omitted.

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.

Migadu for email hosting is amazing as well, also Sweden I beleive.

Re: Attackers can decloak routing-based VPNs

#133

Post by pests »

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…

In your step 4, what happens when the VPN traffic gets routed over option 121 pushed routes?

Don't you block it - thus blocking your entire VPN?

> OR it will attempt to go through the more specific option 121 pushed malicious routes added by the compromised DHCP server (depending on the destination ip of the outbound packets).

This right here... we don't want our VPN-secued traffic going out over routes broadcast by the malicious DHCP server, so you block it... right?

How does that traffic leave the local network and reach the VPN server?

Re: Attackers can decloak routing-based VPNs

#134

Post by caeruleus »

This should have been pretty obvious for more technical people, but it's a nice introduction into networking and VPNs. I have configured a Linux VPN gateway VM a couple of times now and the reliance on the routing table only always felt brittle, especially when paired with running on the same machine that uses the connection.

In addition to network namespaces and physical VPN gateway routers, an architecture based on VMs can thus also solve this. In my homelab, the firewall blocks any unexpected traffic from the VPN gateway VM (devices in the VPN VLAN are not allowed any outgoing connections, the gateway VM has a separate VLAN for outgoing ones). As a personal solution, QubesOS makes configuring a similar setup quite friction-less, but once again requires more technical knowledge than a regular OS.

Re: Attackers can decloak routing-based VPNs

#135

Post by josephcsible »

ikiris wrote: post #131
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.

What was the side channel attack? There’s no way I’m reading 20 pages of networking for absolute toddlers to try to find it.

The side channel attack lets the attacker determine whether or not you're trying to connect to certain IP addresses over your VPN. If you properly fix this, then even when the DHCP server is performing the attack, the traffic in question still goes through your VPN. If you just mitigate it, then when the DHCP server is performing the attack, the traffic will be dropped. The side channel is that if you just mitigate it, then the attacker can repeatedly start and stop the attack for specific IP addresses, while monitoring how much VPN traffic you're sending and receiving.

Re: Attackers can decloak routing-based VPNs

#136

Post by sambazi »

ajsnigrutin wrote: post #100
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)

virtual network interfaces are a thing

Re: Attackers can decloak routing-based VPNs

#137

Post by sambazi »

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

the "attack" is widely known and is used as a config option for the openvpn client (redirect-gateway def1)

Re: Attackers can decloak routing-based VPNs

#139

Post by mschuster91 »

smarx007 wrote: post #29
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..

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

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

Sadly, there are carriers on this planet who think it's a good idea to charge ridiculous prices for mobile data (Germany) or to block hotspot functionality unless you pay up (US, see [1] for the technical background - both Apple and Google are complicit). In a world where politicians would care about their people, there would be no need for wifi hotspots to exist in the first place.

Additionally, there are certain advertising brokers such as utiq that cooperate with major phone networks to provide detailed tracking, so they and advertisers know pretty precisely who you are just because you tethered your laptop to your phone.

And finally, you can't trust your phone ISP either - Verizon got caught red-handed injecting tracking "supercookies" into their customers' traffic [2], thank God at least that vector got closed with everyone and their dog going HTTPS.

In general: anything involving residential ISPs is rife with scams.

[1] https://news.ycombinator.com/item?id=20460438

[2] http://webpolicy.org/2014/10/24/how-verizons-advertising-hea...

Post reply on HN