i think docker allows for this configuration. i use a gluetun container for the network definition of the torrent container to prevent leaking. the torrent container knows of no other network than the vpn container.
To get the webui out of that I stuck two instances of socat together at the stdout and from there it depends on whatever you want to use as a reverse proxy on the host - or you bind to a network interface if you trust the network:
Do you know how to make it so all the host's traffic is sent through the VPN namespace? I couldn't figure out how to do this so I ended up just writing my own firewall. Network namespaces seems like a better solution.
I haven't found the time to research an answer for you, sorry. The way I'd go is: create a veth of your physical uplink and stuff it into its own namespace with dhcp client and wg userspace tools. Do not configure the original interface in your initial namespace. Use the approach wg-netns uses to spawn the tunnel interface in initial network ns. Done.
No worries, and thanks for providing a response nonetheless. I'll look into your suggestion when I have the time. The official Wireguard website also had some guide on network namespaces here but afaik it didn't explain how to set it up persistently
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).
Many VPN-Programs by Providers already have settings to enable this to prevent "leaking".
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.
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.
(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 home, 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.
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.
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?
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.
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.
If i get this right, that attack only works before the tunnel is initiated (i.e. traffic encrypted), if the hosts is compromised, right? No danger from untrusted points inbetween, right?
This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server. We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.
Sounds to me like it totally works even after the tunnel has started.
More like a corrupt traffic cop. There are reasons you might want this kind of functionality, which is why it exists. Normally you can trust the cop (DHCP server) but in this case the cop has decided to send everyone from all streets down to the docks.
That being said, it apparently does not affect Mullvad apps on any platform other than iOS (Apple does not allow fixing it on iOS). I suspect other serious VPNs are also not vulnerable outside iOS, since it is prevented by simple leak prevention mechanism.
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.
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.
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.
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
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
While those are valid concerns, it's not really hard to see why people use VPNs. Just look at how companied and countries abuse the internet, abuse us.
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.
I think this is a good enough reason to actually put in some effort to phase out ipv4 and dhcp. There shouldn't be a way for some random node on the network to tell my node what device to route traffic over. Stateless ipv6 for the win.
I don't think it's laziness, it's financial incentive—there's not much demand for something that might be quite a lot of work from a lot of companies' perspectives.
Hell, IIRC AWS only started supporting IPv6 completely on the cloud service that hosts a huge percentage of the internet's traffic about 3 years ago
I'm a little curious about your situation though—with regards to the CGNAT, does everyone on your ISP effectively share one (or a small pool of) IPv4 address(es)? Do you ever see issues with IP restrictions? (e.g. buying tickets for events, etc)
My provider uses the same IPv4 for four different customers, and it lets each one of them use a different range of 12000 ports each (of course, the random user on ports 1-12000 is the "luckiest" one because he could theoretically host a website on port 80 or 443).
But this means I can expose my Torrent client or Plex or any other services on a custom port, directly forwarded.
It works really well in my experience. The provider is Free (France).
CGNAT is certainly becoming a real issue. In the UK at least legacy providers have millions of IP addresses in the bank and new disruptive providers do not have access to these except at extremely inflated rates.
When I changed one of these new disruptive providers I was unaware that CGNat would be imposed and all of my security cameras were no longer accessible. Fortunately they did move me off CGNat when I asked but they said it may not be forever.
Like always I don't think this will be dealt with in any speedy capacity, unless we get lucky and some correctly positioned legislator can't do what they want to do with their internet connection. Then it might get expedited.
So for this attack to work, the attacker needs to be able to run a malicious DHCP server on the target machine’s network.
Meaning they need to have already compromised your local network either physically in person or by compromising a device on that network. If you’ve gotten that far you can already do a lot of damage without this attack.
For the average person this is yet another non-issue. But if you regularly use a VPN over untrusted networks like a hotel or coffee shop wifi then, in theory, an attacker could get your traffic to route outside the VPN tunnel.
The thing is that in most cases you don’t need a VPN to protect yourself on a public network. The ubiquity of TLS on the internet already does a great job of that. Using a VPN on a public network for privacy and security reasons amounts to little more than the obfuscation of which sites you’re visiting, and some fallback protection against improperly configured websites. So while I agree it isn’t entirely a non-issue, it definitely isn’t as big of an issue as one might assume given the scary wording of the headline and article.
Not quite, this could be exploited by telecom providers when using mobile data. Also using a VPN for networks you DON'T control is one of the more popular uses of the things
Not all VPN traffic. Only traffic that would be routable without a VPN.
This works by tricking the computer into routing traffic to the attacker’s gateway instead of the VPN’s gateway. It doesn’t give the attacker access to the VPN gateway.
So traffic intended for a private network that is only accessible via VPN (like if you were connecting to a corporate network for example) wouldn’t be compromised. You simply wouldn’t be able to connect through the attacker’s gateway to the private network, and there wouldn’t be traffic to intercept.
This attack doesn’t break TLS encryption either. Anything you access over https (which is the vast majority of the internet these days) would still be just as encrypted as if you weren’t using a VPN.
For most people, in most scenarios, this amount to a small invasion of privacy. Our hypothetical malicious coffee shop could tell the ip addresses of websites you’re visiting, but probably not what you’re doing on those websites, unless it was an insecure website to begin with. Which is the case with or with VPN.
For some people or some situations that is a MASSIVE concern. People who use VPNs to hide what they’re doing from state level actors come to mind.
But for the average person who’s just using a VPN because they’re privacy conscious, or because they’re location spoofing. This is not going to represent a significant risk.
Plaintext connections inside corporate networks can still be MITM'ed if the adversary knows what they're targeting, while they can't connect to the corporate network they can still steal credentials
You wouldn’t be able to MITM a plaintext connection inside a corporate network with this attack by itself. You could only MITM something that the attacker can access without your VPN.
Any corporate network that has an unsecure, publicly accessible endpoint that prompts for credentials is begging to be hacked with or without this attack.
Now you could spoof an login screen with this attack if you had detailed info on the corporate network you’re targeting. But it would need to be a login page that doesn’t use HTTPS (any corporations, dumb enough to do that this day and age are begging to be hacked), or you’d need the user to ignore the browser warning about it not being secure, which that is possible.
I'm tech support so I've seen some stuff, sooo many intranet sites on internal servers don't have HTTPS, almost only the stuff built to be accessible from the outside has it. Anything important with automatic login could be spoofed if the attacker knows the address and protocol (which is likely to leak as soon as the DHCP hijack is applied, as the browser continues to send requests to these intranet sites until it times out). Plaintext session cookies are also really easy to steal this way.
Chrome has a setting which I bet many orgs have a policy for;
I do still think that a lot of people do use VPNs in public spaces for privacy from an untrusted provider, though, perhaps more than your initial comment seemed to suggest.
As I mentioned in my other comment, this wouldn’t let an attacker eavesdrop on traffic on a VPN to a private corporate network by itself. It has to be traffic that is routable without the VPN.
I don't know, if you've already have full control over routing and have some form of local presence, seems to me you could do something interesting with a proxy, maybe even route the traffic back to the tunnel adapter.
I can’t see routing traffic to some kind of local presence and then routing back to the target machine to route out through the tunnel adapter without a successful compromise of at least one other vulnerability.
That’s not to say there’s nothing you could do… I could see some kind of social engineering attack maybe… leaked traffic redirects to a local web server that presents a fake authentication screen that phishes credentials , or something like that. I could only see that working in a very targeted situation… would have to be something more than just a some rouge public wi-fi. They’d have to have some prior knowledge of the private network the target was connecting to.
That's why half decent VPN apps also add firewall rules to prevent leakage. Although nothing can beat Linux and shoving the real interface in a namespace so it's plainly not available to anything except the VPN process.
Yes, I don't agree with the no way to mitigate statement.
I suspect on windows the only real defence is something like.
Check if the network has suspicious multiple routes setup from the DHCP
If so, either use the IP/Mask/Gateway with manual IP config (to not receive the CIDR routes) or steer clear of an at best questionable network entirely.
Maybe use the windows firewall to block all traffic outbound EXCEPT from the firewall program (with perhaps exceptions for local networks as per below linux example). For whatever reason the windows firewall doesn't seem to have a way to specify an interface. But you can specify a program.
I did look for some way to control Window's handling of DHCP options. But it seems there isn't anything obvious to limit this otherwise. I do not know if the windows firewall has this kind of fine-grained control with its own fire
For linux, I used to have my own blackout firewall rules. That only allowed the specific LAN range (for mobile use you could include all RFC1918 ranges) and the specific VPN IP out of the internet facing interface. Only the VPN interface could otherwise access the internet.
Some providers have managed to make split tunnelling work fine so those I suspect are not affected because they override the routing at the driver level. It's really only the kinda lame OpenVPN wrappers that would be affected. When you have the custom driver, you can affect the routing. It's been a while since I've tested this stuff on Windows since obviously I haven't been paid to do that for 6 years, but yeah I don't even buy that all providers are affected and that it's unfixable. We had workarounds for that when I joined PIA already so it's probably been a known thing for at least a decade.
The issues we had is sometimes you could get the client to forget to remove the firewall rules or to add back the routes and it would break people's internet entirely. Not great but a good problem to have in context.
Pushing a route also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface. This is intended functionality that isn’t clearly stated in the RFC. Therefore, for the routes we push, it is never encrypted by the VPN’s virtual interface but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface talking to our DHCP server.
Ok, so double encrypted and authenticated traffic (TLS inside the VPN) would still be safe, and some stuff requiring an internal network origin via the VPN is safe (because the attacker can't break into the VPN connection and your client won't get the right response), but a ton of other traffic is exposed (especially unencrypted internal traffic on corporate networks, especially if it's also reachable without a VPN or if anything sends credentials in plaintext)
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.
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.
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.
