- cross-posted to:
- privacy@lemmy.ml
- cross-posted to:
- privacy@lemmy.ml
You must log in or # to comment.
I use option 121 as part of my work, though I am not an expert on DHCP. This attack does make sense to me and it would be hard to work around given the legitimate uses for that option.
What are the legitimate uses of option 121?
Adding routes for other thing on the network the clients can reach directly and remove some load from the router. For example, reaching another office location through a tunnel, you can add a route to 10.2.0.0/16 via 10.1.0.4 and the clients will direct the traffic directly at the appropriate gateway.
Arguably one should design the network such that this is not necessary but it’s useful.
To be fair, any proper VPN setup that only relies on the routing table like this is flawed to begin with.
If the VPN program dies or the network interface disappears, the routes are removed aswell, allowing traffic to leave the machine without the VPN.
So it is already a good practice to block traffic where it shouldnt go (or even better, only allowing it where it should).
As a networking engineer using a VPN service where you don’t have any information on the other end of the tunnel or worse install software which can essentially packet mirror your traffic to any location is the worst possible idea and I can’t believe they convinced so many people to do it.
The trust in the unknown systems of the VPN provider may still be better than the known practices of your local ISP/government though. You shouldn’t necessarily rely on it too heavily but it’s good to have the option.
If someone uses vpns for anything other than region locked content then that’s not very smart
I assume this is definitely the case for free VPNs, if any of those still exist. There might be some willing to donate bandwidth and compute resources for the good of others, but I’m sure there’s more that pretend to do that but actually just sell the data or maybe just spy.
Tbh I wouldn’t be surprised if this is also the case for TOR nodes. I wonder how many entry and exit points are run by the NSA or some other government entity. Or are just monitored. If you can monitor the entry and exit points, you can determine both the source and destination, and just match them together using the middle node address.
Same thing with proxies.
Paid VPNs could go either way. On the one hand, they could make more money if they are willing to sell out their users’ privacy. On the other hand, that risks the entire thing falling apart if word gets out that it’s not private, since that’s the whole point of VPNs. I’m sure there’s some good ones out there but I’m also sure that there’s bad ones and wouldn’t be surprised if some of the ones considered good are actually bad.
Maybe ones that run in Europe would be safer bets. Their business is at least able to run there with the privacy laws. Maybe they are skirting them and haven’t been caught yet, maybe their data sales from other regions are profitable enough to support European operations without data sales, but if they are going for max greed and min risk, maybe they wouldn’t operate there. Or maybe they just run things differently in the different regions to maximize global profits.
Encrypted VPN tunnels are ubiquitous in many industries for remote connection to private clouds. They are used by virtually every high functioning company in the world, and getting more common for mid and lower tier companies as well.
I am thinking more in the vein of piracy or hacking not some business stuffs
Are you saying it’s smarter to not use a VPN for piracy?
Maybe you can explain what you actually mean then, because I don’t understand your point.
I would say those dollar-store VPN products people use for geo-spoofing is the worst security risk when it comes to VPNs. You are sending your data through some other company that you have no control or insight into. You have no idea what network security they employ, or whether they are willing or obligated to release your data to other parties.
There’s no real way to know if VPNs intended for the public are run the same as those intended for enterprise. Windows doesn’t have a lot of the same BS in their enterprise versions that are in the personal ones. Even with the same software, it could just be a checkbox that the salesperson can check for big businesses with legal teams that read and enforce contracts.
But why was this attacking novels? Are comic books safe?
If your LAN is already compromised with a rogue DHCP server, you’ve got bigger problems than them intercepting just VPN traffic. They can man in the middle all of your non-encrypted traffic. While this is bad, it’s not a scenario most people will run into.
I wonder if it applies to routers made by a company who likes collecting user data. Because this is a situation many people are in.
The other comment already covers the fact that VPN should be useful exactly when you are connected to untrusted LANs. I want to add that also the main point of your comment is anyway imprecise. You don’t need a compromise DHCP, you just need another machine who spoofs being a DHCP. Not all networks have proper measures in place for these attacks, especially when we are talking wireless (for example, block client-to-client traffic completely). In other words, there is quite a middle-ground between a compromised router (which does DHCP in most cases) and just having a malicious device connected to the network.
The problem isn’t them being in you LAN. It’s about going to an untrusted network (eg Starbucks, hotel) and connecting to your VPN, boom, now your VPN connection is compromised.
I woke up this morning and thought of this exact scenario, then found your comment lol
Yes, this is bad for anyone who travels for work and can’t trust the network they connect to.
To execute this you need a DHCP server on the network… But any admin worth his salt has a config on the switch to limit DHCP traffic to a designated server.
Seems extremely difficult to pull off in any corporate environment
But makes coffee shop wifi inherently more risky
For shits and giggles I used to sit on those wifis and run a mitm…I would replace all images with the troll face meme…then sit back and watch the confusion. So ya
Now you get to do it again but this time to the VPN users that thought they were above your antics
Step one, be in full control of DNS on the network. Not difficult, but not simple.
A good reason to never trust in shady VPNs.
This isn’t a problem with the VPN, as the article says.
But that involves clicking the link and reading.
We don’t do that here, we just get angry.
According to the article i suppose the same technique can be implemented by the VPN provider, but if you like to continue using shady VPNs it’s not my business… good luck!! 👍✌️.
A shady vpn provider wouldn’t need to use this technique at all dumbass.
Keep crying LMAO…
Why would someone cry because you’re wrong?
So…
reject 121;In your dhclient?
So I gave the article a glance and it’s a bit beyond me can someone give me an eli5?
My understanding is that if you run a rogue discoverable DHCP server in a local network with a particular set of options set and hyper-specific routing rules, you can clobber the routing rules set by the VPN software on any non-Android device, and route all traffic from those devices through arbitrary midpoints that you control.
But IANANE (I am not a network engineer) so please correct my misinterpretations.
this implies physical access or at least access within the network?
Keeping in mind that may mean that somebody like a cellular provider could do so. Since your local network in that context would be them.
Exactly. And if your ISP or cellular provider wants, or is forced, to gather information about your internet activities, they can almost certainly find a way. The cheap consumer-grade VPN services most of us use just prevent casual or automated observers from easily detecting your device’s IP address. For most people that just want to torrent casually or use public wifi, it’s enough.
Or to watch porn in one of the states that block porn.
It has implications on the effectiveness of VPNs on public networks.
That, or the ability to spoof it
(obligatory I’m not a network surgeon this is likely not perfectly correct)
The article mentions network interfaces, DHCP and gateways so real quick: a network interface usually represents a physical connection to a network, like an Ethernet port or a WiFi card. DHCP is a protocol that auto configured network routes and addresses once a physical connection is established, like when you jack in via an ethernet cable, it tells you the IP address you should go by, the range of IP address on the network you’ve connected to, where you can resolve domain names to IP addresses. It also tells you the address of a default gateway to route traffic to, if you’re trying to reach something outside of this network.
You can have more than one set of this configuration. Your wired network might tell you that your an address is 10.0.0.34, anything that starts with 10.0.0. is local, and to talk to 10.0.0.254 if you’re trying to get to anything else. If at the same time you also connect to a wireless network, that might tell you that your address is 192.168.0.69, 192.168.0.* is your local network, and 192.168.0.254 is your gateway out. Now your computer wants to talk to 4.2.2.2. Should it use the wireless interface and go via 192.168.0.254? or the wired one and use 10.0.0.254? Your os has a routing table that includes both of those routes, and based on the precedence of the entries in it, it’ll pick one.
VPN software usually works by creating a network interface on your computer, similar to an interface to a WiFi card, but virtual. It then asks the OS to route all network traffic, through the new interface it created. Except of course traffic from the VPN software, because that still needs to get out to the VPN provider (let’s say, at 1.3.3.7) via real Internet.
So if you’re following along at time, your routing table at this point might look like this:
- traffic to 1.3.3.7 should go to 10.0.0.254 via the wired interface
- all traffic should go to the VPN interface
- traffic to 10.0.0.* should go to the wired interface
- all traffic should go to 10.0.0.254 via the wired interface
- traffic to 192.168.0.* should go to the wireless interface
- all traffic should go to 192.168.0.254 via the wireless interface
whenever your os wants to send network packets, it’ll go down this list of rules until one applies. With that VPN turned on, most of the time, only those two first rules will ever apply.
If I’m reading the article correctly, what this attack does, is run a DHCP server, that when handing out routing rules, will send one with a flag that causes, for example, the last two rules to be placed at the top of the list instead of the bottom. Your VPN will still be on, the configuration it’s requested the OS to make would still be in place, and yet all your traffic will be routed out to this insecure wireless network that’s somehow set itself as the priority route over anything else.
Thank you, you are a surgeon of charity
Thank you network nurse
That actually lays it out incredibly well for me. So in practice, what would I need to look out for as a wired desktop Ubuntu user with mullvad? It’s sounding like this is going to be an issue on public networks, is this something my isp can do to me at home?
It all depends on how much you trust the devices on your LAN. So your ISP can’t do anything unless they own and control your router, since that is on your LAN. So one concern might be if you connect your PC to coffee shop wifi, since all other devices in the shop are on the same LAN, not to mention the coffee shop owns the wifi router and can also perform the attack. Another concern might be if a family member in your house has a device that got hacked, then all devices in your house are vulnerable.
So if they are changing routes by using DHCP options, perhaps this could be exploited by telecom insiders when you are using mobile data, because your mobile data IP could be assigned by a DHCP server on the telecom network. If you’re at home on wifi, then you can control your own DHCP server to prevent that.
The attack vector here seems to be public WiFi like coffee shops, airports, hotels and whatnot. The places you kinda do want to use a VPN.
On those, if they’re not configured well such as coffee shops using consumer grade WiFi routers, an attacker on the same WiFi can respond to the DHCP request faster than the router or do an ARP spoof attack. The attacker can proxy the DHCP request to make sure you get a valid IP but add extra routes on top.
No - the VPN provider has another DHCP server for use ‘inside’ the VPN.
The attack vector described in the article uses the VPN client machine’s host network, i.e. the local network the device is attached to. They don’t discuss the DHCP server of the VPN provider.
Read this part more carefully:
By pushing routes that are more specific than a /0 CIDR range that most VPNs use, we can make routing rules that have a higher priority than the routes for the virtual interface the VPN creates.
Most traffic gets sent through a VPN only because of a default gateway (set by the VPN) in the client’s routing table. If the client’s ISP were to have their DHCP server set one or more specific routes that are broad enough to cover most of the global address space, they would effectively override that default gateway. I believe that’s the scenario described in the article.
Note that the ISP could be a mobile operator, an internet cafe, an airport, or a malicious actor running a wifi access point disguised as the airport access point.
Except this bypasses that I believe.
Most VPN providers don’t use DHCP. OpenVPN emulates and hooks DHCP requests client-side to hand the OS the IP it got over the OpenVPN protocol in a more standard way (unless you use Layer 2 tunnels which VPN providers don’t because it’s useless for that use case). WireGuard doesn’t support DHCP at all and it always comes from configuration.
there are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android.
So . . . unix? Everything-but-Windows?
Everything-but-Windows?
No. Any device that implements a certain DHCP feature is vulnerable. Linux doesn’t support it, because most Linux systems don’t even use DHCP at all let alone this edge case feature. And Android doesn’t support it because it inherited the Linux network stack.
As of this writing, 5 people who don’t know how DHCP works saw this comment
because most Linux systems don’t even use DHCP
This is the dumbest thing I’ve heard all day.
most Linux systems don’t even use DHCP
WTF are you smoking? WTF is wrong with you that you think such a dumb claim would go unscrutinized? I would play Russian roulette on the chances of a random Linux installation on a random network talking DHCP.
Edit, in case being charitable helps: DNS and IP address allocation aren’t the only things that happen over DHCP. And even then the odds are overwhelming that those are being broadcast that way.
Maybe it affects BSD and MacOS.
It also can affect some Linux systems based on configuration. Android doesn’t implement the exploited standard at all and is always immune.
Meh, option 121 shenanigans can be detected and remediated via post connection scripting.
“There are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android.”
So there are ways.
Common Linux w
Not really, Linux is still vulnerable and there is a mitigation but it opens a side channel attack.
This is the way
Wait so the vulnerability exists on macos and iphone even though those are based on bsd (right?)
Edit: and also Windows, forgot about Windows
Hilariously enough, Windows users can use WSL to run a Linux VPN (but only applications running in WSL are safe if I understand the attack right)
True, if you neg a linux dev online enough for two years, you can make your entire infrastructure vulnerable to attack
Android
Here is an alternative Piped link(s):
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
Hate to rain on the Linux parade here, but didn’t the article say: “There are no ways to prevent such attacks except when the user’s VPN runs on Android.” and that Linux was just as vulnerable as Windows?
you’re replying to a verbatim quote from the article.
I was going from this: (emphasis mine)
Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn’t implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.
It’s not as vulnerable but it still is.
Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn’t implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.
But in the details this attack is not that bad. E.g. NordVPN and I guess also other VPNs use firewall rules to drop traffic on normal network interfaces.
Their side channel is still routing traffic away from the VPN channel. Then they can observe that there is no traffic and guess that the user either didn’t make requests in that moment or that he wanted to visit a website in the range covered by the route. They can not spy on the traffic.
Also you can not quickly move into a network and apply this attack, as DHCP leases usually last 1 day or at least 1 hour. Only when they expire you can apply the attack (or you force the user to drop from the network, which is easy if they are using WPA2, but only possible by blocking the wifi signal if they are using WPA3)
It is a serious issue and should be mitigated, but not as huge as news articles make it.
You can also use network namespaces on Linux which Wireguard has a nice explanation and walkthrough on, recommending this as part of setting up wg connections. https://www.wireguard.com/netns/
I saw that but unfortunately it doesn’t detail how to set it up persistently on every boot. And I also haven’t seen anybody using this method, probably because of the lack of tooling around it. For example afaik the official Mullvad client on linux just uses a firewall.
This is the best summary I could come up with:
Researchers have devised an attack against nearly all virtual private network applications that forces them to send and receive some or all traffic outside of the encrypted tunnel designed to protect it from snooping or tampering.
TunnelVision, as the researchers have named their attack, largely negates the entire purpose and selling point of VPNs, which is to encapsulate incoming and outgoing Internet traffic in an encrypted tunnel and to cloak the user’s IP address.
The attack works by manipulating the DHCP server that allocates IP addresses to devices trying to connect to the local network.
A setting known as option 121 allows the DHCP server to override default routing rules that send VPN traffic through a local IP address that initiates the encrypted tunnel.
When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.
This remedy is problematic for two reasons: (1) a VPN user connecting to an untrusted network has no ability to control the firewall and (2) it opens the same side channel present with the Linux mitigation.
The original article contains 903 words, the summary contains 196 words. Saved 78%. I’m a bot and I’m open source!
