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

211–220 of 238 posts

Re: Attackers can decloak routing-based VPNs

#211

Post by Borealid »

banister wrote: post #210
Borealid wrote: post #172

Earlier quoted context omitted.

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

Okay, I'm glad we've got that sorted out.

What I do is put the VPN client into a tagged network namespace (yes, fwmark), and then have a routing rule that makes everything else use a separate routing table.

The DHCP server inserts rules into the routing table used only by the VPN client.

Doing it that way, all leaks are prevented, and also there's no way to denial-of-service traffic within the tunnel - no matter what routes are pushed, it keeps flowing as normal.

No source NAT is required, only `MANGLE`.

Re: Attackers can decloak routing-based VPNs

#212

Post by Borealid »

banister wrote: post #209
Borealid wrote: post #170

Earlier quoted context omitted.

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…

I used RFC1918 addresses as examples only.

10.7.7.7 shouldn't get dropped, because it's supposed to be routed over the VPN. The DHCP server shouldn't be able to cause VPN-bound traffic to be dropped, in my opinion.

As I replied to one of your other comments, I don't think making the attack go from privacy-breach to denial-of-service is "preventing" the attack: you've only partially mitigated it. Full mitigation requires more than the firewall rules you've described.

Said differently, a malicious DHCP server should not be able to denial-of-service traffic within your VPN (or, by selectively pushing routes and then observing the impact on generated traffic, probabalistically determine the IPs with which you're communicating!).

Re: Attackers can decloak routing-based VPNs

#213

Post by banister »

Borealid wrote: post #211
banister wrote: post #210

Earlier quoted context omitted.

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

Okay, I'm glad we've got that sorted out. What I do is put the VPN client into a tagged network namespace (yes, fwmark), and then have a routing rule that makes everything else use a separate routing table. The DHCP server inserts rules into the routing table used only by the VPN client. Doing it that way, all leaks are prevented, and also there's no way to denial-of-service traffic within the tunnel - no matter what…

Cool! glad we're on the same page finally :)

Yeah, lots of cool stuff you can do with Linux. just wish that the other OSes were half as good, unfortunately most of them require kernel code to do what would be a simple shell script in linux

Re: Attackers can decloak routing-based VPNs

#214

Post by banister »

Borealid wrote: post #212
banister wrote: post #209

Earlier quoted context omitted.

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…

I used RFC1918 addresses as examples only. 10.7.7.7 shouldn't get dropped, because it's supposed to be routed over the VPN. The DHCP server shouldn't be able to cause VPN-bound traffic to be dropped, in my opinion. As I replied to one of your other comments, I don't think making the attack go from privacy-breach to denial-of-service is "preventing" the attack: you've only partially mitigated it. Full mitigation requi…

Ok. Well, the attack is so rare that i don't believe putting mitigations against the DoS is worth the effort. The mitigations are not that trivial (though it's arguable that just removing the route is kind of trivial, but still not worth it IMO). Better a DoS than a leak in any case :)

Re: Attackers can decloak routing-based VPNs

#215

Post by jkaplowitz »

sigmoid10 wrote: post #205
jkaplowitz wrote: post #196

Earlier quoted context omitted.

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?

Depends on what things you think are likely to be true in secret or judicially determined in the future without an intervening legislative change. My impression of the law in most Western countries is that the courts would overturn any requirement to compel a company to affirmatively lie to the public through explicit speech of some kind, even in the national security context. Orders compelling silence or non-removal of past statements are a very different constitutional and human rights balance than compelled false speech.

Re: Attackers can decloak routing-based VPNs

#217

Post by Suppafly »

sigmoid10 wrote: post #150
stavros wrote: post #148

Earlier quoted context omitted.

What are these problems, exactly?

As I said above, a simple court order can destroy any attempt at privacy. All (serious) VPN providers claim they don't store logs. But that does not mean that a court can't force them to do so. When combined with a gag order you can have someone collecting all your traffic without you even realizing it. And that's just the VPN provider, which usually doesn't own any datacenters. The datacenter providers can also rece…

>When combined with a gag order you can have someone collecting all your traffic without you even realizing it.

Are such gag orders common in the EU? I know they are fairly common in the US, but don't know enough about EU laws to know if that's an actual concern there or not.

Re: Attackers can decloak routing-based VPNs

#218

Post by DEADMINCE »

sigmoid10 wrote: post #145
froddd wrote: post #143

Earlier quoted context omitted.

Can you expand on that? Specifically the affiliation with Nordic countries? I’m a Nord VPN customer, I’d quite like to know more — may help inform any future decision on renewing or even staying with them.

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…

Mullvad at least doesn't seem to log :shrug_emoji:

Re: Attackers can decloak routing-based VPNs

#219

Post by DEADMINCE »

ang_cire wrote: post #190
jhugo wrote: post #176

Earlier quoted context omitted.

What, specifically, is the “secure browsing” that they offer and how does it improve on HTTP over modern TLS? Funnelling your traffic through another entity doesn’t magically increase security.

*Tunneling* it through one hides the nature of that traffic from intermediary systems that it traverses from you up to that VPN exit point. There is a lot of metadata in packets that can be viewed by any interim hop, like your ISP, workplace IT security, ARP-cache-poisoned coffeeshop router, etc.

> ARP-cache-poisoned coffeeshop router, etc.

Eh, that's not really a thing anymore.

Re: Attackers can decloak routing-based VPNs

#220

Post by DEADMINCE »

sigmoid10 wrote: post #150
stavros wrote: post #148

Earlier quoted context omitted.

What are these problems, exactly?

As I said above, a simple court order can destroy any attempt at privacy. All (serious) VPN providers claim they don't store logs. But that does not mean that a court can't force them to do so. When combined with a gag order you can have someone collecting all your traffic without you even realizing it. And that's just the VPN provider, which usually doesn't own any datacenters. The datacenter providers can also rece…

> All (serious) VPN providers claim they don't store logs. But that does not mean that a court can't force them to do so. When combined with a gag order you can have someone collecting all your traffic without you even realizing it. And that's just the VPN provider, which usually doesn't own any datacenters. The datacenter providers can also receive the orders to either monitor traffic or even install hardware to do so. If

None of this really matters unless you are doing something illegal enough that the government is interested in you and convinced a judge to get warrants.

That isn't 99% of people. 99% of people just want to try and stop being traced and their data being harvested with an easy solution that mostly works for that purpose.

Post reply on HN