this post was submitted on 08 Aug 2023
289 points (99.0% liked)

Technology

60116 readers
3114 users here now

This is a most excellent place for technology news and articles.

Our Rules

  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots

founded 2 years ago
MODERATORS
L3s
[email protected]
[email protected]
L4s
enu
289
TunnelCrack: Widespread design flaws in VPN clients (tunnelcrack.mathyvanhoef.com)
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/technology
43 comments fedilink hide all child comments
 

What are TunnelCrack vulnerabilities?

  • Two widespread security vulnerabilities in VPNs can be abused by an adversary to leak traffic outside the VPN tunnel.
  • The two vulnerabilities are called the LocalNet and ServerIP attack.

Summary of what VPNs are vulnerable to TunnelCrack

  • VPNs for iPhones, iPads, MacBooks, and macOS are extremely likely to be vulnerable
  • A majority of VPNs on Windows and Linux are vulnerable
  • Android is the most secure with roughly one-quarter of VPN apps being vulnerable.
  • Users generally decide which VPN protocol to adopt while creating the VPN tunnel, with common options being OpenVPN, WireGuard, or IPsec. As a result, the precise configuration of the client, and whether it is vulnerable to (variants of) our attacks, may depend on the chosen VPN server and protocol.

TunnelCrack Prevention

To prevent the attack, VPN clients should be updated to send all traffic through the VPN tunnel, except traffic generated by the VPN app itself.

How do the LocalNet and ServerIP attacks work?

LocalNet attack:

  • The adversary acts as a malicious Wi-Fi or Ethernet network and tricks the victim into connecting to it.

  • Once connected, the adversary assigns a public IP address and subnet to the victim.

  • The adversary then tells the victim that the local network is using this subnet, which means that IP addresses in this range are directly reachable in the local network. When the victim now visits a website with an IP address in this range, the web request will be sent outside the protected VPN tunnel.

  • 66+ VPNs on five platforms were tested and found that all VPN apps on iOS are vulnerable. Additionally, all but one VPN client on macOS is vulnerable, on Windows a large majority of VPNs are vulnerable, and on Linux more than one-third are vulnerable. Interestingly, VPN apps on Android are typically the most secure, with one-quarter being vulnerable to the LocalNet attack.

ServerIP attack:

  • The adversary abuses the observation that many VPNs don't encrypt traffic towards the IP address of the VPN server. This is done to avoid re-encryption of packets.

  • The adversary first spoofs the DNS reply for the VPN server to return the IP address of a website that they control. The victim will then connect with the VPN server at this IP address.

  • To assure the victim still successfully creates a VPN connection, the adversary redirects this traffic to the real VPN server.

  • While establishing the VPN connection, the victim will add a routing rule so that all traffic to the VPN server, in this case the spoofed IP address, is sent outside the VPN tunnel. When the victim now visits a website with the IP address of the VPN server, the web request is sent outside the protected VPN tunnel.

  • Built-in VPN clients of Windows, macOS, and iOS are vulnerable. Android 12 and higher is not affected. A significant number of Linux VPNs are also vulnerable.

all 45 comments
sorted by: hot top controversial new old
[–] nickhammes 55 points 1 year ago (2 children)

Look at the last three pages of their paper to see if your VPN is affected.

[–] Cheems 6 points 1 year ago (1 children)

What if yours isn't on the list at all

[–] [email protected] 5 points 1 year ago

Consider them as potentially affected and hope the vendor checks if their client is vulnerable and releases a fix quickly.

[–] [email protected] 6 points 1 year ago

Quite the emotional roller coaster this was... Went from 'uh-oh' all the way over to 'WHATDOTHETRIANGLESMEAN' and back round to 'cool bro'

[–] [email protected] 30 points 1 year ago (1 children)

Seems like Mullvad is yet again a solid choice (except for iOS). Unfortunately almost the only one too, which is the more severe detail here. It looks like most VPN services need to really step up their game.

[–] [email protected] 13 points 1 year ago (1 children)

Its a damn shame they dropped support for port forwarding.

[–] EzekielJK 3 points 1 year ago

I've seriously considered switching away from them since they dropped support. I've stuck with Mullvad for so long because, while they've never been the absolute best option out there, they were reliable, affordable, and respected.

[–] ThomasTheWankEngine 27 points 1 year ago

To be fair, Apples VPN integration on iOS has been shit for a long time. From the top of my head:

  • Leaking IP addresses after connecting the VPN because it doesn’t close the sockets of existing connections
  • Randomly turning the VPN off when not actively in use
  • No Option whatsoever to force all traffic through the VPN.
[–] [email protected] 26 points 1 year ago (2 children)

The first one is just split tunneling which is a design feature for most organizations using VPN, so any company paying for this for their employees, and many using stuff like OpenVPN explicitly want that feature for good reasons.

The second requires both intercepting DNS (which I think is getting harder all the time with DNSSEC etc) and you not using a server certificate to authenticate the actual VPN server (unless I really misunderstand what's happening here). Most public VPN servers don't seem to be configured to work as you say (not send traffic for their server / site over the tunnel) - at least OpenVPN with common configurations will send traffic over the tunnel as far as I've been able to determine. Some details to reproduce this would be helpful. The paper isn't currently available, but I'm still wondering how they're adding a static route to the client unless they can in fact terminate the VPN connection and pass back config rules different from the client config file.

[–] [email protected] 5 points 1 year ago

Yeah I don't quite see how this is supposed to work either. They say they send the traffic to the intercepting server and then forward it to the "real" VPN server to actually establish the connection. But unless they can actually crack any of the encryption, all they have is the encrypted traffic to and from the sever if I'm not mistaken ... So what they do with that I'm unsure.

[–] iopq 4 points 1 year ago (2 children)

So having DNSSEC on the domain of the server prevents the second attack?

[–] [email protected] 5 points 1 year ago

It narrows the chance of DNS interception but the second attack can be mitigated through certificate validation of the VPN server.

[–] [email protected] 2 points 1 year ago (1 children)

I think both attacks are actually DNS vulnerabilities from my reading of the paper which is now available. It has nothing whatsoever to do with VPNs, except in so far as you can abuse DNS to redirect traffic to a hostname somewhere else. I suppose the first attack does suggest that commercial VPN companies should update their configuration to require the non-routed IPs to be the local network unless otherwise overridden by the customer. That should completely kill the first attack from what I can tell. Customers can also just look at their route tables after connecting to a random wifi and see if it looks weird (the local net not being 192.168.0.0/24, 172.16-20.0.0/16[IIRC, google the range],10.0.0.0/8)...

The second attack still requires the attacker to control DNS, so again, is basically either the ISP or a rogue AP. I still think DNSSEC helps, DoH would help (but OSs don't use this, and generally for good reason - we really really need PKI for DNS as the new standard IMHO, which I think DoH is trying to do), but also hardcoding the DNS server you use to a known good server (this might be hard, but like 1.1.1.1 is going to be harder to intercept) would stop it.

This is also why people say VPN doesn't provide full security on it's own (Though I question the ability to pull these attacks off in most practical situations - quite a lot depends on your threat model) and redirecting HTTPS traffic for instance outside the VPN leaks that you connected to that site, but none of the contents of the traffic.

[–] iopq 1 points 1 year ago (1 children)

I run a personal VPN on my DNS and I don't know how to tell if I'm vulnerable.

But when I'm in a country like China, using 1.1.1.1 directly is sometimes an issue, China poisons the unencrypted DNS traffic and blocks encrypted traffic on known DNS servers

Given the threat model of a malicious state actor, what can I do?

[–] [email protected] 1 points 1 year ago (1 children)

Honestly - nothing . You need to not use the Internet for anything sensitive if a nation state is after your traffic, even moreso if you're inside their network, even more so if it's controlled as tightly as China does.

In the US you might hide among the other traffic if you really know what you're doing and very careful. Especially if they're not suspecting you and so aren't directly targeting you. And that's a big if. China blocks traffic so you just end up. Screwed.

[–] iopq 1 points 1 year ago (1 children)

That's absolutely wrong, even China can't get to my encrypted traffic, since I'm hiding it among the other encrypted traffic on port 443

Also, I'm not using encrypted client hello (banned in China), but it's spoofed to a real domain of a real company so the GFW thinks I just really love that website

[–] [email protected] 1 points 1 year ago (1 children)

Ok, but now you're masquerading as HTTPS. I was talking about most VPNs use known ports (openvpn port for instance). I also have heard a lot of external sites are blocked in China, so I was referencing that I would guess most commercial VPN servers get blocked also. If you're running your own endpoint (not paying for a commercial service) and making it look like SSL, and China isn't blocking that IP address outside the country at this time, then it should work, though I'd still worry about timing and network correlation attacks - if a nation state wanted to. There's a lot of wiggle room in that if, and I wouldn't put it past them to just backdoor your hardware on entry (or the US customs inspection either FWIW).

[–] iopq 1 points 1 year ago

It's just some AWS IP, these servers don't have their own provider. So some commerical ones still work. But self-hosting is more predictable

The VPN also does padding to hide small packets like SYN/ACK. The access patterns are an issue, but they kind of just throttle you since that's not a 100% tell.

My hardware is my phone and I keep it on my person, they haven't touched that, thankfully

[–] gaylord_fartmaster 23 points 1 year ago (3 children)

Boy am I glad all of my VPN connections are running on Wireguard these days.

Well, except for my work laptop of course, running a less secure and overpriced proprietary VPN solution lol

[–] [email protected] 16 points 1 year ago

"If we pay for it, we get a support contract, which means we can blame the vendor instead of ourselves!"

-- Corporate IT departments

[–] [email protected] 14 points 1 year ago

As I understand it, WireGuard is impacted too. It seems to have more to do with your OS than the protocol used.

[–] porksandwich9113 6 points 1 year ago

Also glad I run wireguard for my homelab.

Fortunately for my work connection, I work at the ISP I get my internet service from, so they just pipe my work VLAN to a port on my ONT and I don't need a VPN.

[–] [email protected] 9 points 1 year ago* (last edited 1 year ago) (2 children)

I'm not sure to understand correctly: does it only impact OpenVNP? Are Wireguard clients safe?

[–] [email protected] 13 points 1 year ago (1 children)

Here's the paper: https://papers.mathyvanhoef.com/usenix2023-tunnelcrack.pdf

Some OpenVPN and Wireguard clients are impacted. See the paper.

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

Thanks, the website only mentioned OpenVPN, I'll dig into the paper.

[–] [email protected] 6 points 1 year ago (3 children)

Am I the only person that goes straight to whatismyip when they connect over their VPN?

This doesn't seem like a problem with VPN software intrinsically, maybe they could have a configurable limited prefix length with a sensible default and maybe a default setting that will warn/fail if an RFC1918 with an in-scope prefix is not used on all the LAN interfaces active. But again it's generally a combination of user security configuration and opsec (checking they really are connected) that is the problem I think.

[–] [email protected] 9 points 1 year ago (1 children)

Am I the only person that goes straight to whatismyip when they connect over their VPN?

I don't see how that would help, you're still connecting to your actual VPN under this attack. Your IP would report correctly.

[–] [email protected] 0 points 1 year ago

Well, as I'm understanding their first exploit. That is setting up a fake access point with a very large subnet mask. E.g. 192.168.178.124/1 (128.0.0.0). I think that's the largest you can do, I doubt IP stacks will let you set an interface mask of /0. That would put half of the IPv4 address space onto the LAN. They can then have that device transparant proxy for ALL addresses in that address space onto the actual internet, but logging anything of interest.

But, provided the whatismyip site is in that block (it's 50/50 I guess) it would not be showing the VPN address.

I think the overall message here is when you're on a network you're not familiar with (or even if you are, they could be spoofing a known SSID) always be checking things.

Also, yes VPN software could be looking out for suspicious network configurations too.

[–] [email protected] 6 points 1 year ago (1 children)

At the last place I worked, our field agents had to use a VPN to transmit sensitive data back to the office multiple times per day from different locations. These were mostly not technical users. It's very important that the VPN correctly hide information that is being sent to the office servers from whatever dodgy access point they might have connected to (or detect the attack on its own and refuse to connect), and we can't rely on them to perform any extraneous checks. They're under enough stress doing their own job; every added IT hurdle makes it harder for them. This is exactly the kind of situation where this attack is most dangerous.

Maybe I should text this link to my old boss.

[–] AlpacaChariot 10 points 1 year ago (1 children)

This may not be strictly related to the use case you described but I think it's kind of cool...

On Linux you can add the software used to do the upload to a group "vpnroute" or similar, and use iptables to block all traffic from that group that isn't sent through the VPN tunnel. Something like this:

iptables -A OUTPUT -m owner --gid-owner vpnroute ! -o tun0 -j REJECT

Obviously needs to be made persistent which I do with UFW in /etc/ufw/after.rules. It makes for a good kill switch.

[–] [email protected] 2 points 1 year ago

Good tip, thanks!

[–] peopleproblems 5 points 1 year ago

Well

that's not good

[–] kaitco 4 points 1 year ago

Phew! Mine is secure. It’s the little things…

[–] [email protected] 4 points 1 year ago (1 children)

Anyone know if bitdefender's vpn is on the list?

[–] [email protected] 3 points 1 year ago

bitdef

I don't think they tested Bitdefender, but you can ask your vendor about these CVEs

  • CVE-2023-36672: LocalNet attack resulting in leakage of traffic in plaintext. The reference CVSS score is 6.8.
  • CVE-2023-35838: LocalNet attack resulting in the blocking of traffic. The reference CVSS score is 3.1.
  • CVE-2023-36673: ServerIP attack, combined with DNS spoofing, that can leak traffic to arbitrary IP address. The reference CVSS score is 7.4.
  • CVE-2023-36671: ServerIP attack where only traffic to the real IP address of the VPN server can be leaked. The reference CVSS score is 3.1.
[–] [email protected] 3 points 1 year ago

I like how VTun is still dead and still okay (aside from the one guy gaming the testing for karma).

[–] 1luv8008135 2 points 1 year ago

And Ofcourse Nord is on the list.