(…) 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 user’s IP address.
No. That is not the entire point of a VPN. That’s just what a few shady companies are claiming to scam uninformed users into paying for a useless service. The entire point of a VPN is to join a private network (i.e. a network that is not part of the Internet) over the public internet, such as connecting to your company network from home. Hence the name ‘virtual private network’.
There are very little, if any, benefits to using a VPN service to browse the public internet.
that works, but a regular SOCKS proxy should do. for HTTP even a HTTP proxy. many VPN providers offer them too, btw.. may help with mitigating this attack vector.
I use option 121 as part of my work, though I am not an expert on DHCP. This attack does make sense to me and it would be hard to work around given the legitimate uses for that option.
Adding routes for other thing on the network the clients can reach directly and remove some load from the router. For example, reaching another office location through a tunnel, you can add a route to 10.2.0.0/16 via 10.1.0.4 and the clients will direct the traffic directly at the appropriate gateway.
Arguably one should design the network such that this is not necessary but it's useful.
To be fair, any proper VPN setup that only relies on the routing table like this is flawed to begin with.
If the VPN program dies or the network interface disappears, the routes are removed aswell, allowing traffic to leave the machine without the VPN.
So it is already a good practice to block traffic where it shouldnt go (or even better, only allowing it where it should).
No. Any device that implements a certain DHCP feature is vulnerable. Linux doesn't support it, because most Linux systems don't even use DHCP at all let alone this edge case feature. And Android doesn't support it because it inherited the Linux network stack.
I would bet some Linux systems are vulnerable, just not with the standard network packages installed. If you're issued a Linux laptop for work, wouldn't be surprised if it has a package that enables this feature. It essentially gives sysadmins more control over how packets are routed for every computer on the LAN.
WTF are you smoking? WTF is wrong with you that you think such a dumb claim would go unscrutinized? I would play Russian roulette on the chances of a random Linux installation on a random network talking DHCP.
Edit, in case being charitable helps: DNS and IP address allocation aren't the only things that happen over DHCP. And even then the odds are overwhelming that those are being broadcast that way.
So if they are changing routes by using DHCP options, perhaps this could be exploited by telecom insiders when you are using mobile data, because your mobile data IP could be assigned by a DHCP server on the telecom network. If you're at home on wifi, then you can control your own DHCP server to prevent that.
The attack vector described in the article uses the VPN client machine's host network, i.e. the local network the device is attached to. They don't discuss the DHCP server of the VPN provider.
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.
Most traffic gets sent through a VPN only because of a default gateway (set by the VPN) in the client's routing table. If the client's ISP were to have their DHCP server set one or more specific routes that are broad enough to cover most of the global address space, they would effectively override that default gateway. I believe that's the scenario described in the article.
Note that the "ISP" here could be a mobile operator, an internet cafe, an airport, someone running a wifi access point that looks like the airport's, or a guest on the same local network running an unauthorized DHCP server.
Most VPN providers don't use DHCP. OpenVPN emulates and hooks DHCP requests client-side to hand the OS the IP it got over the OpenVPN protocol in a more standard way (unless you use Layer 2 tunnels which VPN providers don't because it's useless for that use case). WireGuard doesn't support DHCP at all and it always comes from configuration.
The attack vector here seems to be public WiFi like coffee shops, airports, hotels and whatnot. The places you kinda do want to use a VPN.
On those, if they're not configured well such as coffee shops using consumer grade WiFi routers, an attacker on the same WiFi can respond to the DHCP request faster than the router or do an ARP spoof attack. The attacker can proxy the DHCP request to make sure you get a valid IP but add extra routes on top.
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 user’s IP address.
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 121 allows the DHCP server to override default routing rules that send VPN traffic through a local IP address that initiates the encrypted tunnel.
When apps run on Linux there’s 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.
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 original article contains 903 words, the summary contains 196 words. Saved 78%. I'm a bot and I'm open source!
