Attackers can decloak routing-based VPNs
leviathansecurity.com
Attackers can decloak routing-based VPNs
1–10 of 238 posts
Re: Attackers can decloak routing-based VPNs
#2linux not affected if network namespaces are used to separate vpn and physical interfaces.
Re: Attackers can decloak routing-based VPNs
#3Is there a tl;dr so we don't have to wade through swathes of AI generated text explaining what a network is?
Re: Attackers can decloak routing-based VPNs
#4Is there a tl;dr so we don't have to wade through swathes of AI generated text explaining what a network is?
Scroll down to "What is DHCP option 121?" and start reading there.
Re: Attackers can decloak routing-based VPNs
#5Is there a tl;dr so we don't have to wade through swathes of AI generated text explaining what a network is?
An attacker who controls the DHCP server can give your device more specific routes and this apparently can cause traffic to go over those routes instead of the VPN. So if your VPN says that it's taking traffic for 0.0.0.0/0, and the DHCP server says 0.0.0.0/1 and 1.0.0.0/1 route over 10.1.1.1, then all your traffic gets sent over 10.1.1.1 because those routes are more specific so they "win".
(Please feel free to correct if I've missed something; this was my interpretation of https://arstechnica.com/security/2024/05/novel-attack-agains... )
Re: Attackers can decloak routing-based VPNs
#6I don't know why this article is so long.
DHCP Option 121 allows the DHCP server to set routing rules for a given CIDR range, which end up having a higher priority than the default 0.0.0.0/0 rule due to higher specificity (longer prefix).
Re: Attackers can decloak routing-based VPNs
#7tldr DHCP can add routes, so it can add routes for the internal network of a VPN. It’s not obvious to me why this works, because VPNs set metric 1 on their routes, that’s why traffic goes into them regardless of what IP the surrounding network used. DHCP option 121 has no metric field, so it should get a high default metric and shouldn’t have any impact on a VPN with specific routes. If you only “set the default gateway” (0.0.0.0/0 route), then this probably works. But that also seems particularly amateurish, even for enterprise VPN admins.
Re: Attackers can decloak routing-based VPNs
#8tldr DHCP can add routes, so it can add routes for the internal network of a VPN. It’s not obvious to me why this works, because VPNs set metric 1 on their routes, that’s why traffic goes into them regardless of what IP the surrounding network used. DHCP option 121 has no metric field, so it should get a high default metric and shouldn’t have any impact on a VPN with specific routes. If you only “set the default gate…
because unless you have matching routes, most specific wins
Re: Attackers can decloak routing-based VPNs
#9VPN can be trivially defeated any number of ways. I was shocked when I first learned this ten fifteen years ago through a site that showed my internet provider and location despite being on a VPN. I forgot the name of the site.
A huge problem that doesn't even require defeating is, most OSs and VPN clients, if the connection is shaky, just reverts to the default connection. Even a single packet is enough for your VPN to be worth nothing. In Ubuntu, it required setting up elaborate firewall rules and activate them after you get a stable VPN connection to avoid this. (and even that doesn't protect you from DNS and other stuff being able to track you) (let alone cookies which reveal who you are etc etc)
Re: Attackers can decloak routing-based VPNs
#10The threat model is that an arbitrary attacker can somehow become the DHCP server on your LAN, which is unlikely but not impossible.
On the other hand, if you are using an ISP provided gateway device..