This morning I read an article with the headline, “Novel attack against virtually all VPN apps neuters their entire purpose.” This seemed really alarming and, to be sure, the details are pretty bad. But as I read through the article I was thinking about what I expect from a VPN, and how the attack would affect those expectations, and, maybe I’ve been thinking about VPNs wrong all this time?
First, the vulnerability: let’s take for an example you’ve got your laptop and you’re connecting to a café’s wireless network. There’s a device on the network, a DHCP server, that issues your laptop a local address and tells your laptop how to send traffic out to the wider world. So, the laptop joins the network and learns how to talk to the wider world, and then you fire up your VPN software and it tells your laptop, “Okay, great, thanks for letting me talk to the wider world. Now, whenever any program on this laptop wants to talk to anything that isn’t on this laptop, send the network traffic to me and I’ll deal with it from there.” The vulnerability is that there’s an option on the DHCP server that nobody uses, but which allows the DHCP server to tell the laptop, “Okay, so, the wider world exists, and here’s how to talk to it: ignore anything that programs you’re running may want to do, and just send everything to me.” The effect is, the VPN software on the laptop thinks it’s working just fine, but when you open your web browser and go to your bank’s website, the request doesn’t go through the VPN, it goes around the VPN software and out to the world as if you weren’t even running a VPN client.
Now, that’s bad, right? Like, the whole point of a VPN is that…wait a second. So what this means, really, is that the person who set up the network can, effectively, disable VPN clients on that network. Okay, yeah, that’s rotten. But here’s my confusion, right, about what this really is about. I learned about VPNs in the context of working remotely. I used a VPN client to connect to my employer’s network and then access resources that were only available on the corporate LAN – file servers and the like. The way that worked was, my laptop would make requests but all those requests would be forwarded to a computer on the corporate network and it would act as a proxy, sending on the requests and forwarding the responses back to my computer. In this café scenario, when I try to go to the corporate file server to access my project’s progress spreadsheet, the request would not go through the VPN client and the café’s DHCP server has no idea what the address of the file server is (because it’s not on the public Internet), so I’d just see a spinning cursor and never be able to do anything.
So the vulnerability can’t be about that, since that is immediately obvious, especially because the VPN client on my laptop thinks I’m connected to the corporate network. So it must be about something else. Now, one thing that was always a little annoying about working remotely this way was that all traffic got routed through the VPN. This meant that all my web browsing would have to go from my laptop over to the corporate VPN endpoint, and then out to the world. This meant extra time for each request, and as a side effect meant that the company’s IT department could see what sites I was looking at. Not that they or I cared, but still.
Since I’ve retired, I don’t use a VPN for that stuff any more. And since I don’t like to role play as a system administrator or network technician, I don’t have always-on servers on our home network; the closest thing is the laser printer, and why would I want to make it spit out a sheet of paper when I’m halfway around the world? Who would pick it up? Now, my use case for a VPN is to make the remote service I’m connecting to think that I’m in a particular location. When we took that cruise last year, we found that not only did the Submittable website not work for us from the ship’s plain network, but that even when we were in port and using some café hotspot we had to use a VPN. (I suspect, but never bothered to prove, that was because some part of Submittable does geofencing, probably for CDN affinity or something.) Again, though, this use case is one in which it becomes glaringly obvious if the VPN isn’t being used to route requests because, again, the whole point of the VPN here is that the requests fail when they don’t use it.
So, back to the vulnerability. One aspect of the attack that gets called out is that the VPN client doesn’t know that it’s not working. So your laptop will still display the “you’re protected” icon or whatever. And if you’re using a VPN for stuff that won’t fail when you don’t use the VPN, then you’re using it to…um… Okay, I can imagine a scenario: you’re a person living in a place where the local government wants to exert tight control over what websites you can and can’t go to. Using a VPN, you could route all your traffic to a local VPN server and all your requests would be encrypted and so the local government wouldn’t even know what sites you were visiting. This attack would mean that the requests would not be encrypted and conceivably, you could get in trouble. So that’s bad. But this is so far away from my own threat model that it took actually writing this down to get it in my forebrain.
So. The headline is right, because this attack allows a local network administrator to disable VPN clients running on the local network. A side effect of the attack is that the VPN clients don’t know that they’re not working. And requests that will work without going through a VPN will continue to work, and you’ll think that the requests did go through the VPN even though they didn’t. But requests that require using the VPN in order to work will not work.