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
You must log in or register to comment.
Claim: if you use HTTPS you are safe!
Overall a solid writeup, but this part could use some clarification. Assuming the VPN client doesn’t leak DNS this is only a concern after exploitation by DHCP option.
Another thing that might be noted, since this is a DHCP based issue the window for compromise is largely going to be at the time of connection unless the server has a particularly short lease time. If there are multiple DHCP servers on the same network answering requests it’s bound to raise some alarms if someone is watching the network so it makes 3rd person exploitation a very noisy method since you would have a race for who offered the lease first.
Edit: Really this attack isn’t just a problem for VPNs but could apply to any network connectivity. A rouge DHCP sever can cause all sorts of havoc. There used to be an single button APK called ‘firesheep’ that would do similar to this by presenting itself as the gateway, although that wouldn’t have allowed for the specific split routing config option push.
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.
Discover/offer/request/acknowledge since it didn’t make a pretty picture for me.
Basically it’s just a case of who answers first. A DHCP discover is a broadcast message since the client doesn’t know where or even if there is a server on the net. Whoever gets back to the client first with an offer though will end up with the request/ack following up and get to provide whatever options they push along with the offer.
So it’s really that simple…I can see why there are security issues 😅
To add to that, (or maybe you said this, forgive me if so I am sick RN and my brain is not working optimally), there’s no such thing as a trusted network, and many ways to trick devices into connecting. Evil twins are clones of nearby networks that you will connect to instead. There’s also an attack where your device is actively sending out requests to connect to saved networks, and an attacker can simply respond to that request to get you to connect, and authenticate regardless of what password you send.
WiFi pineapples are fun that way. I’ve taken one out on a drive going to our cabin in scanning mode and picked up 100+ different SSIDs along the way. It can also respond as a wildcard to any request that comes by or just be obnoxious and advertise them all at one.
Never setting an ‘auto connect’ for unsecured WiFi is a must in that case. Secured not so much an issue unless the interceptor has the key for the network at least.
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…
Yeah. The school I go to uses MAC based blocking on their network, and it is otherwise an open network.
Most mobile devices these days default to using a random spoofed MAC, so I have a hard time seeing how that’s effective unless it’s done as a whitelist only.
It’s done as a whitelist and they issue devices.
Thank you for summarizing it up
I’ve been using network namespaces in Linux where each one also use a different user; this way you can have multiple profiles of apps separated not only by permissions but also by the VPN connection that is the only route out
So you can have a connection that will supply your favorite iso sharer, a VPN connection to work, all unaware of each ot
I still haven’t figured how to make GUI media applications work on them though
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?
Sure, someone helped me setting up a script to share the wl socket between namespaces so I can run GUI programs in isolated namespaces, and if you look at this post you can check the namespaced-openvpn; also check vole’s answer if you want to run GUI programs
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.
Got in touch with ProtonVPN support and asked about this. Here’s their reply:
Our engineers have conducted a thorough analysis of this threat, reconstructed it experimentally, and tested it on Proton VPN.
We concluded that:
- The attack can only be carried out if the local network itself is compromised
- Our Windows and Android apps are protected against it
- For iOS and macOS apps, you are completely protected from this as long as you’re using a Kill Switch and a WireGuard-based protocol (our apps use them by default, and if a user wants to use something other than WireGuard derivates, they’d have to manually set it up). Note that Stealth, WireGuard TCP and Smart protocol on iOS/macOS are all WireGuard-based.
- For our Linux app, we’re working on a fix that would provide full protection against it.
Since android are not subject to the risk, I wonder what happens if one connects the computer with hot spot from android.
Edited: just found out in the original report hot spot was also mentioned as a mitigation technique.
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.
This is blatantly false. They can see IP addresses and ports of you connect to from IP packets, and hostnames from TLS negotiation phase (and DNS requests if you don’t use custom DNS settings). HTTP data is fully encrypted when using HTTPS.
If exposing hostnames and IP addresses is dangerous, chances are that establishing a VPN connection is as dangerous.
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.
It says right in there that they can’t see what you are sending or receiving, but seeing the SNI provides content on what you’re doing. Not seeing where it’s false at all.
Using that SNI header profile though if one was inclined and the site doesn’t enforce HSTS it would be simple enough to proxy traffic through their gateway, or to creating a phishing duplication of the site with a DNS redirect.
