TunnelVision: The end of the VPN as we know it!?
This week we have a long article to help contextualize a new exploit that has a lot of people in the privacy and missionary spaces concerned.
Ars Technica dropped a bomb of an article which reports a vulnerability that’s existed in networking software since 2002 and allows attackers to “neuter[ VPNs’] entire purpose.”
It’s a bold assertion. They essentially say that any attacker can just—*boop*—neuter your VPN.
Take five minutes and go read the article here for context: https://arstechnica.com/security/2024/05/novel-attack-against-virtually-all-vpn-apps-neuters-their-entire-purpose/
Now that you’re back, let’s break down this attack:
The attacker must be on the same Local Area Network as you (think coffee shop or hotel Wi-Fi in this case).
The attacker must control a malicious DHCP server—a server which allows them to assign IP addresses to machines on the local network.
Your machine must look to that DHCP server for IP and route information.
The attacker must push a bad route to your network interface card that causes your computer to route internet traffic to their malicious server as the gateway instead of to your VPN app.
The attacker must be in a position to capture traffic and/or decrypt or strip other encryption protecting your communications to learn something of value.
In other words, this isn’t an attack where just any attacker anywhere on the internet can *boop* your VPN into revealing information about you. In fact, this isn’t actually a problem with the VPN software—it’s a problem with how Windows, MacOS, iOS, and Linux handle network configurations. That’s why most VPN providers aren’t in a position to fix this.
To reinterpret what the attack requires:
The attacker must already have access to the network you are on and be able to send network traffic to and from your computer (this is most relevant on public networks like coffee shops or hotels, though many now isolate all computers on the network from each other).
The attacker must deploy a malicious DHCP server without crashing the local area network in the act of deploying a second DHCP server, or must be able to take over the existing DHCP server.
The attacker must be able to force your computer to trust their server, so probably needs to have already compromised the router or the existing DHCP server.
The attacker pushes a bad route to your computer’s network interface which causes your computer to route over the normal network interface instead of the VPN’s virtual interface.
The attacker must be able to decrypt HTTPS traffic when it receives your network traffic and then relay that traffic on to legitimate sites.
In other words, this attack most likely occurs on a pre-compromised public network. That’s not unheard of, Russia’s known to attack hotel chains for exactly these kinds of purposes (https://www.reuters.com/article/idUSKBN1AR1IZ/), but your VPN hasn’t been neutered either.
How Virtual Private Networks Work
This attack works because using a VPN is effectively on off-label use of networking magic medicine. VPNs were originally designed to connect together distant local networks into corporate wide area networks. They’re used for privacy because—by simulating connecting to a massive conglomerate with millions of users—you gain the cryptography protecting the connection as well as the anonymity of the crowd.
When you turn on a VPN, it generally establishes a tap and tunnel interface on your computer that serves as a virtual network interface and sets up routes to determine whether traffic uses that interface. In the corporate wide area network scenario, those routes tell your computer to send business traffic to business servers and send the rest to the local net or internet as normal.
In the privacy context, VPNs are usually configured to route all network traffic across the VPN before allowing it to go out to the internet.
This makes your traffic appear to come from the conglomerate, not the individual.
In this case, the TunnelVision vulnerability leverages how DHCP servers talk to computers. The IP-address-authority-server sends a route to your computer that trumps the virtual network interface and says “don’t talk to him, talk to me.”
At this point, the attacker is able to see your network traffic as if there’s no VPN. But that’s not the end of the story.
What can attackers really get?
One thing to keep in mind with exploits like this is that they're not panopticons. They are targeted at specific networks and more ubiquitous encryption like HTTPS still provides value.
Just being in control of a route is sufficient to snoop on IP addresses, session lengths, maybe domain names, and other metadata. But specific encrypted information like what you are searching on google.com is probably not visible.
If decrypting traffic were so trivial, more random hops on the way from your home Wi-Fi to google.com would do it. And then your VPN wouldn’t matter because every nation-state attacker would sit close to google.com on your route, crack your cryptography, and read the internal details of your traffic to re-identify you.
Don’t get me wrong, it’s doable, but it’s costly to do at large scale and usually would involve a mass push to undermine the integrity of cryptography on the internet as a whole (So think China’s issuance of fake root certificates: https://en.wikipedia.org/wiki/Root_certificate or Facebook trying to spy on Snapchat https://www.malwarebytes.com/blog/news/2024/03/facebook-spied-on-snapchat-users-to-get-analytics-about-the-competition)
These kinds of attacks are made more expensive by modern browser defenses. Browser developers cooperate with web sites that publish their encryption certificates so that both the web site and the user can automatically verify there is no man-in-the-middle before allowing a connection.
So, the attacker on your hotel Wi-Fi is probably seeing HTTPS. That means they are seeing mostly metadata, not data. In privacy circles it’s common to quote Retired General Hayden of NSA fame saying “We kill people based on metadata,” (https://www.youtube.com/watch?v=tL8_caB35Pg). But that quote is from 2014, and some things have changed in our favor.
The biggest change being the proliferation of encrypted domain name systems which vastly reduce the value of domain metadata. The second being the proliferation of content delivery networks and cloud exchanges (CloudFlare, AWS, Microsoft Azure, etc.) causing most traffic to appear to route into massive corporate networks.
What this effectively means is that unless I can decrypt HTTPS I can no longer see the following in large volume:
The domain name of the site you’re going to because it’s probably encrypted
The specific server address of the site you’re going to because it’s probably in a massive shared Microsoft, Amazon, Akami, or Cloudflare network
The part of the site you’re going to because it’s encrypted within HTTPS
This isn’t universally applicable, but it’s generally true. However, if you’re in a nation where the very internet itself is engineered to allow intercept or where all companies are expected to comply with data and intercept requests, you’ve got bigger problems than your VPN can fix for you.
So ,what do we do about this?
First, procedurally. Don’t do sensitive work on untrustworthy public networks unless you actually have to. If someone looking over your shoulder in an airport would get you in trouble, don’t do it in an airport.
Second, when you turn your VPN on, check the IP address it reports. Then go to a leak detection site like https://whatismyipaddress.com/vpn-leaking and see if the IP address reported is the same as the one your VPN reports. If not, you’re not masked by the VPN. That doesn’t mean that you’ve been hit by TunnelVision, just that you’re not masked.
For those reading this and saying that this advice is untenable because you absolutely have to get work done right now and fast: stop. Your cell phone is lying to you about how fast you have to move. Emergencies are not improved by rushing, nor are fights won in a hurry.
Speed favors the bad guys in cyber. Slow and smooth favors the defender.
Second, technology:
If your VPN has a leak detection tool, turn it on and use it
Enable HTTPS by default in your browser (almost all browsers support this now, https://www.eff.org/https-everywhere)
Encrypt your internal traffic using services like Signal messenger and Pretty-good-privacy (PGP) for email encryption so that messages cannot be read without users’ encryption keys even if intercepted
Use big service providers where tenable so that you gain anonymity from the crowd as a customer
Consider using a Virtual Machine on your main, real machine and connecting to the VPN from there: that way even if your real machine is hit with TunnelVision, the traffic will be encrypted by the VPN before it reaches attackers.
Finally, some VPN-replacement technology like zero trust networking may help you—depending on how that technology interacts with your network card.
If TunnelVision is a concern to you and you need help navigating it, please don’t hesitate to reach out.