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
So it's really that simple...I can see why there are security issues 😅
Great write-up, I've been looking for something like this. I've heard of vopono and eznetns before but not namespaced-openvpn, and this is the first post I've seen where somebody details how they use a tool like this, so thanks! I'll have to try setting it up some time.
Yeah, you don't have to dig very deep to find out how insecure our networks are. Mac addresses can be spoofed, ports can be scanned, TCP numbers can be guessed, etc...
From a privacy standpoint I don't think it would make a big difference over not using a VPN at all. It will take a bit of time but your new IP will become associated with your identity. From the perspective of Facebook and Google, it will just look like you moved and are living inside a datacenter now.
That sounds very cool, I've been interesting in network namespaces but it's hard to find information on how to use them. How did you do it?
If exposing hostnames and IP addresses is dangerous
It's not necessarily dangerous, but it's a major privacy issue. Hiding your browsing history from other people (except for the VPN provider) is one of the main reasons why people get a commercial VPN in the first place. And this vulnerability mainly concerns those users.
I added clarification that the HTTPS part is assuming that the attacker has already performed the DHCP attack. Thanks for the note!
The DHCP race is one part I didn't go into detail about since I'm not very familiar with the details, but what you wrote makes sense. One potential danger is a hacker at a coffee shop, where the shop owner is unlikely to be monitoring the network, and there are going to be many new connections coming in all the time. It's still an unlikely scenario, but it also isn't a particularly difficult attack.
No offense taken, on the contrary thanks for the constructive criticism! I'll add some more details to my repo to make things more clear.
Yeah, it does come down to threat model and preference. If you only need to route specific apps, Gluetun sounds like a great solution.
I've been seeing a lot of confusion around the TunnelVision vulnerability. While I'm no expert, I've done a fair share of research and I'll edit this post with corrections if needed. The goal of this post is to answer the question: does this affect me?
Two sentence summary of the vulnerability
When you use a commercial VPN like Mullvad or NordVPN, the VPN client tells your system to redirect all traffic through the VPN. This recent vulnerability shows that a malicious device on the network can trick your system into redirecting traffic to their device instead.
Claim: just don't connect to hostile networks!
This is hard in practice. For most people, the only "trusted" networks are your home network and your workplace. So you still have to worry about coffee shops, airports, hotels, restaurants, etc. And if you are using cellular data, the cellular tower can perform this attack to snoop on your traffic.
Claim: but I trust the hotel owner, restaurant owner, etc
This attack allows any device on the network to impersonate a DHCP server and attack your system, not just the router. And while there are router settings that can prevent devices on the network from talking to each other, afaik they are rarely used. So even if you trust the owner of the cafe, you have to also trust everybody else in the cafe.
Claim: if you use HTTPS you are safe!
If the attacker redirects traffic to their machine, then even if you use HTTPS, the attacker can still see what websites you connect to, they just can't see what you are sending or receiving. So basically they can steal your browsing history, which defeats the purpose of a commercial VPN for many users.
Claim: Linux users are safe!
Not quite. The report says that Linux has a feature that is able to fully defend against this vulnerability, called network namespaces. So if your VPN uses that, congratulations. Afaik most VPNs do not use this, and instead use a kill-switch or a firewall. In which case Linux, Mac, and Windows users are all affected the same way, and I go into it more in the next claim.
Claim: if you use a kill-switch you are safe!
The term "kill switch" gets thrown around a lot but there's actually two major ways that a kill-switch can be implemented. The first way is a more literal "kill switch" - when the VPN connection drops, the kill switch is triggered and blocks leaks. The other way is a persistent firewall, which blocks leaks all the time.
If your VPN client uses the first kind, then bad news, it won't protect you against this attack. This is because the VPN connection is never dropped, so the kill switch is never triggered. NordVPN was caught using this poor practice, to nobody's surprise (more info here).
If your VPN uses the second kind, then you should be safe. For example, Mullvad published a statement about how they are not vulnerable here. I would hope that any competent VPN would also use a persistent firewall, but if your VPN provider hasn't published a statement yet, unfortunately your only other option is to inspect the VPN client yourself.
That being said, even if your VPN uses a persistent firewall, you may have read in the report that there's a "side-channel" attack still possible...
Claim: even if you use a firewall, there's a side-channel attack
This is true, but from what I read the side-channel is actually very hard to pull off and gain any useful information from. You can read some discussion about it here. My takeaway is that if you're a regular user, you don't have to worry about it. But we should still push VPN providers and network engineers to use network namespaces in their applications, since they are more resistant to these kinds of attacks.
Claim: you shouldn't trust commercial VPN providers anyways
This is not really about the vulnerability but I've seen it a lot in the discussions. I think it's a mischaracterization of why people use VPNs. If you are using the internet, somebody has to send that traffic to your destination. The three major options are your ISP, a VPN provider, or Tor. Depending on your location and your circumstances, you will trust these three differently. In the EU, ISPs are not allowed to sell data. In the US, ISPs are allowed to, and have been caught doing so. VPNs can sell data too but they risk losing their entire business. Tor is much harder to judge, but the bigger issue with Tor is that many websites block it.
Further reading:
- Official Report
- Official TLDR and FAQ
- Arstechnica article
- Hacker News discussion
- one of the original researchers is active in this discussion, see comments by @morattisec
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.
how would you not use DHCP when connecting to coffee shop wifi?
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 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.
How do you route all a host system's traffic through Gluetun? If you use routing tables, wouldn't it similarly be affected by TunnelVision? In which case you would still need a firewall on the host...
Also, the host system likely makes network requests right after boot, before a Gluetun container has time to start. How do you make sure those don't leak?
I am curious though, how you were able to route all host traffic through Gluetun. I know it can be used as a http/socks proxy, but I only know of ways to configure your browser to use that. What about other applications and system-level services? What about other kinds of traffic, like ssh?
I'm no network security expert, so I mainly followed Mullvad VPN for my implementation. I looked at the nftables rules that official Mullvad linux client uses, and also their document here: https://github.com/mullvad/mullvadvpn-app/blob/main/docs/security.md.
Though if you have any alternatives for vanilla wireguard users like me, I'll gladly switch. I know somebody mentioned Gluetun but I thought that was for docker only. Do you know of any others?
Isn't gluetun for docker? Are there people running it on the host system?
Actually my firewall is persistent, just like many of the other good VPN clients, so "kill switch" is a bit of a misnomer. Which is why I called it wg-lockdown, named after Mullvad's lockdown mode. Persistent firewalls are effective, they just add a very tiny side-channel, as discussed in the link in my post. I just used the terms "kill switch" in my post because that's what many other people use.
Though the point about the LAN is a good point, I didn't consider that. I added LAN access because without it, the firewall was interfering with the networking of my docker container and virtual machines, which use local subnets. Even the official Mullvad client has issues with this. What do you recommend in this case? Manually whitelist the local subnets used by docker and my other virtual networks?
Edit: actually upon reading Mullvad's statement on TunnelVision, I realized that my firewall is still effective because it only allows traffic directed to LAN IP's to bypass the VPN. So regular internet traffic will be blocked if the attacker tries to redirect it to the LAN. I'm glad I used Mullvad as a reference implementation 😅
cross-posted from: https://lemmings.world/post/8926396
> In light of the recent TunnelVision vulnerability I wanted to share a simple firewall that I wrote for wireguard VPNs. > > https://codeberg.org/xabadak/wg-lockdown > > If you use a fancy official VPN client from Mullvad, PIA, etc, you won't need this since most clients already have a kill switch built in (also called Lockdown Mode in Mullvad). This is if you use a barebones wireguard VPN like me, or if your VPN client has a poorly-designed kill switch (like NordVPN, more info here). > > A firewall should mitigate the vulnerability, though it does create a side-channel that can be exploited in extremely unlikely circumstances, so a better solution would be to use network namespaces (more info here). Unfortunately I'm a noob and I couldn't find any scripts or tools to do it that way.
In light of the recent TunnelVision vulnerability I wanted to share a simple firewall that I wrote for wireguard VPNs.
https://codeberg.org/xabadak/wg-lockdown
If you use a fancy official VPN client from Mullvad, PIA, etc, you won't need this since most clients already have a kill switch built in (also called Lockdown Mode in Mullvad). This is if you use a barebones wireguard VPN like me, or if your VPN client has a poorly-designed kill switch (like NordVPN, more info here).
A firewall should mitigate the vulnerability, though it does create a side-channel that can be exploited in extremely unlikely circumstances, so a better solution would be to use network namespaces (more info here). Unfortunately I'm a noob and I couldn't find any scripts or tools to do it that way.