We discovered a fundamental design problem in VPNs and we're calling it TunnelVision. This problem lets someone see what you're doing online, even if you think you're safely using a VPN.
The attacker needs to have access to your LAN and become the DHCP server, e.g. by a starvation attack or timing attacks
The attacked host system needs to support DHCP option 121 (atm basically every OS except Android)
by abusing DHCP option 121, the attacker can push routes to the attacked host system that supersede other rules in most network stacks by having a more specific prefix, e.g. a 192.168.1.1/32 will supersede 0.0.0.0/0
The attacker can now force the attacked host system to route the traffic intended for a VPN virtual network interface (to be encrypted and forwarded to the VPN server) to the (physical) interface used for DHCP
This leads to traffic intended to be sent over the VPN to not get encrypted and being sent outside the tunnel.
This attack can be used before or after a VPN connection is established
Since the VPN tunnel is still established, any implemented kill switch doesn’t get triggered
DHCP option 121 is still used for a reason, especially in business networks. At least on Linux, using network namespaces will fix this. Firewall mitigations can also work, but create other (very theoretical) attack surfaces.
Interesting read.
So, in short:
DHCP option 121 is still used for a reason, especially in business networks. At least on Linux, using network namespaces will fix this. Firewall mitigations can also work, but create other (very theoretical) attack surfaces.