TunnelVision vulnerability: Novel attack against virtually all VPN apps neuters their entire purpose

erek

erek

[H]F Junkie
Joined
Dec 19, 2005
Messages
11,005
"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 that’s 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 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. 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 isn’t 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."


View: https://youtu.be/ajsLmZia6UU

Source: https://arstechnica.com/security/20...ly-all-vpn-apps-neuters-their-entire-purpose/
 
erek said:
"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 that’s 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 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. 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 isn’t 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."


View: https://youtu.be/ajsLmZia6UU

Source: https://arstechnica.com/security/20...ly-all-vpn-apps-neuters-their-entire-purpose/
Click to expand...

Palo Alto had me patch against this a week or so ago with a new version of the Global Protect app, and Microsoft patching against this is probably the cause of the “This update will break your VPNs” warning going about.
It’s ugly and it looks like it’s been in the wild for a long time.
 
More information on mitigation:
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.
Click to expand...
https://www.bleepingcomputer.com/ne...k-leaks-vpn-traffic-using-rogue-dhcp-servers/
 
  • Like
Reactions: erek
like this
Whalter12 said:
Mullvad VPN had an news update about this and it looks like only iOS devices were affected if you were running Mullvad.
Click to expand...
NordVPN is also immune to this attack on every platform except on iOS, because iOS is the problem. On the article from Mullvad's website, the author says this, "iOS is unfortunately vulnerable to TunnelVision, for the same reason it is vulnerable to LocalNet." Then clicking on the link referring to the reason for iOS's vulnerability, he states this:

"On iOS we sadly do not offer any Local network sharing setting and local networks are always allowed in the current versions of our app. This is stated in our feature table in the readme of our app’s source code. However, we do confess that we could have made this caveat much more discoverable and visible to users. We can definitely improve on this.

This means that the device will always send any network traffic to the local network outside the tunnel. Including public IPs advertised by rogue APs and similar.

The only solution we know against these leaks on iOS is to enable a flag called includeAllNetworks in iOS VPN terminology. We have been aware of this flag for a long time, and we have wanted to enable it for just as long. The problem is that the underlying tunnel implementation that we and most other WireGuard apps on iOS use, wireguard-go, is simply not compatible with includeAllNetworks. We are currently replacing wireguard-go with something allowing us to enable this security feature. We actually have been working on this for quite some time. But it is a pretty large task and we are not there yet."

Meh.
 
Shoganai said:
NordVPN is also immune to this attack on every platform except on iOS, because iOS is the problem. On the article from Mullvad's website, the author says this, "iOS is unfortunately vulnerable to TunnelVision, for the same reason it is vulnerable to LocalNet." Then clicking on the link referring to the reason for iOS's vulnerability, he states this:

"On iOS we sadly do not offer any Local network sharing setting and local networks are always allowed in the current versions of our app. This is stated in our feature table in the readme of our app’s source code. However, we do confess that we could have made this caveat much more discoverable and visible to users. We can definitely improve on this.

This means that the device will always send any network traffic to the local network outside the tunnel. Including public IPs advertised by rogue APs and similar.

The only solution we know against these leaks on iOS is to enable a flag called includeAllNetworks in iOS VPN terminology. We have been aware of this flag for a long time, and we have wanted to enable it for just as long. The problem is that the underlying tunnel implementation that we and most other WireGuard apps on iOS use, wireguard-go, is simply not compatible with includeAllNetworks. We are currently replacing wireguard-go with something allowing us to enable this security feature. We actually have been working on this for quite some time. But it is a pretty large task and we are not there yet."

Meh.
Click to expand...
So Apple adds the flags to fix the issue in iOS13, but the wireguard-go fork that they are reskinning doesn’t support it so it’s Apples fault?
 
This is another attack that requires the attacker to have access to the victim's local network. Why do the always have to do this? Make you shit your pants and then you have to read 3/4th through the article to realize it is not as bad as they made it sound.
 
M76 said:
This is another attack that requires the attacker to have access to the victim's local network. Why do the always have to do this? Make you shit your pants and then you have to read 3/4th through the article to realize it is not as bad as they made it sound.
Click to expand...
That's how they get clicks. Clearly working as intended ;)
 
I really have a problem with this being called an attack. It is just basic routing working the way it is intended to work. More specific routes always take precedence over less specific routes and anyone that knows anything about networking knows this or at least should. Can this knowledge be used maliciously? Sure, so can water and air ... The fact that vpn providers are acting as if they were unaware of this is laughable. I have a bigger issue with an OS choosing to ignore DHCP options. I'll add that there is at least one ISP that uses or at least has used, no idea if they still do today, option 121 as part of their service.
 
Last edited:
Lakados said:
So Apple adds the flags to fix the issue in iOS13, but the wireguard-go fork that they are reskinning doesn’t support it so it’s Apples fault?
Click to expand...
It's not entirely Apple's fault. But when iOS is the only OS that has an issue without VPN companies changing their framework, yes. There's also a bug in iOS that hasn't been fixed in years (and still isn't fixed, as far as I'm aware):

"There are three distinct issues affecting VPNs on iOS. They are:
1. Network connections that were active before turning the VPN on may not close and remain outside of the VPN.
2. Third-party applications may obtain the actual IP address of your mobile network and bypass the VPN.
3. Apple traffic, such as push notifications, App Store traffic, and even Health app data, completely bypasses the VPN."

https://www.comparitech.com/blog/vpn-privacy/vpn-ios-bug-privacy/

Don't be an Apple apologist. There's definitely ongoing issues with VPNs on iOS.
 
Shoganai said:
It's not entirely Apple's fault. But when iOS is the only OS that has an issue without VPN companies changing their framework, yes. There's also a bug in iOS that hasn't been fixed in years (and still isn't fixed, as far as I'm aware):

"There are three distinct issues affecting VPNs on iOS. They are:
1. Network connections that were active before turning the VPN on may not close and remain outside of the VPN.
2. Third-party applications may obtain the actual IP address of your mobile network and bypass the VPN.
3. Apple traffic, such as push notifications, App Store traffic, and even Health app data, completely bypasses the VPN."

https://www.comparitech.com/blog/vpn-privacy/vpn-ios-bug-privacy/

Don't be an Apple apologist. There's definitely ongoing issues with VPNs on iOS.
Click to expand...
But isn’t that exactly what the allnetworks flag does. Because implementing it requires you to kill all active network sessions before the flag will successfully enable which is easiest done by enabling airplane mode, enabling the allnetworks switch, then disabling airplane mode. Which should then rebuild all connections through the VPN tunnel, not sure about air drop you might need to create a specific function to disable that while the VPN is working though.
 
Lakados said:
But isn’t that exactly what the allnetworks flag does. Because implementing it requires you to kill all active network sessions before the flag will successfully enable which is easiest done by enabling airplane mode, enabling the allnetworks switch, then disabling airplane mode. Which should then rebuild all connections through the VPN tunnel, not sure about air drop you might need to create a specific function to disable that while the VPN is working though.
Click to expand...
That's what it's supposed to do, and if VPN companies aren't using this method by now, they're stupid. The other issue, however, still needs to be addressed by Apple.
 
M76 said:
This is another attack that requires the attacker to have access to the victim's local network. Why do the always have to do this? Make you shit your pants and then you have to read 3/4th through the article to realize it is not as bad as they made it sound.
Click to expand...
Or any public wifi or open network. I could go to a starbucks, connect to their wifi and run a DHCP server and exploit this, pending on how they have their wifi network set up and if secure (not likely)
 
You must log in or register to reply here.
Back
Top