What are TunnelCrack vulnerabilities?
- Two widespread security vulnerabilities in VPNs can be abused by an adversary to leak traffic outside the VPN tunnel.
- The two vulnerabilities are called the LocalNet and ServerIP attack.
Summary of what VPNs are vulnerable to TunnelCrack
- VPNs for iPhones, iPads, MacBooks, and macOS are extremely likely to be vulnerable
- A majority of VPNs on Windows and Linux are vulnerable
- Android is the most secure with roughly one-quarter of VPN apps being vulnerable.
- Users generally decide which VPN protocol to adopt while creating the VPN tunnel, with common options being OpenVPN, WireGuard, or IPsec. As a result, the precise configuration of the client, and whether it is vulnerable to (variants of) our attacks, may depend on the chosen VPN server and protocol.
TunnelCrack Prevention
To prevent the attack, VPN clients should be updated to send all traffic through the VPN tunnel, except traffic generated by the VPN app itself.
How do the LocalNet and ServerIP attacks work?
LocalNet attack:
-
The adversary acts as a malicious Wi-Fi or Ethernet network and tricks the victim into connecting to it.
-
Once connected, the adversary assigns a public IP address and subnet to the victim.
-
The adversary then tells the victim that the local network is using this subnet, which means that IP addresses in this range are directly reachable in the local network. When the victim now visits a website with an IP address in this range, the web request will be sent outside the protected VPN tunnel.
-
66+ VPNs on five platforms were tested and found that all VPN apps on iOS are vulnerable. Additionally, all but one VPN client on macOS is vulnerable, on Windows a large majority of VPNs are vulnerable, and on Linux more than one-third are vulnerable. Interestingly, VPN apps on Android are typically the most secure, with one-quarter being vulnerable to the LocalNet attack.
ServerIP attack:
-
The adversary abuses the observation that many VPNs don’t encrypt traffic towards the IP address of the VPN server. This is done to avoid re-encryption of packets.
-
The adversary first spoofs the DNS reply for the VPN server to return the IP address of a website that they control. The victim will then connect with the VPN server at this IP address.
-
To assure the victim still successfully creates a VPN connection, the adversary redirects this traffic to the real VPN server.
-
While establishing the VPN connection, the victim will add a routing rule so that all traffic to the VPN server, in this case the spoofed IP address, is sent outside the VPN tunnel. When the victim now visits a website with the IP address of the VPN server, the web request is sent outside the protected VPN tunnel.
-
Built-in VPN clients of Windows, macOS, and iOS are vulnerable. Android 12 and higher is not affected. A significant number of Linux VPNs are also vulnerable.
Am I the only person that goes straight to whatismyip when they connect over their VPN?
This doesn’t seem like a problem with VPN software intrinsically, maybe they could have a configurable limited prefix length with a sensible default and maybe a default setting that will warn/fail if an RFC1918 with an in-scope prefix is not used on all the LAN interfaces active. But again it’s generally a combination of user security configuration and opsec (checking they really are connected) that is the problem I think.
I don’t see how that would help, you’re still connecting to your actual VPN under this attack. Your IP would report correctly.
Well, as I’m understanding their first exploit. That is setting up a fake access point with a very large subnet mask. E.g. 192.168.178.124/1 (128.0.0.0). I think that’s the largest you can do, I doubt IP stacks will let you set an interface mask of /0. That would put half of the IPv4 address space onto the LAN. They can then have that device transparant proxy for ALL addresses in that address space onto the actual internet, but logging anything of interest.
But, provided the whatismyip site is in that block (it’s 50/50 I guess) it would not be showing the VPN address.
I think the overall message here is when you’re on a network you’re not familiar with (or even if you are, they could be spoofing a known SSID) always be checking things.
Also, yes VPN software could be looking out for suspicious network configurations too.
At the last place I worked, our field agents had to use a VPN to transmit sensitive data back to the office multiple times per day from different locations. These were mostly not technical users. It’s very important that the VPN correctly hide information that is being sent to the office servers from whatever dodgy access point they might have connected to (or detect the attack on its own and refuse to connect), and we can’t rely on them to perform any extraneous checks. They’re under enough stress doing their own job; every added IT hurdle makes it harder for them. This is exactly the kind of situation where this attack is most dangerous.
Maybe I should text this link to my old boss.
This may not be strictly related to the use case you described but I think it’s kind of cool…
On Linux you can add the software used to do the upload to a group “vpnroute” or similar, and use iptables to block all traffic from that group that isn’t sent through the VPN tunnel. Something like this:
Obviously needs to be made persistent which I do with UFW in /etc/ufw/after.rules. It makes for a good kill switch.
Good tip, thanks!
Always check for leaks
Well, the issue is that the main exploit they’re using (I’ve not read the second one yet) is because of how most people would want a VPN to work. Route anything inside the LAN direct via the implied route, and the rest over the VPN.
Sure for ultra security you would want to limit that. But it has a trade-off too. Local resources become unavailable too. In most cases people will want their NAS mounts, and other local resources to still work.
I don’t think the VPN software can or should know what is legitimate LAN traffic and what should be secure internet traffic. But making configurable rules with sensible defaults would certainly be able to limit any weakness this produces. And yes, consumer targeted VPN software should probably have a maximum security option which locks out the LAN interface except for packets to the VPN server. I have a VM configured to connect to a VPN and it works like this. In fact it has two states. State 1: VPN not connected, LAN accessible, Internet not. State 2: VPN Connected, LAN inaccessible, Internet accessible.
Beyond that, the user needs to take some level of responsibility too.
Additionally, it seems to me like you could bind the app that needs to use the VPN to the VPN adapter/interface specifically, preventing it from going out the wrong route.
That’s quite a good idea. But, most apps aren’t really VPN aware. Usually for incoming you might be able to choose an interface (either by interface name, or by the IP on the adapter). But for outgoing, they will just follow the routing table. It would make apps more difficult to use.
It’s interesting this is an exploit. Because I’ve had problems with configuring a VPN that involved wider LAN subnets before. But I never considered it would be specifically used as an attack vector.
https://github.com/Safing/portmaster
You could use something like portmaster to configure your app to either must use the VPN or can use the normal network.
Rather than binding to the VPN interface you can just use the firewall to block traffic from any sensitive apps that doesn’t go out on that interface. If the VPN goes down the traffic gets dropped. I posted an example elsewhere in the thread.