61–70 of 238 posts
There are numerous ways to defeat a VPN on a client device, this is why I prefer to put a router that terminates VPN tunnels with no other available routes between my clients and the Internet when I feel the need for a VPN. You can trivially set up one of these "travel routers" and carry it with you everywhere, which is exactly what I do.
You can also mitigate this by placing the VPN interface in a VRF on Linux. I.e. systemd-networkd have support for doing that out of the box. One thing to watch out or is that when enabling VRF, the ip rule entry for l3mdev is listed as 1000 but rule for local traffic is listed as 0, the local rule should be moved to 1000+.
Earlier quoted context omitted.
One of the authors here, the intention was to provide a primer of the topics since we figured this would draw people from a nontechnical background too. That and half the information on the internet about VPNs is from VPN providers and is incorrect or not technical enough to describe how they _actually_ work. We had a sentence in the intro that was supposed to be a hyperlink to the “hey if you know this stuff you sho…
I looked at this in detail. This exploit is a nothing-burger for most decent VPNs. A simple "leak protection" (aka Killswitch) firewall rule completely negates this attack. All decent VPNs implement such a rule by default. Dealing with undesirable routes (whether pre existing or pushed by a DHCP server) is nothing new or in the slightest bit hard to defend against. If a VPN does not implement such a firewall rule alr…
I haven't seen anywhere that said there can be a "fix" for this outside of not allowing "option 121" to be in use at all the DHCP server. Is there no way to mitigate this in the VPN client, or is it simply too fundamental to the way the networks work that there is and never can be a "fix" on the VPN client? I wouldn't expect a malware laden network's "admin" to ever fix this or even hear about it.
The other operating systems do not support that feature. The mitigations we saw were firewall based rules, which create a side-channel that be used to leak the destination of traffic.
I haven't seen anywhere that said there can be a "fix" for this outside of not allowing "option 121" to be in use at all the DHCP server. Is there no way to mitigate this in the VPN client, or is it simply too fundamental to the way the networks work that there is and never can be a "fix" on the VPN client? I wouldn't expect a malware laden network's "admin" to ever fix this or even hear about it.
This article is 99% FUD IMO.
You can also mitigate this by placing the VPN interface in a VRF on Linux. I.e. systemd-networkd have support for doing that out of the box. One thing to watch out or is that when enabling VRF, the ip rule entry for l3mdev is listed as 1000 but rule for local traffic is listed as 0, the local rule should be moved to 1000+.
Is there a way to run an app in a specific VRF nowadays?
You can also mitigate this by placing the VPN interface in a VRF on Linux. I.e. systemd-networkd have support for doing that out of the box. One thing to watch out or is that when enabling VRF, the ip rule entry for l3mdev is listed as 1000 but rule for local traffic is listed as 0, the local rule should be moved to 1000+.
Is there a way to run an app in a specific VRF nowadays?
Yes, it's eBPF but the solution is quite neat to be honest. And you can integrate it into systemd units.
Phew, that was my biggest concern. This would've been pretty difficult to work around (as are Android's well-known VPN bypasses through system apps, but those need local execution privileges).
I haven't seen anywhere that said there can be a "fix" for this outside of not allowing "option 121" to be in use at all the DHCP server. Is there no way to mitigate this in the VPN client, or is it simply too fundamental to the way the networks work that there is and never can be a "fix" on the VPN client? I wouldn't expect a malware laden network's "admin" to ever fix this or even hear about it.
The only fix we’ve observed in the wild was limited to Linux hosts. WireGuard has documentation about how to implement that properly using network namespaces which can be used to isolate network stacks. https://www.wireguard.com/netns/ however, the VPN provider must implement it this way. In our demo we use WireGuard that is implemented without namespaces. The other operating systems do not support that feature. The…
Did u even do any of the math required to demonstrate it can actually work in a reasonable time frame? Did u clearly list the very onerous assumptions required to pull it off?
This whole thing is silly.