Why Your VPN May Not Be As Secure As It Claims
Why Your VPN May Not Be As Secure As It Claims
Virtual private networking (VPN) companies market their services as a way to prevent anyone from snooping on your Internet usage. But new research suggests this is a dangerous assumption when connecting to a VPN via an untrusted network, because attackers on the same network could force a target’s traffic off of the protection provided by their VPN without triggering any alerts to the user.
Use a killswitch then... no vpn, no internet
In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.
This is the only place they mention kill switch. I feel like it needs a slight clarification on whether it was enabled and didn't work, or if was just disabled and therefore not "engaged".
The Killswitch only checks that VPN is up, not whether traffic is correctly routed over it.
As I understood it, VPNs don't work in this threat model because it's essentially routing traffic through a compromised router before it ever reaches the VPN, so the VPN acts normally but there's a snooper before you ever connect to it
Huh? I thought the whole point of a VPN is to encrypt all traffic between my PC and the VPN server. Please be so kind and educate me on anything I have a misconception of:
For example, I use Safing Portmaster and I have set it up in a way where all the packets have to go through their VPN and if they don't, they get dropped before they leave my PC.
Before that I was running openvpn with a killswitch, which I thought besically did the same, it had a tunnel to the VPN server and if it is down, no packet leaves the PC.
Is that not how VPNs normally work?
I'm not saying it could not happen, but when you use VPN, the local network equipment does not determine protocols, the VPN infrastructure and it's configuration in the device do. Any local connection, including the internet gateway, just serve as the road for those packets to go out or come in.
If anyone thinks I'm wrong, please let me know, I'm not 100% certain this is the case, but it is my understanding of how VPNs work.
This won't mitigate this specific attack, however running your VPN as a full tunnel will.
Why does running the VPN in a VM mitigate the attack?
I think that mitigation requires two things for it to work.
- You need to use a a Type 2 hypervisor (like Virtualbox, VMware Workstation/Fusion).
- That VM needs to be configured in NAT mode.
The two primary ways you can configure a network for a local virtual machine are NAT and Bridged.
Bridged mode places your VM effectively on the same network as your host OS, meaning that any DHCP server that exists on your network (rogue or otherwise) will give your virtual machine and IP.
In NAT mode, the virtualization platform itself includes a DHCP server to dole out IPs, and handle the routing between your virtual machine and your host OS's network.
The thought process is that if you trust your laptop, the DHCP address handed out for NAT mode will not have the VPN breaking DHCP option and your VPN inside the VM will not have it's route table screwed with.
I need an eli5
MITIGATIONS
According to Leviathan, there are several ways to minimize the threat from rogue DHCP servers on an unsecured network. One is using a device powered by the Android operating system, which apparently ignores DHCP option 121.
Relying on a temporary wireless hotspot controlled by a cellular device you own also effectively blocks this attack.
“They create a password-locked LAN with automatic network address translation,” the researchers wrote of cellular hot-spots. “Because this network is completely controlled by the cellular device and requires a password, an attacker should not have local network access.”
Leviathan’s Moratti said another mitigation is to run your VPN from inside of a virtual machine (VM) — like Parallels, VMware or VirtualBox. VPNs run inside of a VM are not vulnerable to this attack, Moratti said, provided they are not run in “bridged mode,” which causes the VM to replicate another node on the network.
Now when I'm lazy and don't support some standards in my open source projects, I'm just going to say its for security.
Short version of this attack, it involves split routing for the tunnels. A lot of clients will have a default route-all to send traffic through the VPN. There is however a limitation to this because the tunnel itself needs a route from the local nic to connect to the VPN endpoint and establish the tunnel, otherwise you end up with a chicken and egg where you can't establish the VPN. By taking advantage of the DHCP option to set preferred routes (really anything more specific than 0.0.0.0/0) it can tell the host system to send the specified traffic through the local gateway rather than the tunnel's virtual adapter.
One relatively simple fix if you happen to have a fancy router/firewall on the edge of the network that handles the VPN would be to use policy based routing rather than relying on the underlying network configuration. Static route tables would be possible too, but in theory that could be overridden by just sending a more specific route again than what was set statically.
Well, my job better not, or they'll get a letter from their ISP about that torrenting I was actually told I could do when I asked!
I couldn't quickly find an answer to this, but would setting the "UseRoutes" option in systemd-networkd to false prevent the dhcp client from using the option 121 routes?
If so, would this be a possible mitigation for linux devices using systemd?
See also
UseGateway.