We present two widespread design flaws in VPN client. These can be abused to make a victim leak traffic in plaintext outside the protected VPN tunnel.

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.

  • jmp242@sopuli.xyzEnglish
    1·
    1 year ago

    I think both attacks are actually DNS vulnerabilities from my reading of the paper which is now available. It has nothing whatsoever to do with VPNs, except in so far as you can abuse DNS to redirect traffic to a hostname somewhere else. I suppose the first attack does suggest that commercial VPN companies should update their configuration to require the non-routed IPs to be the local network unless otherwise overridden by the customer. That should completely kill the first attack from what I can tell. Customers can also just look at their route tables after connecting to a random wifi and see if it looks weird (the local net not being 192.168.0.0/24, 172.16-20.0.0/16[IIRC, google the range],10.0.0.0/8)…

    The second attack still requires the attacker to control DNS, so again, is basically either the ISP or a rogue AP. I still think DNSSEC helps, DoH would help (but OSs don’t use this, and generally for good reason - we really really need PKI for DNS as the new standard IMHO, which I think DoH is trying to do), but also hardcoding the DNS server you use to a known good server (this might be hard, but like 1.1.1.1 is going to be harder to intercept) would stop it.

    This is also why people say VPN doesn’t provide full security on it’s own (Though I question the ability to pull these attacks off in most practical situations - quite a lot depends on your threat model) and redirecting HTTPS traffic for instance outside the VPN leaks that you connected to that site, but none of the contents of the traffic.