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).
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 probably some other prior art. But that's a very well known one.
They also claim that it affects all VPN clients in the headline, yet so many such clients setup firewall rules to block traffic to/from the physical interface as they acknowledge in the write-up. Most of the VPNs that are claiming to hide your identity or where such cloaking is important tend to implement that. I'm sure plenty of setups don't have it enabled by default, but I think it would have been productive to document what percentage of leading personal/commercial and corporate VPN solutions have this enabled by default.
A good write-up and explanation for the lay person, but I think the headline over-sells it a little bit given the number of clients that would prevent most of the data leak with those firewall rules and not acknowledging the prior art in this area.
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.
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 comply, NordVPN (and all others who wanted to remain in the European market) were forced to admit [1] that they do comply with law enforcement orders. Today, all VPNs that you can legally buy are worthless in the aspects they advertise to you. You neither get extra security through encryption when browsing the web (https is already good enough for public wifi) nor actual privacy from your own government. There is exactly one use case for public commercial VPNs these days: If you want to easily access the internet from a different location to bypass geoblocking. But many big services like Netflix have started to simply block or otherwise limit access from traffic that comes from big VPN provider IP ranges, so even that use-case is becoming more worthless every year.
[1] https://www.pcmag.com/news/nordvpn-actually-we-do-comply-wit...
Even Mullvad?
You can answer the question yourself for any provider using this simple test: Can you legally buy access to it from inside the EU? If yes, they will suffer from the same problem as all other providers.
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 receive the orders to either monitor traffic or even install hardware to do so. If you want any hope of privacy, you steer clear of all big commercial "privacy" providers, because they are very high on every government agency's list. And you just need one component in the entire chain to be compromised.
You're spreading FUD, the Swedish government can't do shit to Mullvad but take their servers offline. Possibly if it was a matter of national security, at which point our recommendations are useless either way.
False. Like all member states, the Swedish government has officialy ceded jurisdiction and enforcement of certain laws to the EU. Only VPN providers who do not comply with such international court orders get shut down. Look at what happened to vpnlab: The police literally write on their seized domain that they have forcefully attained access to everything, because the provider would not give it away freely: https://vpnlab.net/
Consequently, you can assume that all other VPN providers who are still doing business in Europe are freely giving away their data to government agencies.
You presume that a) all governments are bad, b) law is controlled by these governments and c) we only have to hide from governments.
Neither are absolutely true.
I mostly trust my (western european) government to not fuck me over when I am abiding the laws. Which I mightn't always do. I mostly trust them to be proportional: e.g. not beat me up or throw me in prison for smoking a spliff or drinking in public.
A court order is handled by courts. Which, at least in most European countries, is independent. This is shifting in some countries, but that's a rather big deal. "Cut of from EU benefits" big. Regardless what police or governments want, they have to abide by laws. And courts decisions on allowing access to my internet usage.
While in many countries governments are truly life threatening to minorities, that's not the only privacy concern. I have much more to "fear" from my ISP selling out, my datacenter getting bought by a FAANG or just those FAANGs spying on my every move.
What I'm trying to say is: you are spreading FUD by inventing some absolutisms that are really a spectrum for most common VPN users.
Also: VPNs have always known to be detrimental to your security when browsing "really" secure: through TOR.
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 the news cycle, willful or otherwise. As well as an obliviousness to the logic of self-interest, bureaucratic expediency, State survival, profit motivation, corruption, party politics, and more. It takes an obliviousness to history.
I doubt that few people in law enforcement, public bureaucracies, or even in most elected offices would agree with the statement under discussion. In fact, the most best (or most just) system seems to be mostly built on fail-safes against being fucked over in this manner, even if all systems arguably eventually fall to corruption. Which underscores such government motivation.
If your take is that "in many countries governments are truly life threatening to minorities", then the rest of the Profession of Trust makes no logical sense for the population generally: if the bar is the threat to life. And while that is a sensible ceiling for a "do not trust" conclusion, I would argue that the bar doesn't need to be that high.
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 and places where government did absolutely f# over minorities here¹. But: hear me out: those are cases where the government, through democratic mandate, made (extremely) bad laws. And then had to abide by their own laws. Sometimes forced by the -independent- courts². Democracy works: "we, the people, voted for incompetent and blasé governors, racists even, who then turned out to be imcompetent and blasé. And in doing so f*d minorities". It's not the government, really, but the will of the people!
Do I trust the police force (the institude)? Not really. But I don't need to, because it is kept in check by a functioning democratic system and courts. Again, this is not the US. Nor Somalia or South Africa. Do I trust a police officer (a human)? Quite probably; in the Netherlands a majority isn't power-tripping nazi scum but rather people with a (imo weird) calling to help.
¹ e.g. a still ongoing case at https://en.wikipedia.org/wiki/Dutch_childcare_benefits_scand...
² e.g. https://en.wikipedia.org/wiki/Nitrogen_crisis_in_the_Netherl...*
Mullvad complies, but they go out of their way to keep very little information. If you don't have the information in the first place, you can't surrender it.
Beware that despite all marketing statements, VPN providers can easily be forced to store logs using court orders, even if they don't do it by default.
You can always shut down rather than do so - it's happened in the US.
This also happened with providers in Europe. So you can safely assume that any VPN provider who is still doing business in Europe is compromised in some way or another by the government.
"Compromised" is a wrong word to use, unless you consider any obedience to the law "compromise". VPN providers who are still doing business in EU (not Europe) do obey court orders - that would be more correct wording. Any non-compliance is a one-time occurence: either you decide to cease operations or you are forced to cease operations by LEA, as in vpnlab.net example.
VPN providers can easily be forced to store logs using court orders
It's not grave if the provider is allowed to notify the user that logs are being collected from now on.
Is there a country where gag orders are unconstitutional or something of that sort?
That still has value, it's much harder to do drag-net style surveillance if you need court orders to collect new information and can't scoop up old information.
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
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.
*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.
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 but Hacker News - I assume some bad site database misunderstands the name of this site.
As for hiding from governments, 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. So far, they can sometimes force silence, and can sometimes force a previously published canary notice not to be removed, but they haven’t yet had any right confirmed to uphold a compelled lie. So any Western provider that continues to publish suitably broadly worded canary notices on a verifiably still-updated basis (e.g. securely OpenPGP-signed together with a bit of new daily news headlines) is either telling the truth or is lying without being legally forced to do so.
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?
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.
Yeah. But Mullvad VPN, based in Sweden, is an actual good one.
Migadu for email hosting is amazing as well, also Sweden I beleive.
Migadu is Swiss
Why do people keep mistaking Sweden and Switzerland?
People confuse Switzerland and Swaziland and those two aren't even on the same continent :)
Something something Austria
My mistake, I did know they were one of the two. I should have double checked. In general I know the difference between the two just forgot which Migadu was based on.
Or more generally, marketing budget and trustworthiness tend to be inversely proportional.
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.
That’s certainly a take.
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.
A.k.a merely the no. 1 selling point for most VPN offerings.
I thought the selling point was protection against hackers. No, was it your ISP seeing your (basically always HTTPS encrypted) traffic? Or facebook/google harvesting your data? Or russian hackers? Or watching netflix from other countries? Or data-harvesters watching your traffic? Or if you just really like downloading linux ISOs? I also think I heard something about snowden and NSA tracking in a few ads. Something something cheaper airplane tickets?
Either way, it's all scary and for the low fee of 5$ per month (sign up for 3 years and you get 3 months free with my code!) you don't have to worry your pretty little head about it anymore. Don't worry about that our company is registered in Bermuda and is just 3 months old.
There are super shady VPN providers but that doesn’t mean local network risks can be ignored. For example, how frequently do you hear about compromised networks of routers and access points? Attackers could be using those for far more stealthy means.
Also, remember when Verizon decided to helpfully inject cross-domain tracking cookies into their customers’ traffic? Do you really want to gamble that some MBA wouldn’t start to think about ways to monetize activity collection from VPN users? Some provider won’t sell schools, coffee shops, etc. a service which will block the “wrong” traffic and that just quietly expands to cover, say, women looking for family planning advice or college students in Florida looking for trans support?
Coffee shop wi-fi? A.k.a merely the no. 1 selling point for most VPN offerings.
Isn't the #1 selling point of general consumer's (not Enterprise) VPNs to stream video and audio from another country?
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...
"the DCHP server" implies it is somehow a special device on your network, which is a flawed assumption. DHCP works on an broadcast protocol and your device will accept the first offer. The fact that the most common residential configuration is for your DHCP to be hosted on your router and thus likely the first to respond is inconsequential to the fact that any hostile device on your network could use this exploit.
not implying anything in that regard, I can imagine a clever attack which involves a local malicious dhcp implementation
That's not at all guaranteed. The residential gateway most likely contains a hardware switch and a CPU, which also does the routing. The CPU is attached to the switch like any other device, though probably with less physical-layer bits, and some of them aren't all that fast.
That's one of the commonly advertised reasons to use VPNs: protection in untrusted WiFi networks.
Or become the DHCP server on whatever third party wifi you're connected to.
what are you insinuating? I still need to be spelt out. Are you saying that ISP's gateway device have any incentives to decloak my vpn traffic? Sounds like a huge liability for no reason? Surely they will be out of business it sounds so bad?
Surely one of the big use-cases for a VPN is that the network you're connected to is untrusted?
You mean like a pwned home router?
The risk is outside the home: Using a VPN at the coffee shop, hotel, office, etc.
VPN can be trivially defeated any number of ways. I was shocked when I first learned this ten fifteen years ago through a site that showed my internet provider and location despite being on a VPN. I forgot the name of the site.
A huge problem that doesn't even require defeating is, most OSs and VPN clients, if the connection is shaky, just reverts to the default connection. Even a single packet is enough for your VPN to be worth nothing. In Ubuntu, it required setting up elaborate firewall rules and activate them after you get a stable VPN connection to avoid this. (and even that doesn't protect you from DNS and other stuff being able to track you) (let alone cookies which reveal who you are etc etc)
Are there any router/cheap "bridge" devices that can sit between your router and the internet and force outbound communication to go through the VPN, as if it were your ISP?
Just use iptables and only allow the vpn traffic. Or do the same with a small Linux box.
apparently lots of folks who do this still have problems that a lot of software that promises to do this actually only does it for ipv4, so ipv6 traffic still exposes them, lol
It's not unusual to get the recommendation to deactivate ipv6, which isn't hard (on Linux at least).
There have been a bunch of these, although if you’re really that concerned, you might as well go all in with tor
A modern version of this: https://github.com/grugq/portal
You do not want to mix your non-anonymous and anonymous traffic over the same Tor connection, especially if you don't control the bridge (first hop) to which you're connecting.
Pretty much any of the GL.iNet devices should be able to do that.
apparently lots of folks use Raspberry Pi's for this, which has added benefit of PiHole filtering out of ads etc
no personal experience but sounds nifty, maybe there are other options too
On Linux this is easy with a network namespace and nftables.
Can just be location services - it uses known bluetooth devices and known wifi networks to deduce your location
can be but that wasn't what i was experiencing
is there reading on this matter?
What leaks your location might just be a DNS request. Depends on the configuration.
The site can include a completely unique DNS name as a part of a page. Something like "a5afbdeffe.attacker.com".
What is a trivial way to reveal a VPN-using website visitor’s actual IP these days? Browsers have improved a lot over the last ten years.
A huge problem that doesn't even require defeating is, most OSs and VPN clients, if the connection is shaky, just reverts to the default connection.
This is mostly a function of the VPN client, not the OS. Some clients will reinstate default routes pretty quickly when they lose connectivity, others are pretty sticky.
At least Android even offers a specific “always-on VPN” option to prevent leaks like that.
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 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 from Australia with a VPN to an Australian server and lastly the standard home Internet wifi.
It's super easy to do if you have a couple of old wifi routers and even cheap home ones seem to have some VPN support these days. A big advantage, aside from centralizing the VPN setup so you don't screw it up is that it's trivial to connect any device to the VPN. Just join the relevant wifi address! Boom I'm now in a VPN to Australia from any device without messing around setting up that device specifically because I connected to the 'Australia' wifi.
I do this with multiple old routers but I actually think there's probably a market for a single home router that vpns to multiple locations in the world with a different wifi network for each of those just for the sake of easily having your TV/Roku/iPad appearing to be from somewhere else trivially.
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 want my family to be able to watch Netflix, browse the web without running a CAPTCHAthon, etc.
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
If you could list some hardware and software, it would save us the effort ...
I currently carry a GL-Inet MT-3000 with me.
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.
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.
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.
So for this attack does the attacker need to control your internet router? Or does it only need to control ISP infrastructure?
Pretty sure the attacker has to control your DHCP server, which in ex. a home environment is usually the router.
No, the attacker just has to be on the network. When on the network the attacker can deploy various techniques to become the DHCP server. Since it's (relatively) easy to become a DHCP server on a network, it's considered a big deal when the DHCP server can trick you into doing something like in this case decloaking your VPN traffic.
What is the fix for this vulnerability? Is it the router that needs to get a software update, the VPN client, the OS, or some/all of the above?
The OS needs an extra feature, and then clients need to make use of that feature. There's other workarounds listed in the "Mitigations" section of the post. But the problem is basically that everything is working as intended, for example if you disable the "Option 121" feature then under certain circumstances you might not have internet connection. Apparently Android devices don't support Option 121 at all, and it makes them unaffected by this vulnerability, but also causes to sometimes not be able to connect to networks.
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:
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!
This is mostly correct, in our POC video we showcase a lab where we go from being an adjacent host on the network to being the DHCP server.
We did this by DHCP starving the true DHCP server and hoarding all the leases. Then we serve our own and do not have to compete with the true DHCP.
There’s network protections against this such as guest network isolation or switches with DHCP snooping protections. However, those are usually on enterprises and relying on those being in place kind of removes the point of “securing an untrusted network” like many VPN providers claim.
You should play with IPv6, you can bypass IPv6 RA Guard on some switches (including Cisco) https://blog.champtar.fr/VLAN0_LLC_SNAP/, allowing attacks in 'trusted' networks
Is there a tl;dr so we don't have to wade through swathes of AI generated text explaining what a network is?
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 correct if I've missed something; this was my interpretation of https://arstechnica.com/security/2024/05/novel-attack-agains... )
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.
can cause traffic to go over those routes instead of the VPN
AIUI the vulnerability is more about forcing traffic via a specific interface than it is about the setting the route. The host's routing table contains at least these fields:
A) destination (IP or subnet)
B) gateway (aka route, aka next hop)
C) interface
The article says that when the route is set using DHCP Option 21, the interface field is set to the interface on which the DHCP response was received. So, if I've understood the article correctly, even if the route/gateway address is correct and not malicious, the host will send out packets for that destination via the regular (wifi or ethernet) interface, instead of the VPN interface.
Imagine a coffee shop scenario: a malicious DHCP server responds to your DHCP request. It includes Option 121, making certain traffic go to the 10.0.0.1 (the coffee shop router address). Now, even though that gateway isn't malicious, the fact that the traffic is now going over the wifi interface instead of VPN, means someone can snoop on it.
You probably followed the advice to read from the 121 section already but if you’re sharing this others it might be helpful to link our website that serves as a TLDR + FAQ. https://tunnelvisionbug.com/
There’s also a general public advisory there that’s supposed to be for anyone non-technical but who wants to understand the issue. All this content was also written by hand over 8ish months too, no AI was used
This is a great explanation of basic networking mechanisms that most people know almost nothing about. Don’t listen to the haters.
I feel that I’m in a high percentile for networking knowledge, but I didn’t know about option 121!
Scroll down to "What is DHCP option 121?" and start reading there.
I interviewed some smart people about their research in story published today:
https://krebsonsecurity.com/2024/05/why-your-vpn-may-not-be-...
I haven't seen anywhere that said there can be a "fix" for this outside of not allowing "option 121" to be in use at all the DHCP server. Is there no way to mitigate this in the VPN client, or is it simply too fundamental to the way the networks work that there is and never can be a "fix" on the VPN client? I wouldn't expect a malware laden network's "admin" to ever fix this or even hear about it.
The only fix we’ve observed in the wild was limited to Linux hosts. WireGuard has documentation about how to implement that properly using network namespaces which can be used to isolate network stacks. https://www.wireguard.com/netns/ however, the VPN provider must implement it this way. In our demo we use WireGuard that is implemented without namespaces.
The other operating systems do not support that feature. The mitigations we saw were firewall based rules, which create a side-channel that be used to leak the destination of traffic.
The "side channel" is silly. You assume someone is hitting the same endpoint over and over and over and with significantly high traffic that it rises above the noise.
Did u even do any of the math required to demonstrate it can actually work in a reasonable time frame? Did u clearly list the very onerous assumptions required to pull it off?
This whole thing is silly.
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.
There’s also mitigation bypasses that are likely to be discovered, we have a few we’re working on.
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.
Side channels are a huge danger. An example is cryptographic functions have been cracked because of timing differences based on the key or data being encrypted. This is why cryptographic ciphers are implemented in constant time code (i.e. code that always runs in the same amount of time regardless of its input).
I'm talking about the specific side channel attack mentioned in their report. Not side channels generally ;)
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
Most decent VPNs are already protected against it. It's a simple firewall rule known as leak protection or a kill switch which blocks all off-VPN traffic including on option 121 routes.
This article is 99% FUD IMO.
always the breathless sensationalized vulnerability headlines...
it's interesting, but of limited usefulness - the device has to accept responses from a dhcp server. if an attacker controls a dhcp server, he's either on the network already or has already had to do a lot worse than installing a couple static routes to get there.
it's not nothing - a compromised home gateway could use this technique to sneak into a corporate VPN via a users' laptop, but if you have a compromised home gateway, you have a lot of other problems that could lead to the same result.
I think a public wifi network effectively being able to disable someone's VPN is pretty bad.
if you are on a public wifi, particularly if you can control an evil dhcp server, there are sooo many other ways to attack someone's pc client and network. this is just another. it doesn't even seem that unexpected.
But this heavily undermines one major selling point VPN providers use: safety on public wifi and other untrusted networks.
There are lots of ways to disable vpn : basic firewall on the router, if you have access ARP poisoning if you do not.
Yes, but this disables a user's VPN without alerting the user.
Firewalling off their VPN service would cause a visible connection failure.
because Android does not implement support for DHCP option 121, it was uniquely unaffected
Curious if that was a deliberate decision because Google knew about this or completely coincidental..
There are so many DHCP options, for something like Android it makes sense to start with only supporting the bare minimum and then only enable support for an additional option if there is a requirement raised for it. Given this DHCP option isn’t commonly used, such a strategy would likely result in it not being supported, irrespective of any security concerns with it.
Android doesn't even implement the new DHCP version defined first 21 years ago:
https://www.rfc-editor.org/rfc/rfc3315
So not really a surprise.
Looking at https://issuetracker.google.com/issues/117544989 seems like Google mostly just ignored this feature request without giving any reason. I wonder the same. Perhaps someone who works at Google with access to the internal Buganizer will know more.
But if you want me to speculate, my speculation is that the team behind Android networking is highly pro-IPv6. They don't really care about missing niche features in IPv4. Even for IPv6 they have a specific vision for how IPv6 should be used, resulting in deliberate non-support of features like stateful DHCPv6.
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...
That article is referenced in the Appendix:
However, neither technique described in the August 2023 paper leveraged DHCP option 121 to push routes. Pushing routes through DHCP has a significantly higher impact from the same attacker vantage point (the ability to hand out IP leases for a non-RFC1918 range or spoofing DNS replies).Ah good find, I totally missed the appendix when reading on mobile.
the "attack" is widely known and is used as a config option for the openvpn client (redirect-gateway def1)
You can also mitigate this by placing the VPN interface in a VRF on Linux. I.e. systemd-networkd have support for doing that out of the box. One thing to watch out or is that when enabling VRF, the ip rule entry for l3mdev is listed as 1000 but rule for local traffic is listed as 0, the local rule should be moved to 1000+.
Is there a way to run an app in a specific VRF nowadays?
Just like with netns using ip: `ip vrf exec <vrf> <command>`. It’s been available for a while now
Look here: https://jerryxiao.cc/archives/1004
Yes, it's eBPF but the solution is quite neat to be honest. And you can integrate it into systemd units.
This is a perfect example of the CVE mining.
There is nothing novel in the attack nor it's a security problem. DHCP environment must be trusted. We do have IP Source Guard and DHCP Snooping for decades to avoid scenarios from that link ( and many other).
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.
I saw a github project that tries to make wireguard+netns more easy to setup: https://github.com/kalken/eznetns
What would be the opposite approach, to make sure all traffic goes through VPN, and only VPN, even if user didn't start the VPN connection (default to no connectivity)? Is there better approach then just disabling all other network interfaces?
AFAIK Wireguard will always listen in the default namespace, thus you need to isolate everything else. A fun way of doing it though is to do an ip rule that uses the VRF table, and matches on the user id. That way all traffic from certain users will always end up in the same routing table. You can go further and match on everything except the Wireguard endpoint. With iptables you can MARK the traffic you want to be differently and then catch that traffic with ip rule.
tldr DHCP can add routes, so it can add routes for the internal network of a VPN. It’s not obvious to me why this works, because VPNs set metric 1 on their routes, that’s why traffic goes into them regardless of what IP the surrounding network used. DHCP option 121 has no metric field, so it should get a high default metric and shouldn’t have any impact on a VPN with specific routes. If you only “set the default gateway” (0.0.0.0/0 route), then this probably works. But that also seems particularly amateurish, even for enterprise VPN admins.
because unless you have matching routes, most specific wins
More specific routes are higher priority than less specific ones, so 0.0.0.0/1 is chosen over one for 0.0.0.0/0 even with metric 1.
Is disabling DHCP a mitigation?
Well written, I appreciated the background. Far more enjoyable to read than a good deal of the incoherent articles posted on here.
linux not affected if network namespaces are used to separate vpn and physical interfaces.
I recall 20 years ago: statistical attack on TOR network, namely with enough man-in-the-middle agents on TOR nodes, you actually "know"...
Good thing I don't use DHCP.
When connected to a hostile network.
We noted that because Android does not implement support for DHCP option 121, it was uniquely unaffected.
Phew, that was my biggest concern. This would've been pretty difficult to work around (as are Android's well-known VPN bypasses through system apps, but those need local execution privileges).
Cisco ASAs don't seem to support option 121. Are they immune to this one?
We want to stress that there are ways an attacker who is on the same network as a targeted user might be able to become their DHCP server
Does this mean your ISP could also perform this attack on you?
IE: If there is a warrant for a wiretap, or otherwise your ISP is malicious?
Same like on device vpns are pretty sketchy.
An interesting (and portable) alternative to network namespaces is to bypass kernel networking entirely and use a userspace network stack.
I've got an example of doing just that with my project Noisy Sockets, https://github.com/noisysockets/noisysockets/blob/main/examp...
Improvement suggestion: This article could do with an executive summary for professionals.
The "attack" is just a clever use of DHCP option 121. It's a valid attack against a badly broken client configuration. Just replacing the default route (or overwriting it with two /1 routes) and adding a host route to the VPN endpoint is not secure. To properly isolate the encapsulated traffic from the underlaying network you have to use proper policy based routing (e.g. Linux network namespaces, FreeBSD vnet, OpenBSD rdomains). Attempting to cobble together something with packet filters and a userspace "kill switch" is broken by design and just shows how little the common VPN hosters understand or care about their supposed core competency. Good old enumerating badness strikes again.
Not a rethoric question:
Has anyone here compared western VPN services to Russian and Chinese available VPN?
I know you are trading one spy for another, but those two countries are, supposedly, not cooperating with the west. You are also raising a tall flag whem connecting to one of those two countries via VPN.
Appart from that, would it be more "Private" for the regular small time evildoer?
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.
What else is new?
I'm more worried about people using VPN services that are IP4 only while having IP6 enabled in the system.
That can go terribly wrong...
One of the authors here, the intention was to provide a primer of the topics since we figured this would draw people from a nontechnical background too.
That and half the information on the internet about VPNs is from VPN providers and is incorrect or not technical enough to describe how they _actually_ work.
We had a sentence in the intro that was supposed to be a hyperlink to the “hey if you know this stuff you should skip to the POC section”. I’ll make sure that gets updated/more obvious.
I looked at this in detail. This exploit is a nothing-burger for most decent VPNs.
A simple "leak protection" (aka Killswitch) firewall rule completely negates this attack.
All decent VPNs implement such a rule by default.
Dealing with undesirable routes (whether pre existing or pushed by a DHCP server) is nothing new or in the slightest bit hard to defend against.
If a VPN does not implement such a firewall rule already then it's likely already leaking so all this exploit demonstrates is that "A VPN without leak protection, leaks".
(I won't even mention the "side channel" attack as it's completely ridiculous)
I liked your write-up and option 121 is a little known option, so it's good to know about. But let's not pretend this thing is bigger than it is.
FTA: Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.
They don't know what they're talking about. Kill switches are not "tripped" there is no "control channel".
A kill switch is just a firewall rule that is ALWAYS engaged and all it does is blocks off-VPN traffic.
It 100% will defend against this exploit.
Most practical VPN services don't actually implement it this way, it's a somewhat difficult and rather OS-specific problem depending on the firewall services offered by the OS. On some popular OS like mobile ones it's just not possible at all.
So just to grab an example, NordVPN's implementation does indeed work as the article presents: it monitors the VPN and disables network access for applications if the VPN connection drops. This is indeed vulnerable to any number of potential problems, and depending on the OS and user savvy you can set up better protection using e.g. the iptables owner module. It's very non-portable though, sometimes even between Linux distributions, and hard to support at scale. Actually I'd say a true "no access except through the VPN" rule is easiest to implement on Windows, but NordVPN doesn't seem to do it there either, I'm not sure why.
To be fair, it's right in the name: a kill switch is a switch that kills things. It isn't proper network policy like per-process routing tables that are, unfortunately, difficult to implement for consumer machines.
Mobile is an exception (but they already state android is immune), let's stick to desktop for the sake of discussion, the 3 major desktop platforms: mac, win, linux :)
On mac - just implement a block everything rule with pf and then just allow traffic on the tunnel and whitelist the VPN endpoint. Boom, a kill switch that defends against this exploit. And there's no racey nordvpn-style "control channel" (if nord really works like this i have an even lower opinion of them than i do currently).
On linux - iptables (for example) - just implement a general DROP policy then override with a specific ALLOW on the tunnel interface.
On Windows - Use WFP to implement a block everything rule, then provide a higher priority rule to allow on the tunnel interface.
All three of these techniques are the recommended way to implement a kill switch and it's used heavily in the VPN industry by anyone sensible. It completely defends against this TunnelVision exploit too.
The way that you suggest kill switch is implemented (reactive and monitoring the connection?) is very fragile, racey and prone to leak, i absolutely would not trust it and it shouldn't even be called a kill switch. It's an embarrassment. :)
You wrote three different ways to end up with all traffic dropped and a broken VPN connection.
Traffic sent to the VPN interface gets encapsulated by the VPN client software and then routed to the Internet. If your firewall rule is dropping all traffic not destined for the VPN interface, it will drop the encapsulated traffic.
You need two (sets of) rules: one allowing traffic on the VPN interface and one allowing traffic which is already cloaked by the VPN software (or not cloaked, but used to establish/maintain the tunnel itself). That second category is a bit complicated, because you need to be able to route to the VPN server regardless of which network you're connected to - and the DHCP server tells you how to do that.
Yes. I just provided simplified firewall rules in my answer. You also need to whitelist either the VPN endpoint itself (and add a route to that endpoint) or you need to whitelist the process (such as wireguard or openvpn) that hits that endpoint.
Not sure how a DHCP server is relevant in the slightest here except for the initial host network config of course. But the host network should already be configured before the VPN comes up.
Source: i've implemented this dozens of times (and you probably have too, it sounds like) so let's not quibble over the details ;)
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 table - let's call it "host routing" - and everything else on the system is using a second routing table - let's call that "VPN routing".
The DHCP server inserts rules into the host routing table, and the only software using those rules is the VPN client for its management and tunnel traffic.
Otherwise, what if the network to which you connect says "the next hop for all internet traffic is 10.10.10.10"? You need to respect that rule when sending traffic to your VPN server, and ignore it for applications whose traffic will be tunneled.
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. These also get added to your routing table
* Step three - You connect your VPN. The VPN will bring up a firewall. It will also bring up `128/1` and `0/1` routes that point at the VPN tunnel. The VPN tunnel now takes over the default route. This firewall will block all traffic that's not on the tun device (the VPN interface). Further, it will whitelist the VPN endpoint IP and create a route for it (it can do this since it already received the default gateway from the DHCP server)
* Step four - Your host starts sending traffic - either this traffic will go through the VPN tunnel (the default route) 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).
* Step five - All traffic that would go down the malicious option 121 routes are BLOCKED by the firewall rule. Hence nullifying the TunnelVision exploit.
That's all. Done. Where's the complexity in that? As i said before i've done this dozens of times. I'm talking from experience. I know this works.
Further you say:
You are aware we're talking about consumer VPNs right? The majority of users are on Windows and Mac. Neither of those OSes support multiple routing tables. Only Linux supports multiple routing tables.
You're also just plain wrong - as i demonstrated above - you CAN just configure a firewall rule and it WILL just work properly. Again, i'm talking from experience.
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?
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?
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 the DHCP server attempts to do.
I think you might be saying to add rules like `iptables -A OUTPUT -d <vpnserver>/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-service attack instead of a loss-of-confidentiality one.
But there's no technical need to drop the maliciously-routed traffic, is there?
The only problem with this persons comments is saying "you're wrong" "you're confused" so much.
The actual content is 100%.
Get over the "you're wrong" tone and ingest the tech message.
It's really a misnomer to call the firewall a kill switch since it isn't reacting, it's already in effect, already blocking the bad traffic before the bad traffic happens. No switch is thrown.
Any vpns that DO work that way are silly and should not be used. If this is most popular commercial vpns today, oh well so be it.
The articles going around saying "affects all vpns and nothing can stop it" are also just silly and wrong. But it is probably true that most convenient vpns are currently leaking.
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 ignore the route).
That has already been explained a couple times over.
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
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 tunnel stays up because the tunnel connection is over the physical interface. The VPN endpoint has a physical route from the host to the VPN endpoint which is whitelisted in the firewall. So new physical routes (which option 121 would push) don't impact anything as VPN endpoint route is physical anyway. Also it's impossible for the DHCP server to push a route MORE specific than the endpoint route (which is a /32) that already exists, so it can't be overridden (and it wouldn't matter anyway since it would still be a physical route, which is what is desired here).
Can you stop just talking and actually TRY it? it's all theoretical for you since you're not actually testing it and your theory is completely wrong.
I am actually testing it, so i know I am correct.
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 is blocked
- After the renew, traffic with a destination IP matching 10.0.0.0/8 not routed via 10.9.9.9 is blocked
What should the firewall rule look like to let the VPN connection stay up both before and after the new rule, while also ensuring that traffic to 10.7.7.7 goes via the VPN and not via 10.9.9.9 or 10.8.8.8?
EDIT: you keep saying "I'm wrong" but I'm just asking how this firewall rule can be structured to do what you say. It occurs to me that perhaps you're saying you can make traffic for 10.7.7.7 get blocked. But in the above, and before, what I'm asking for is how to make traffic for 10.7.7.7 continue to get sent over the VPN after the new rule addition, just like it was before - in other words, no dropped packets.
I'm not saying how it should be implemented, I'm saying how it is implemented by a number of popular VPN services. Take up the argument with them. There are VPN providers that do it right on at least some platforms, but unfortunately the way most document it it's very hard to tell without experimenting with the client to verify.
As far as I know, use of the term "kill switch" closely correlates with an untrustworthy implementation. Consider the case of Mullvad who handle this a lot better and also decline to call it a "kill switch" for that reason. And that's not to say that Mullvad is perfect, easy to find forum threads by people who had traffic leakage for various reasons. I wouldn't trust anything you didn't set up yourself.
Let's be honest, there're 2 OSs on desktop that matter to VPN providers that provide "all-in-one app" - Windows and macOS. Both have easy to configure from your application.
On linux, well, you have to choose:
- use iptables style rules regardless of the backend
or
- use nftables style rules regardless of the backend.
So it's 3 firewalls that you have to think about.
On mobile, well, on mobile you're mostly at the mercy of the platform owner and generally can't do much. Hence, why connecting phone to "SoftAP/ether_g + VPN" device is better than a direct connection.
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.
I can't check your fascinating answers but a friend is, and is beginning to concur, so I'll take theirs and your advice as closer to correct. Thank you. Next question, where have you been for so long and only back now why giving such juicy answers?
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.
Let me explain how a _very_ basic setup works: you set up a firewall rules allowing only connection to VPN on all interfaces except your VPN interface.
If you're running a torrent box, then you can do whatever your OS equivalent of "this process uses this routing table". My seed box was using interfaces that were set up in dom0 and guests didn't even know about a ways to reach outside without a VPN connection being established by the host.
The point is - "such" attacks have no legs against anything beyond "OpenVPN: Getting Started" kind of server.
Looking at mozilla vpn, I can’t tell if there is such a setting, unless it’s just enabled by default. Can anyone clarify?
https://support.mozilla.org/en-US/kb/mozilla-vpn-kill-switch
The PoC section doesn't explain the issue. I think a one-line TL;DR similar to the summary above would be best, e.g. "A malicious DHCP server can use DHCP Option 121 to set routing rules, which can override the routing rule used by VPNs and cause traffic to be routed outside the VPN"
(I like it that you provide the background for people who need it, but also found the actually relevant information extremely annoying to find.)
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 to figure it out.
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)
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!
Skip down to the DHCP section?
What I read does a great job of explaining the technology; I know it pretty well but it's great to have an updated, clear, concise, well-organized, integrated explanation all in one place. I can't imagine how long that took to make it that clear!
(Everything posted here gets similar complaints about the writing, headline, too short, too long, too hot, too cold, etc. Goldilocks is never pleased here. Welcome to HN! :)
Good call. For a general IT audience you are speaking to, context building really helps refresh the scene before dropping the exploit. Well communicated.
Have you identified actual VPN vendors that are affected by this? I won't disclose which ones I use, but I would love to know if they have been affected.
Great write up by the way. Even some technical people might not know about this, not all technical people are network experts after all.
...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?
Sure, but he still needs access to the L2 network, the virtual interface has to be connected/bridged to something.
Unless if you're thinking about a virtual interface and dhcp server directly on the victims pc (bridged to the interface with the dhcp client), but if the attacker can do that, he can also just capture the data directly.