> because Android does not implement support for DHCP option 121, it was uniquely unaffected
Curious if that was a deliberate decision because Google knew about this or completely coincidental..
Attackers can decloak routing-based VPNs
71–80 of 238 posts
Re: Attackers can decloak routing-based VPNs
#72Earlier 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…
FTA: Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.
Re: Attackers can decloak routing-based VPNs
#73I saw a github project that tries to make wireguard+netns more easy to setup: https://github.com/kalken/eznetns
What would be the opposite approach, to make sure all traffic goes through VPN, and only VPN, even if user didn't start the VPN connection (default to no connectivity)? Is there better approach then just disabling all other network interfaces?
Re: Attackers can decloak routing-based VPNs
#74[deleted]
Re: Attackers can decloak routing-based VPNs
#75Earlier quoted context omitted.
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…
FTA: Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.
They don't know what they're talking about. Kill switches are not "tripped" there is no "control channel".
A kill switch is just a firewall rule that is ALWAYS engaged and all it does is blocks off-VPN traffic.
It 100% will defend against this exploit.
Re: Attackers can decloak routing-based VPNs
#76There 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.
I highly encourage dedicated VPN routers at home with each router having it's own wifi network as a way to connect to VPNs. It's easier to connect and more reliable than locally running VPN software on each device imho. Eg. I have a router sharing wifi for 'work' with a permanently maintained vpn connection to the workplace intranet. Another sharing wifi as 'Australia' that I connect to whenever I want to watch TV fr…
Is there a simple DIY? Is it as simple as running a custom router firmware or software on a small mini PC? Last I looked into this a couple years ago, it basically wasn't possible to chain multiple VPN providers on the same machine, even using VPNs, but maybe I'm misremembering. You could of course just use the built-in VPN connection of your router, but that lacks all the benefits of updated software/firewall, and I want my family to be able to watch Netflix, browse the web without running a CAPTCHAthon, etc.
Re: Attackers can decloak routing-based VPNs
#77I saw a github project that tries to make wireguard+netns more easy to setup: https://github.com/kalken/eznetns
What would be the opposite approach, to make sure all traffic goes through VPN, and only VPN, even if user didn't start the VPN connection (default to no connectivity)? Is there better approach then just disabling all other network interfaces?
AFAIK Wireguard will always listen in the default namespace, thus you need to isolate everything else. A fun way of doing it though is to do an ip rule that uses the VRF table, and matches on the user id. That way all traffic from certain users will always end up in the same routing table. You can go further and match on everything except the Wireguard endpoint. With iptables you can MARK the traffic you want to be differently and then catch that traffic with ip rule.
Re: Attackers can decloak routing-based VPNs
#78Earlier quoted context omitted.
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…
Looking at mozilla vpn, I can’t tell if there is such a setting, unless it’s just enabled by default. Can anyone clarify?
> A VPN kill switch is a must-have for privacy reasons when using a VPN. If you are actively using the VPN to transfer data and your Internet connection becomes unstable or drops, the entire network connection on your device will be blocked to prevent your local IP address from being exposed to the outside world. The kill switch is on by default on Windows, Android, iOS, macOS and Linux and there is no setting to turn it off.
https://support.mozilla.org/en-US/kb/mozilla-vpn-kill-switch
Re: Attackers can decloak routing-based VPNs
#79> because Android does not implement support for DHCP option 121, it was uniquely unaffected Curious if that was a deliberate decision because Google knew about this or completely coincidental..
There are so many DHCP options, for something like Android it makes sense to start with only supporting the bare minimum and then only enable support for an additional option if there is a requirement raised for it. Given this DHCP option isn’t commonly used, such a strategy would likely result in it not being supported, irrespective of any security concerns with it.
Re: Attackers can decloak routing-based VPNs
#80Earlier quoted context omitted.
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…
The "side channel" is silly. You assume someone is hitting the same endpoint over and over and over and with significantly high traffic that it rises above the noise. 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.
So in the example we gave for the side-channel you’d be correct that “it depends”. We also wrote that it was flexible.
I do want to point out that you could deny all traffic except allow a single IP address to test the inverse in a low traffic setting. With a low DHCP lease time it’s feasible that could look like a shaky connection. This is only possible because the kill switches don’t actually disconnect the user.
There’s also mitigation bypasses that are likely to be discovered, we have a few we’re working on.