Technology

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

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.

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

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.

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

I assume you mean the table on the last page of the paper, which indeed shows WireGuard is safe against the second attack.

If you go back one page (to page 17) it has another table for the first attack. That one is less positive about WireGuard:

• The good: On Linux/Android, WireGuard is safe against that one.
• The bad: MacOs and iOs WireGuard are marked as vulnerable to that first attack.
• The ugly: Windows is marked as "local traffic blocked" which presumably means the attack failed but so does the connection they tried to attack.

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.

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.

Well, the issue is that the main exploit they're using (I've not read the second one yet) is because of how most people would want a VPN to work. Route anything inside the LAN direct via the implied route, and the rest over the VPN.

Sure for ultra security you would want to limit that. But it has a trade-off too. Local resources become unavailable too. In most cases people will want their NAS mounts, and other local resources to still work.

I don't think the VPN software can or should know what is legitimate LAN traffic and what should be secure internet traffic. But making configurable rules with sensible defaults would certainly be able to limit any weakness this produces. And yes, consumer targeted VPN software should probably have a maximum security option which locks out the LAN interface except for packets to the VPN server. I have a VM configured to connect to a VPN and it works like this. In fact it has two states. State 1: VPN not connected, LAN accessible, Internet not. State 2: VPN Connected, LAN inaccessible, Internet accessible.

Beyond that, the user needs to take some level of responsibility too.