Attackers can decloak routing-based VPNs • Hacker News Board

Re: Attackers can decloak routing-based VPNs

#201

Post by hughesjj » Tue, May 07, 2024, 7:09 PM UTC

banister wrote: post #83

morattisec wrote: post #80

Earlier quoted context omitted.

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.

Did you say the same thing about meltdown/spectre? Ramhammer?

Those are way more impractical but the industry still moved mountains (and killed perf) to mitigate them

Re: Attackers can decloak routing-based VPNs

#202

Post by hughesjj » Tue, May 07, 2024, 7:15 PM UTC

betaby wrote: post #119

StressedDev wrote: post #105

Earlier quoted context omitted.

I have never heard anyone claim that VPNs only work if DHCP can be trusted. Note that that means trusting all devices on a network because any device can be a DHCP server. This is a great find and a real security bug. I cannot believe how many people are downplaying this work.

It has nothing to do with VPN. Attack on the mined CVE is a general type of the malicious DHCP attack described in any CCNA level book since 90s.

it does expose a nuance in VPN configuration though. If we all as an industry perfectly implemented things to be 100% to the spec, and 100% understand all security considerations in the spec from the start, this would be a nothing burger.

From TFA it seems like nordvpn at minimum is affected by this, as per the user report. Lots of users assuming a lot of trust just got violated. I'm sure there's all lots of devs at the VPN vendors and network admins in corporate settings looking around to ensure the hole is plugged.

Re: Attackers can decloak routing-based VPNs

#203

Post by [deleted] » Tue, May 07, 2024, 7:32 PM UTC

berkes wrote: post #199

mrangle wrote: post #194

Earlier quoted context omitted.

>Regardless what police or governments want, they have to abide by laws I can't tell if this person actually believes what they wrote, or if it is some kind of attempted public social pressure technique meant to adjust the Overton Window from a rational place. Be it 2024 or 1624, to assert that one trusts the gov to "not fuck them over" takes a special type of naivete. It certainly takes a general obliviousness to th…

I believe what I wrote. Do note that this applies to Western Europe (more precisely: the Netherlands). And do note that "to be f#ed over" is rather broad and personal. While one person might feel they are truly "f#d" by police" when they get a ticket driving their bike without lights at night, that's obviously not what I mean. I am by conviction an Anarchist (though certainly not libertarian), and I do see the times…

[deleted]

Re: Attackers can decloak routing-based VPNs

#204

Post by sigmoid10 » Tue, May 07, 2024, 8:17 PM UTC

NoGravitas wrote: post #179

sigmoid10 wrote: post #145

Earlier quoted context omitted.

In general, Nordic countries are known for their extensive privacy laws, which in theory would make it harder for law enforcement to gain access to your traffic (and with a court order it is very easy to decloak your VPN traffic). However, as all Nordic countries are part of the Schengen Area, they are bound by European laws - and their enforcement. When Europol started cracking down on VPN providers that didn't comp…

You are missing one valid use-case: avoiding three-strikes letters being sent to your ISP by the MPA. Unless you're part of a release group, the complaints from the MPA never rise to the level of actual legal action, so your VPN provider is free to bin them, whereas your actual ISP would almost certainly act on them.

Yes of course, if you're engaged in low level criminal behaviour, then even these low levels of obfuscation will keep some pressure off your back. But since copyright law is somewhat of a grey area in the EU, you technically don't even need a VPN for that. You could run a VPS somewhere and get the same results much cheaper. But this kind of use case is not something VPN providers can advertise with anyways, so my point remains unchanged.

Re: Attackers can decloak routing-based VPNs

#205

Post by sigmoid10 » Tue, May 07, 2024, 8:23 PM UTC

jkaplowitz wrote: post #196

sigmoid10 wrote: post #145

Earlier quoted context omitted.

In general, Nordic countries are known for their extensive privacy laws, which in theory would make it harder for law enforcement to gain access to your traffic (and with a court order it is very easy to decloak your VPN traffic). However, as all Nordic countries are part of the Schengen Area, they are bound by European laws - and their enforcement. When Europol started cracking down on VPN providers that didn't comp…

HTTPS is not enough for public WiFi. Domain names get leaked due to how the TLS negotiation works, and unencrypted HTTP sites or ones with weak crypto are still more common than they should be. Plus, many public WiFi networks exist which block SSH or specific websites to keep security auditors happy while allowing VPN to make business people happy. I used such a public WiFi quite recently, which blocked not only SSH…

>I’m not aware of any Western government that has so far gained the power to force its companies to affirmatively lie about whether they have shared logs with the government

Do you see the problem with this statement?

Re: Attackers can decloak routing-based VPNs

#206

Post by remram » Tue, May 07, 2024, 9:29 PM UTC

sambazi wrote: post #136

ajsnigrutin wrote: post #100

Earlier quoted context omitted.

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

Yes but what do you mean by that?

Re: Attackers can decloak routing-based VPNs

#207

Post by varenc » Wed, May 08, 2024, 12:09 AM UTC

tristor wrote: post #181

varenc wrote: post #130

Earlier quoted context omitted.

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

Why would you be unlikely to bring your own router in a coffee-shop situation? My travel router fits in a small pouch with its power adapter and together is no larger than a couple of decks of cards. If I have my laptop, then I have my backpack, which means I have my travel router.

Hah, well I have a travel router as well I use for things like hotels, but I wouldn't really want to bring it to a coffeeshop because the setup process is a bit onerous. I need to get the travel router to connect to whatever the coffeshop's wifi is and then get through its captive portal. The last part can be tricky in my experience though it's certainly doable.

Personally I wouldn't bother with the hassle and would instead just rely on an on-device VPN which I now would need to ensure is protected from this type of attack.

Re: Attackers can decloak routing-based VPNs

#208

Post by Borealid » Wed, May 08, 2024, 12:26 AM UTC

Brian_K_White wrote: post #198

Borealid wrote: post #178

Earlier quoted context omitted.

I can see how you can write rules that block "bad traffic", but I can't see how you write them so they don't also block some "good traffic" when the network assigns a routing rule. I think the person here might be glossing over writing overzealous rules that cause the VPN connection to go down when an Option 121 route is assigned, when the ideal solution leaves the VPN functional (and causes tunneled traffic to ignor…

That has already been explained a couple times over.

I don't understand your explanation because you just keep alluding to certain firewall rules but not actually showing them.

If you've done this, could you paste an `iptables -L -v` for me? That would make clear exactly what you're talking about. If there is a problem, I could then point it out, and if there is not, I could then understand how to do what you're saying.

Re: Attackers can decloak routing-based VPNs

#209

Post by banister » Wed, May 08, 2024, 6:16 AM UTC

Borealid wrote: post #170

banister wrote: post #153

Earlier quoted context omitted.

No, you're wrong again. I just tested this (simulating routes added by a DHCP option 121) and it works exactly as I said. C is what happens. But it doesn't happen the way you say at all. Only the traffic heading to the new 121 routes are blocked - why is it blocked? because the routes are on the physical interface, and the firewall rules blocks all off-VPN traffic (except traffic to the VPN endpoint itself) The tunne…

Could you please show me a rule so I can "try it"? I'd love it if this worked. Let's say: - the physical interface name is "wlan0" - the VPN virtual interface name is "tun0" - the VPN server is 10.1.1.1 on TCP port 8888 - the DHCP server on initial lease sends "0.0.0.0/0 via 10.8.8.8" - the DHCP server on renew sends the above rule and also "10.0.0.0/8 via 10.9.9.9" - Before the renew, traffic not routed via 10.8.8.8…

Your examples are strange as you're using rfc1918 addresses (i.e private range) rather than public ips. So all your examples are very odd.

10.7.7.7 will get dropped. This is correct behaviour based on the routing rules in your example. The VPN connection will stay up as it has a /32 route setup through the wlan0 interface.

What we're concerned about with TunnelVision is preventing LEAKS, this is what constitutes VPN security. If the DHCP server sends a route that forces traffic through the physical interface instead, then the best you can do is BLOCK it. If you really wanted to you could detect and remove the route, but that's a different question and still has nothing to do with the question we're concerned about which is plugging LEAKS.

Also why on earth are you using rfc1918 addresses as an example, it's more meaningful to be using public ip addresses - i.e the DHCP server pushes a 1.1.1.1/32 route. The issue with rfc1918 addresses is it's totally not clear if they will get routed at all as you didn't specify whether they're on-link or not as you didn't provide a subnet mask.

The rules are: * an ALLOW rule on the vpn endpoint ip + a /32 route for the endpoint * an ALLOW rule on tun0 traffic * a BLOCK rule on EVERYTHING else - i.e just a iptables -I OUTPUT -j DROP

Can we please stop the back and forth now, it's really starting to chew up too much time. I don't want to have a conversation about the specific addressing scheme you're using - you should have used public ips to make things much clearer, i don't want a long argument now about subbets and whether certain addreses in your example are on-link or require a routing hop. This is so tiring. :)

Re: Attackers can decloak routing-based VPNs

#210

Post by banister » Wed, May 08, 2024, 6:26 AM UTC

Borealid wrote: post #172

banister wrote: post #154

Earlier quoted context omitted.

Read my reply to the other poster, i answer exactly this. Actually test it yourself. Stop theorizing. I tested it. It works exactly as I said. I think i know where you're confused. There is a firewall whitelist on the VPN endpoint route. Also it's impossible for the DHCP server to push a route more specific than this since it's a /32 route, so it's unaffected (together with the firewall rule allowing it) by anything…

I think you might be saying to add rules like `iptables -A OUTPUT -d /32 -j ACCEPT`, `iptables -A OUTPUT -o vpn0 -j ACCEPT`, and `iptables -A OUTPUT -j DROP`. I'm a bit confused though because you only mentioned one rule and that's three. But also, I think using that combination of rules would result in dropping all traffic that someone attempts this attack against - in other words, turning it into a denial-of-servic…

Yes exactly. It becomes a "denial of service" against the option 121 pushed subnet routes. That's already discussed in the paper, i assumed you knew that already.

There's nothing else you can do in this situation other than detecting and then removing those routes, which is possible. In lieu of deleting the routes the best and most secure option is to block that subnet. A DoS is infinitely better than a LEAK.

There are SOME things you could do (other than just removing the routes) to prevent the DoS i guess if you REALLY wanted - there is some package rewriting capabilties in the mac pf firewall and windows WFP would support this too (though it would require a 'callout' driver (kernel code) at the IP_OUTBOUND layer), and linux allows something like this too with fwmarks and multiple routing tables + a source NAT, but it's not really worth the effort in a rare case like this. Easiest just to let those packets be blocked. The network you're on is controlled by a bad actor with a malicious DHCP server. Best option for you is to GTFO.