Original posting by Feisty Duck: Feisty Duck: VPNs Still Don’t Work, which based their Newsletter from TunnelCrack.
The Feisty Duck reiterates TunnelCrack’s conclusions so I’ll try to articulate the two vulnerabilities/attack vectors identified by TunnelCrack. The first attack dubbed “LocalNet Attack” is where the malicious actor clones a WiFi hotspot, which are commonly available in public spaces, like the WiFi at StarBucks. The user, thinking that this is owned and operated by the establishment, foolishly connects to it, where the hacker assigns an IP address from their private pool. The malicious actor can then exploit the vulnerability because VPNs are notorious for permitting LAN address communication. When the user tries to connect with a site, the malicious actor injects or monitors web traffic between its unsuspecting user and a legitimate site.
The second attack, dubbed “ServerIP Attack,” is a little more complex, but the principle is the same; “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 1.2.3.4, is sent outside the VPN tunnel.” And because VPNs don’t re-encrypt traffic between the user and its VPN server, the user connects to an unsafe point, which leaks information.
The TunnelCrack team did testing for a broad set of VPN clients and platforms, and they discovered that Apple users are most susceptible, whereas other platforms and VPN clients did better; Android, after version 12, is least affected.
The reason why Feisty Duck posted about these attacks is because they’re a good source for SSL/TLS configuration. Feisty Duck concludes that when a “combination of TLS, valid certificates, and HTTP Strict Transport Security” are implemented, users are far better protected from these exploits. It’s easy to spoof DNS and masquerade as a legitimate server until TLS is properly vetted since most 3rd Parties, like Verisign and GoDaddy, protect their private keys like Crown Jewels.
I did notice that from the TunnelCrack post that VPNs are also susceptible since, like in OpenVPN, the host configuration keyword is often accompanied by a DNS hostname, which can easily be spoofed.
One thing that I didn’t see in these blog posts/newletters was mention of DNSSEC, but I guess, DNS — when it performs a forward lookup — may not be running the gauntlet to validate that the DNS reply is using properly configured DNSSEC; it’s probably less likely.
Continue reading VPNs Still Don’t Work – Week 2