To be fair, any proper VPN setup that only relies on the routing table like this is flawed to begin with.
If the VPN program dies or the network interface disappears, the routes are removed aswell, allowing traffic to leave the machine without the VPN.
So it is already a good practice to block traffic where it shouldnt go (or even better, only allowing it where it should).
Many VPN-Programs by Providers already have settings to enable this to prevent "leaking".
If i get this right, that attack only works before the tunnel is initiated (i.e. traffic encrypted), if the hosts is compromised, right? No danger from untrusted points inbetween, right?
This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server. We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.
Sounds to me like it totally works even after the tunnel has started.
More like a corrupt traffic cop. There are reasons you might want this kind of functionality, which is why it exists. Normally you can trust the cop (DHCP server) but in this case the cop has decided to send everyone from all streets down to the docks.
That being said, it apparently does not affect Mullvad apps on any platform other than iOS (Apple does not allow fixing it on iOS). I suspect other serious VPNs are also not vulnerable outside iOS, since it is prevented by simple leak prevention mechanism.
Pushing a route also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface. This is intended functionality that isn’t clearly stated in the RFC. Therefore, for the routes we push, it is never encrypted by the VPN’s virtual interface but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface talking to our DHCP server.
Ok, so double encrypted and authenticated traffic (TLS inside the VPN) would still be safe, and some stuff requiring an internal network origin via the VPN is safe (because the attacker can't break into the VPN connection and your client won't get the right response), but a ton of other traffic is exposed (especially unencrypted internal traffic on corporate networks, especially if it's also reachable without a VPN or if anything sends credentials in plaintext)
To execute this you need a DHCP server on the network.... But any admin worth his salt has a config on the switch to limit DHCP traffic to a designated server.
Seems extremely difficult to pull off in any corporate environment
For shits and giggles I used to sit on those wifis and run a mitm...I would replace all images with the troll face meme...then sit back and watch the confusion. So ya
Encrypted VPN tunnels are ubiquitous in many industries for remote connection to private clouds. They are used by virtually every high functioning company in the world, and getting more common for mid and lower tier companies as well.
Maybe you can explain what you actually mean then, because I don't understand your point.
I would say those dollar-store VPN products people use for geo-spoofing is the worst security risk when it comes to VPNs. You are sending your data through some other company that you have no control or insight into. You have no idea what network security they employ, or whether they are willing or obligated to release your data to other parties.
There's no real way to know if VPNs intended for the public are run the same as those intended for enterprise. Windows doesn't have a lot of the same BS in their enterprise versions that are in the personal ones. Even with the same software, it could just be a checkbox that the salesperson can check for big businesses with legal teams that read and enforce contracts.
I assume this is definitely the case for free VPNs, if any of those still exist. There might be some willing to donate bandwidth and compute resources for the good of others, but I'm sure there's more that pretend to do that but actually just sell the data or maybe just spy.
Tbh I wouldn't be surprised if this is also the case for TOR nodes. I wonder how many entry and exit points are run by the NSA or some other government entity. Or are just monitored. If you can monitor the entry and exit points, you can determine both the source and destination, and just match them together using the middle node address.
Same thing with proxies.
Paid VPNs could go either way. On the one hand, they could make more money if they are willing to sell out their users' privacy. On the other hand, that risks the entire thing falling apart if word gets out that it's not private, since that's the whole point of VPNs. I'm sure there's some good ones out there but I'm also sure that there's bad ones and wouldn't be surprised if some of the ones considered good are actually bad.
Maybe ones that run in Europe would be safer bets. Their business is at least able to run there with the privacy laws. Maybe they are skirting them and haven't been caught yet, maybe their data sales from other regions are profitable enough to support European operations without data sales, but if they are going for max greed and min risk, maybe they wouldn't operate there. Or maybe they just run things differently in the different regions to maximize global profits.
While those are valid concerns, it's not really hard to see why people use VPNs. Just look at how companied and countries abuse the internet, abuse us.
The trust in the unknown systems of the VPN provider may still be better than the known practices of your local ISP/government though. You shouldn't necessarily rely on it too heavily but it's good to have the option.
