TunnelVision vulnerability. Any best practice staff can suggest?

[tranquivox69 27]

https://www.leviathansecurity.com/blog/tunnelvision


Apparently this affects both OpenVPN and WireGuard protocols.

Technically it's not a vulnerability but it was easier for the title...

[Staff 10015]

24 minutes ago, tranquivox69 said:

https://www.leviathansecurity.com/blog/tunnelvision


Apparently this affects both OpenVPN and WireGuard protocols.

Hello!

As reported in the very informative and well written article, provided that unfortunately the adversary has the ability to crack your local network and install inside it an evil DHCP server, an excellent mitigation is based on firewall rules exactly as they are enforced by AirVPN's Network Lock.

Kill switches are ineffective as usual, nothing new here, but Network Lock greatly mitigates the problem. This mitigation is very hard to circumvent, as it would require traffic analysis first and more operations later (check "Problems with Firewall Rule Mitigations" in the article). Please note that traffic splitting MUST be avoided, otherwise firewall rules of Network Lock will have exceptions which can be in themselves a dangerous enlargement of the surface attack and that can be again exploited by TunnelVision.
 

Quote

To determine the traffic’s destination, an attacker could perform traffic analysis on the volume of VPN encrypted traffic a user sends. The attacker would need a baseline volume of traffic where no malicious are installed. Then the attacker would need to modify the lease configuration to install routes that deny traffic and observe the difference in volume.

As a double protection, you may consider to disable DHCP option 121, an option which can be reported even as “Disable Classless Static Route”. Without DHCP option 121 the attack lacks its essential pre-requisite. Check the downsides, though.

We will have the paper investigated by independent reviewers in the next days and if anything relevant on top of all of the above comes out we will publish it.

Kind regards
 

[tranquivox69 27]

2 minutes ago, Staff said:

As a double protection, you may consider to disable DHCP option 121, an option which can be reported even as “Disable Classless Static Route”. Without DHCP option 121 the attack lacks its essential pre-requisite.

First of all, thanks for the quick reply.

When you mention "disable DHCP option 121", is that something that needs to happen at router level or is it something that can be done at the device level? In the first case, it becomes rather impossible to apply in the most at risk scenarios (hotels, restaurants, airports, etc.).

[Staff 10015]

8 minutes ago, tranquivox69 said:

First of all, thanks for the quick reply.

When you mention "disable DHCP option 121", is that something that needs to happen at router level or is it something that can be done at the device level? In the first case, it becomes rather impossible to apply in the most at risk scenarios (hotels, restaurants, airports, etc.).

Hello!

On the systems, of course!

It is possible to disable it on the router too but that's ineffective in any case. If you don't control the router you just can't do it, as you correctly point out, but even if you control the router and then the rogue DHCP server is installed in your local network but it's a machine different from your router, it makes no difference that you disabled it on your own DHCP server (apart from the fact that if the attacker gains control of your router, he/she can re-enable all DHCP options).

Kind regards
 

[tranquivox69 27]

1 hour ago, Staff said:

On the systems, of course!

Ok, good. Am I right in assuming that I do not have to worry about my private home network (machines at home connecting to the home router, with Eddie installed on them)? If that would be compromised I think TunnelVision could be the least of my problems, to start with.

This would leave me with an iPad to secure (mobile is Android, so immune by default). Any pointers on how to do it? Not necessarily from staff. I think, at the end of the day, this thing is here to stay, so better understand how best to mitigate it.

[Stack of computer parts 9]

4 hours ago, Staff said:

Quote

Hello!

As reported in the very informative and well written article, provided that unfortunately the adversary has the ability to crack your local network and install inside it an evil DHCP server, an excellent mitigation is based on firewall rules exactly as they are enforced by AirVPN's Network Lock.

Correct me if I read the article from arstechnica wrong but it made it seem like the DHCP on the client device can also be exploited. So the vulnerable time period would be during the brief period where network lock is not yet online but the device is. This would also occur in a foreign network during inital login, or during the captive portal login phase(coffee shops and hotels).

As best as i have found, keeping network lock on at boot time prevents something like eddie from being able to contact airvpn to initiate a connection.

Wireguard came up with a solution by isolating the NICs in a namespace jail but I dont think this would work with eddie, perhaps it would work with the airvpn suite
https://www.wireguard.com/netns/#the-new-namespace-solution

Another solution that was mentioned in the article is to have the NICs in a vm. Much like Qubes NetVMs but there is lots of overhead for this kind of solution. Have the external facing NICs isolated in a vm while the host OS uses the virtual nic as its primary gateway with static address asignment. Then when eddie or openvpn is initialized on the host machine it wont matter if the NetVM is manipulated.

I am curious myself if anyone has any other solutions. I use eddie while roaming mostly because I am lazy and need a fast way to connect to a low latency server. I cant easily do that with openvpn or airvpn suite where I generally would need to have a favorites list of servers pre-selected, with no idea of their current status.

[DarkSpace-Harbinger 11]

8 hours ago, tranquivox69 said:

Ok, good. Am I right in assuming that I do not have to worry about my private home network (machines at home connecting to the home router, with Eddie installed on them)? If that would be compromised I think TunnelVision could be the least of my problems, to start with.

This would leave me with an iPad to secure (mobile is Android, so immune by default). Any pointers on how to do it? Not necessarily from staff. I think, at the end of the day, this thing is here to stay, so better understand how best to mitigate it.

Staff can correct me if I am wrong, however I do not believe it will be possible to secure an iOS system from this attack with practical methods.

iOS will not allow you to disable DHCP option 121, nor will it allow you to use a network lock such as Eddie implements.

Due to Apples restrictions, I believe the only way to mitigate responsibly is to abstain from using untrusted/public networks alltogether or perhaps use a pocket router that can implement solutions like firewall rules that the iOS device can connect to.

[benfitita 39]

19 hours ago, DarkSpace-Harbinger said:

use a pocket router that can implement solutions like firewall rules that the iOS device can connect to

I believe that is the only solution for iOS, Windows and macOS.

[Rosuchairudosan 0]

On 5/7/2024 at 5:39 AM, Staff said:

Hello!

As reported in the very informative and well written article, provided that unfortunately the adversary has the ability to crack your local network and install inside it an evil DHCP server, an excellent mitigation is based on firewall rules exactly as they are enforced by AirVPN's Network Lock.

Kill switches are ineffective as usual, nothing new here, but Network Lock greatly mitigates the problem. This mitigation is very hard to circumvent, as it would require traffic analysis first and more operations later (check "Problems with Firewall Rule Mitigations" in the article). Please note that traffic splitting MUST be avoided, otherwise firewall rules of Network Lock will have exceptions which can be in themselves a dangerous enlargement of the surface attack and that can be again exploited by TunnelVision.
 
As a double protection, you may consider to disable DHCP option 121, an option which can be reported even as “Disable Classless Static Route”. Without DHCP option 121 the attack lacks its essential pre-requisite. Check the downsides, though.

We will have the paper investigated by independent reviewers in the next days and if anything relevant on top of all of the above comes out we will publish it.

Kind regards
 

Hi there.  Would you be able to elaborate on how the Network Lock specifically has an advantage here?

And was this independent review carried out?  I haven't seen any other posts related to this, so I'm assuming nothing was found, but I wanted to double-check.