New attack leaks VPN traffic using rogue DHCP servers


A new attack dubbed “TunnelVision” can route traffic outside a VPN’s encryption tunnel, allowing attackers to snoop on unencrypted traffic while maintaining the appearance of a secure VPN connection.

The method, described in detail in a report by Leviathan Security, relies on the abuse of Dynamic Host Configuration Protocol’s (DHCP) option 121, which permits the configuration of classless static routes on a client’s system.

The attackers set up a rogue DHCP server that alters the routing tables so that all VPN traffic is sent straight to the local network or a malicious gateway, never entering the encrypted VPN tunnel.

“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,” reads the report.

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

Exploitation process
Exploitation process
Source: Leviathan

The issue lies in DHCP’s lack of an authentication mechanism for incoming messages that could manipulate routes, and was assigned the vulnerability identifier CVE-2024-3661.

The security researchers note that this vulnerability has been available for exploitation by bad actors since at least 2002, but there are no known cases of active exploitation in the wild.

Leviathan has informed many of the impacted vendors, as well as CISA and the EFF. The researchers have now publicly disclosed the issue along with a proof-of-concept exploit to raise awareness and compel VPN vendors to implement protection measures.

Mitigating TunnelVision attacks

Users are more apt to be impacted by “TunnelVision” attacks if they connect their device to a network that is either controlled by the attacker or where the attacker has a presence. Possible scenarios would include public Wi-Fi networks like those in coffee shops, hotels, or airports.

The VPN on the targeted device must be susceptible to routing manipulation, which Leviathan says is typically the case with most VPN clients that use system-level routing rules without anti-leak safeguards.

Finally, automatic DHCP configuration on the target device needs to be enabled, for the malicious DHCP configuration to be applied during network connection. This is, again, a commonly seen configuration.

However, it should be noted that for this attack to work, a user must connect to the rogue DHCP server before the network’s legitimate one.

The researchers say attackers can increase the chance their rogue servers will be accessed first in multiple ways, including DHCP starvation attacks against the legitimate server and ARP spoofing.

The TunnelVision CVE-2024-3661 flaw impacts Windows, Linux, macOS, and iOS. Due to Android not having support for DHCP option 121, it is the only major operating system not impacted by TunnelVision attacks.

Leviathan proposes the following mitigations for VPN users:

  • Use network namespaces on Linux to isolate network interfaces and routing tables from the rest of the system, preventing rogue DHCP configurations from affecting VPN traffic.
  • Configure VPN clients to deny all inbound and outbound traffic that does not use the VPN interface. Exceptions should be limited to necessary DHCP and VPN server communications.
  • Configure systems to ignore DHCP option 121 while connected to a VPN. This can prevent malicious routing instructions from being applied, though it might disrupt network connectivity under certain configurations.
  • Connect via personal hot spots or within virtual machines (VM). This isolates the DHCP interaction from the host system’s primary network interface, reducing the risk of rogue DHCP configurations.
  • Avoid connecting to untrusted networks, especially when handling sensitive data, as these are prime environments for such attacks.

As for VPN providers, they are encouraged to enhance their client software to implement their own DHCP handlers or integrate additional security checks that would block applying risky DHCP configurations.



Source link