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

181–190 of 238 posts

Re: Attackers can decloak routing-based VPNs

#181

Post by tristor »

varenc wrote: post #130
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 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.

Re: Attackers can decloak routing-based VPNs

#182

Post by tristor »

Aloisius wrote: post #61
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.

I'd imagine most travel routers are still vulnerable to this.

How? Serious question.

This uses DHCP Options to set routes, which is an optional behavior on the client (but on by default), I have it disabled. I also don’t allow setting DNS via DHCP or anything but giving me an IP and gateway. Clients behind the device are unimpacted, the device itself is configured in a way which eliminates this vulnerability.

Re: Attackers can decloak routing-based VPNs

#185

Post by IggleSniggle »

aeonik wrote: post #177
timbre1234 wrote: post #175

Earlier quoted context omitted.

Or they could have maybe lead with that sentence and THEN given the explanation. Too many tech people have that "I want to slowly lead you to the point like Sherlock Holmes mystery" style of writing, and it is such a time-waste. Arthur Conan Doyle was paid by the word, you aren't. Please, everyone, back to middle school: State a Thesis in your first sentence and THEN expand on it, don't force me to spend pages trying…

It's not just tech people, but any field with a high enough complexity. The "abstract" of a journal article is supposed to contain all the key points of a science experiment including the results , but it's too rare that they do. I think some folks are just hitting their limits, and needed more time to digest/ review their publication. Other folks are doing it I obfuscate or pad their work, for whatever reason.

When you're deep enough in a thing it can be hard to know what counts as "high level summary." For example, "attackers can decloak routing-based VPNs" might seem like a good high level summary. "Attackers can decloak routing-based VPNs using DHCP rules that give priority to an attacker over other lower priority routes" might seem like it's just in the weeds enough to be misleading, or to result in a bunch of people now believing they are educated on the subject when they really are not.

Picking the right level to communicate such that you avoid clickbait journalists spreading a lie of omission/ hysteria is an art. Personally, I think we should be grateful for all the effort put into clearly communicating all the most relevant nuances; we can generalize that any high complexity field is doing its readers a service when it approaches communication this way. I'd rather the "result" be communicated at too high a level than too close to the middle (giving the illusion of understanding the nuance)

Re: Attackers can decloak routing-based VPNs

#186

Post by froddd »

jhugo wrote: post #176
froddd wrote: post #165

Earlier quoted context omitted.

So, should they be requested to do so by a formally issued court order, they would comply and start logging a user’s activity, but do not do so by default. Calling them worthless at providing secure browsing seems far-fetched; calling them a scam is fully disingenuous.

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.

Being able to cover/scramble your actual or virtual location can provide security in some contexts

Re: Attackers can decloak routing-based VPNs

#187

Post by Shared404 »

froddd wrote: post #186
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.

Being able to cover/scramble your actual or virtual location can provide security in some contexts

It also would prevent your ISP or local attackers from seeing the domains you are reaching out to, which is still visible over https.

It's all tradeoffs.

Re: Attackers can decloak routing-based VPNs

#188

Post by lsllc »

champtar wrote: post #115
lsllc wrote: post #54

Earlier quoted context omitted.

Many networking switches/systems (e.g. UniFi from Ubiquiti) let you enable DHCP Snooping which drops Layer 2 traffic from rogue DHCP servers to prevent this: https://en.wikipedia.org/wiki/DHCP_snooping

I invite you to not trust blindly L2 security features, anything that use denylist approach can miss some corner cases, have a good read :) https://blog.champtar.fr/VLAN0_LLC_SNAP/

Interesting write up! I typically use multiple-WLANs as well as guest-isolation on the "guest" network which further reduces the attack surface. All of the network infra also runs on a separate management VLAN and (by default) switch ports are on the guest network so if someone randomly plugs in to a ethernet jack, they're not getting on the MGMT lan. Maybe not perfect, but certainly better than your average Comcast/Verizon/Orange/SFR setup!

Re: Attackers can decloak routing-based VPNs

#189

Post by jofla_net »

sixothree wrote: post #13
yjftsjthsd-h wrote: post #5

Earlier quoted context omitted.

An attacker who controls the DHCP server can give your device more specific routes and this apparently can cause traffic to go over those routes instead of the VPN. So if your VPN says that it's taking traffic for 0.0.0.0/0, and the DHCP server says 0.0.0.0/1 and 1.0.0.0/1 route over 10.1.1.1, then all your traffic gets sent over 10.1.1.1 because those routes are more specific so they "win". (Please feel free to corr…

Will static IP and gateway alleviate this threat? I guess at what level too.

I tend to think yes. If the initial attack as i understand it, is from a dhcp server handing out poisoned options, then if a client is set-up as static from the get-go it'll never request a lease to begin with and, well, there you have it.

Re: Attackers can decloak routing-based VPNs

#190

Post by ang_cire »

jhugo wrote: post #176
froddd wrote: post #165

Earlier quoted context omitted.

So, should they be requested to do so by a formally issued court order, they would comply and start logging a user’s activity, but do not do so by default. Calling them worthless at providing secure browsing seems far-fetched; calling them a scam is fully disingenuous.

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.

Post reply on HN