VPN BUSTER — Novel attack against virtually all VPN apps neuters their entire purpose TunnelVision vulnerability has existed since 2002 and may already be known to attackers.
Dan Goodin – May 6, 2024 8:35 pm UTC EnlargeGetty Images reader comments 150
Researchers have devised an attack against nearly all virtual private network applications that forces them to send and receive some or all traffic outside of the encrypted tunnel designed to protect it from snooping or tampering.
TunnelVision, as the researchers have named their attack, largely negates the entire purpose and selling point of VPNs, which is to encapsulate incoming and outgoing Internet traffic in an encrypted tunnel and to cloak the users IP address. The researchers believe it affects all VPN applications when theyre connected to a hostile network and that there are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android. They also said their attack technique may have been possible since 2002 and may already have been discovered and used in the wild since then. Reading, dropping, or modifying VPN traffic
The effect of TunnelVision is the victim’s traffic is now decloaked and being routed through the attacker directly, a video demonstration explained. The attacker can read, drop or modify the leaked traffic and the victim maintains their connection to both the VPN and the Internet. TunnelVision – CVE-2024-3661 – Decloaking Full and Split Tunnel VPNs – Leviathan Security Group.
The attack works by manipulating the DHCP server that allocates IP addresses to devices trying to connect to the local network. A setting known as option 121allows the DHCP server to override default routing rules that send VPN traffic through a local IP address that initiates the encrypted tunnel. By using option 121 to route VPN traffic through the DHCP server, the attack diverts the data to the DHCP server itself. Researchers from Leviathan Security explained: Advertisement Our technique is to run a DHCP server on the same network as a targeted VPN user and to also set our DHCP configuration to use itself as a gateway. When the traffic hits our gateway, we use traffic forwarding rules on the DHCP server to pass traffic through to a legitimate gateway while we snoop on it.
We use DHCP option 121 to set a route on the VPN users routing table. The route we set is arbitrary and we can also set multiple routes if needed. By pushing routes that are more specific than a /0 CIDR range that most VPNs use, we can make routing rules that have a higher priority than the routes for the virtual interface the VPN creates. We can set multiple /1 routes to recreate the 0.0.0.0/0 all traffic rule set by most VPNs.
Pushing a route also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface. This is intended functionality that isnt clearly stated in the RFC. Therefore, for the routes we push, it is never encrypted by the VPNs virtual interface but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface talking to our DHCP server. Enlarge / A malicious DHCP option 121 route that causes traffic to never be encrypted by the VPN process.Leviathan Security
We now have traffic being transmitted outside the VPNs encrypted tunnel. This technique can also be used against an already established VPN connection once the VPN users host needs to renew a lease from our DHCP server. We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.
The attack can most effectively be carried out by a person who has administrative control over the network the target is connecting to. In that scenario, the attacker configures the DHCP server to use option 121. Its also possible for people who can connect to the network as an unprivileged user to perform the attack by setting up their own rogue DHCP server. Advertisement
The attack allows some or all traffic to be routed through the unencrypted tunnel. In either case, the VPN application will report that all data is being sent through the protected connection. Any traffic thats diverted away from this tunnel will not be encrypted by the VPN and the Internet IP address viewable by the remote user will belong to the network the VPN user is connected to, rather than one designated by the VPN app.
Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn’t implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux theres a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks. Network firewalls can also be configured to deny inbound and outbound traffic to and from the physical interface. This remedy is problematic for two reasons: (1) a VPN user connecting to an untrusted network has no ability to control the firewall and (2) it opens the same side channel present with the Linux mitigation.
The most effective fixes are to run the VPN inside of a virtual machine whose network adapter isnt in bridged mode or to connect the VPN to the Internet through the Wi-Fi network of a cellular device. The research, from Leviathan Security researchers Lizzie Moratti and Dani Cronce, is available here. reader comments 150 Dan Goodin Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Advertisement Promoted Comments mktogeek I think it’s important to clarify the use of the term "VPN" here. This affects "VPNs" used for anonymizing internet traffic or for geofence defeating on streaming services and such. It should not impact VPNs used to access private networks via the Internet.
For example, if you use a VPN to connect to your home network and access machines inside your LAN that are not directly exposed to the internet, this won’t affect that at all. It only affects VPN setups that redirect all Internet traffic via the VPN.
You may also be able to partially defeat it by not using a /0 route. You could instead do four routing entries with /2 networks. Of course, if the hacker sets up their network the same way, this could also be defeated. May 6, 2024 at 8:59 pm Channel Ars Technica ← Previous story Next story → Related Stories Today on Ars
