TunnelVision - How Attackers Can Decloak Routing-Based VPNs For a Total VPN Leak

Privacy
1
4 Likes
2

From the article.

Requirements for decloaking VPN traffic

  • The targeted host must accept a DHCP lease from the attacker-controlled server
  • The targeted host’s DHCP client must implement DHCP option 121

We want to stress that there are ways an attacker who is on the same network as a targeted user might be able to become their DHCP server:

For a normal home, this seems pretty unlimely given that an attacker would have already breached your network.

2 Likes
3

Ill revise my opinion, this could be used in internet cafe, airport wifi, restaurants and other oublic wifi where you don’t control the network. This might be a little more bad that I initially thought.
I hope that the people finding these issue can stoo coming woth stupid attack names. This is basic network operation, but with a small tweak that defeat a vpn on the side, not a heavy critical and deep vulnerability issue.

4 Likes
4

There is another explanation of the attack.

This is a serious problem. While it is true that this sort of attack doesn’t actually compromise the VPN per se, it does compromise the router/gateway/DHCP server the device is connected to.

While this isn’t a problem if you are on your own home network, this is a pretty damn major issue if you connect to public WiFi or are traveling. As the article states, the only way to mitigate is to connect via android or your bridged WiFi device. Even Linux is somewhat vulnerable.

VPN providers are either going to have to implement some sort of solution in-app with routing tables, or kernals/drivers are going to have to be updated to ignore option 121.

3 Likes
5

Does this impact connections to the Tor network too? I don’t know enough about networking…

6

Rogue DHCP servers are not a new thing

3 Likes
7

Just yesterday I was debating if I should buy a used Windows laptop and drop Linux on it or buy a Pixel tablet and flash GrapheneOS.

Considering androids ignore option 121 that is a point in the tablet’s favour.

1 Like
8

The issue seems to be solved on linux too though, well kinda sorta mostly solved

9

You may want to be aware of this. Especially relevant if you run your own VPN.

1 Like
10
1 Like
11

I still really hate that this got granted a CVE and a witty cool name, it’s a misconfiguration not a vulnerability :weary:

But that aside, I think the pertinent information most people really need to know is that:

  • if you use a VPN to “make public wifi safe”, you should probably only use Proton/other VPNs with killswitch or just not use public wifi
  • if you use a VPN for creating a virtual private network to access network resources not normally available via the internet, this is not an issue

Edit: I should probably explain why I strongly believe this is a misconfiguration and not a vulnerability. Basically, the “vulnerability” relies on a network not having sufficient protections against rogue DHCP servers (i.e., it is misconfigured). This is very easy to do with any network hardware that can drop unauthorised DHCPOffer packets, you just allowlist the real DHCP server and you literally cannot have a rogue server replying to devices on the network.

2 Likes
12

Misconfiguration well yeah but if that’s what a default is that is is still a vulnerability imho. I understand where you are coming from tho. Technically you should have good TSCM (technical state compliance monitoring) but when a specific version of a piece of software has some weakness that can still be classified as vulnerability which needs to be patched with an update. Essentially all vulnerabilities in a way are misconfigurations.

1 Like
13

Might also be a good time to mention again that the Killswitch of proton is still pretty broken on Macs with a T2 Security chip (Kill switch issue on Intel-based macOS devices - Proton VPN Support)

14

So, are the firewall rules mentioned in Mullvad and Proton’s blogs implemented by default or is it the same as Kill Switch feature?

1 Like
15

Curious about how ProtonVPN implements their firewall rules for iOS. Not used their service before. Can anyone share any insight?

According to IVPN which uses TunnelKit (afaik), the issue can’t be mitigated on iOS. Perhaps @viktorivpn can comment?

Mullvad still uses wireguard-go for their iOS app, which is incompatible with some of the flags available via Apple’s APIs, so that’s understandable. They’ve been working on replacing wireguard-go for some time (ever since the TunnelCrack vulnerability) according to their blog, but they’re not there yet.

16

We concluded that the key question is whether the mitigation method ‘includeAllNetworks’ used for iOS firewall is sufficient to prevent this attack. Based on our first tests using ‘includeAllNetworks’ does not block DHCP traffic on a local network, and this assertion is backed up by relevant Apple documentation:

If that’s the case, even though we use this property on iOS, it’s not effective against TunnelVision.
Proton claims ‘includeAllNetworks’, resolves this issue. Mullvad (last time I heard about this from them, might not be up to date) does not utilise it yet.

Note/caveat: doing a full replication of the attack is in our backlog, only after that we can verify that our hypothesis is correct.

Based on the above we decided for now to suggest to customers that our iOS app is potentially affected by TunnelVision.

4 Likes
17

Can’t even use a VPN safely on iOS, lol. So much for a “privacy-respecting” OS developed by a “privacy-respecting” corporation.

4 Likes
18

Appreciate the transparency, please post updates!

1 Like
19

More like network admins suck, and iOS doesn’t protect you from headass incompetent network admins :rofl:

20

Apple is just incompetent. You should be protected, no matter if the network administrators suck or have just done something to be malicious.

3 Likes