CyberClub

A massive security hole in virtual private networks (VPNs) reported this week highlights the fact that they were never intended to fulfill a security function despite widespread use as a defensive feature, according to security experts.

The VPN security hole vulnerability, which can neither be patched nor meaningfully negated, was reported in a blog post by the Leviathan Security Group. The researchers outline a methodology dubbed TunnelVision that attackers can use to divert data within the VPN to a place where it can be read in clear text. 

What makes the hole more dangerous is that the VPN software would likely have no way of knowing that its contents have been rerouted, thereby preventing the system from alerting anyone that there has been an attack.

Given that a VPN is solely an encrypted tunnel and provides no security on either end, they are a popular means for attackers to backdoor an environment. Malware planted on the machine of any VPN user can piggyback on an infected file and safely ride the VPN to the enterprise’s broader network.

“VPNs aren’t necessarily security tools. It’s a connectivity tool” that IT departments have “bolted on and tried to patch things up,” said Dani Cronce, a senior security consultant at Leviathan and one of the report’s authors.  “Think of it as a perception issue, with some marketing around it.”

VPNs over-credited as security tools

Many executives have historically credited VPNs with far more security capabilities than they merit, said Brian Levine, an Ernst & Young managing partner overseeing cybersecurity. “This changes little because it has never been sufficient to rely on a VPN alone for security, which requires defense in depth,” Levine said.

“Among other things, traffic should be appropriately encrypted prior to even entering a VPN. All technology has vulnerabilities. The mere fact that a tool has a particular vulnerability doesn’t mean it can’t be helpful in a robust defense in depth strategy,” he said.

Noah Beddome, Leviathan’s CISO in residence, said that CISOs need to remember the origin of VPNs. “VPN was never supposed to be a security solution — VPNs were never designed for that,” he said.

“They were a stopgap use at the time [they were created]. Still, almost all enterprises have so many VPNs in use that there is no easy replacement,” Beddome said, adding that it’s likely that underfunded and understaffed security operations may have made it more difficult to replace VPNs quickly.

How TunnelVision intercepts VPN traffic

According to the researchers, TunnelVision is a secondary attack, meaning that it only works if the attacker has already gained significant access to the network. The danger is that some IT and security staffers might think that the VPN would still protect its data even if the environment is compromised. According to testing performed by Leviathan, no such protection would exist in a standard VPN.

The attack “bypasses VPN encapsulation. An attacker can use this technique to force a target user’s traffic off their VPN tunnel using built-in features of DHCP (Dynamic Host Configuration Protocol),” Leviathan researchers wrote. “The result of this is the user transmits packets that are never encrypted by a VPN, and an attacker can snoop their traffic. We are using the term ‘decloaking’ to refer to this effect. Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.”

The key to the attack lies in the manipulation of DHCP option 121, according to Leviathan’s research.

“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 user’s routing table. The route we set is arbitrary and we can also set multiple routes if needed,” the researchers wrote.

“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.”

Using this tactic, network traffic can be sent over the same interface as the DHCP server instead of the virtual network interface, a functionality not clearly stated in the RFC.

“Therefore, for the routes we push, it is never encrypted by the VPN’s 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.”

The attack can avoid detection by the VPN

The attack’s ability to avoid detection is perhaps the most problematic element. Leviathan pointed out that during such an attack, “the VPN user shows as being connected to the VPN. Attackers can control which IPs they wish to decloak, so theoretically they could choose to not decloak leak-checking IPs.”

The Leviathan team found it could leak DNS IPs while forwarding traffic, keeping a VPN connection intact while obtaining information about the traffic in the tunnel. “In no circumstances did we observe a VPN server disconnecting us with kill switches or other features.”

Another problematic feature of this attack is that VPNs are often used in locations such as coffee shops, airports, medical facilities, and other locations where WiFi security protections are typically weak or nonexistent.

In a Q-and-A published on a separate Leviathan site, the company noted that while most networks have widespread adoption of DHCP snooping or other protections, “most people using VPNs are not connecting from an enterprise network. They are connecting from public networks or their home networks. In addition, part of the VPN provider threat model is they can secure any untrusted network, including those who do not have these protections.”

Minimizing the risk of TunnelVision

Although there is a no patch or fix for the security hole, there are a few ways to minimize the damage. Companies can ensure all data is encrypted before entering a VPN, which sidesteps the issue as attackers might still be able to learn the data’s destination and who is sending it, but at least the data itself should be protected. In a zero-trust environment, such encryption would be the default choice

The attack worked in all operating systems other than Android, Leviathan said. But Android has other security limitations, Beddome said, so encouraging a shift for mobile users to Android is not a recommended move.

Other ways to avoid the problem deliver unwanted security side effects, the company said. “We’ve seen one mitigation for this technique, as well as identified a fix that exists on Linux-based operating systems.” The blog said. “However, the mitigation offers a side channel that could be used for targeted denial-of-service censorship, as well as to de-anonymize the destination of traffic via traffic analysis.

Attempting to fix the issue by simply removing support for the DHCP feature could break internet connectivity in some legitimate cases, the report said. Leviathan said its strongest recommendation is for VPN providers to implement network namespaces, a Linux feature that can segment interfaces and routing tables away from the local network’s control, where they are supported.

Another tactic is to avoid unknown WiFi and use hotspots, along with a travel router, said Lizzie Moratti, a security consultant at Leviathan and another of the report’s authors.

Beddome added that it’s helpful to look for WiFi that delivers host isolation “so you have a subnet just for yourself.  Travel networks — especially hotels — don’t usually do host isolation.”