96
Why Your VPN May Not Be As Secure As It Claims
(krebsonsecurity.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 07 May 2024
96 points (98.0% liked)
Privacy
31978 readers
365 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
Chat rooms
-
[Matrix/Element]Dead
much thanks to @gary_host_laptop for the logo design :)
founded 5 years ago
MODERATORS
Use a killswitch then... no vpn, no internet
This is the only place they mention kill switch. I feel like it needs a slight clarification on whether it was enabled and didn't work, or if was just disabled and therefore not "engaged".
The Killswitch only checks that VPN is up, not whether traffic is correctly routed over it.
As I understood it, VPNs don't work in this threat model because it's essentially routing traffic through a compromised router before it ever reaches the VPN, so the VPN acts normally but there's a snooper before you ever connect to it
Huh? I thought the whole point of a VPN is to encrypt all traffic between my PC and the VPN server. Please be so kind and educate me on anything I have a misconception of:
For example, I use Safing Portmaster and I have set it up in a way where all the packets have to go through their VPN and if they don't, they get dropped before they leave my PC.
Before that I was running openvpn with a killswitch, which I thought besically did the same, it had a tunnel to the VPN server and if it is down, no packet leaves the PC.
Is that not how VPNs normally work?
That is the function of a firewall and not of the VPN. As I understand portmaster it does both. But that is not normal VPN behavior.
VPNs are not magic. They are a piece of software that encrypt traffic and send it to a special server. They do that by creating a virtual Internet connection (think like pluging in an additional Ethernet cable or connection to an addition WiFi at the same time). Everything that is sent through the virtual connection is encrypted. Your system now has (at least) two valid Internet connections (one real and one virtual). For every packet it sends it needs to decide which connection it should send it from. This is decided by something called the routing table. When you start the VPN it will put two routes into the table.
The attack described is a way how a network router can add a new route into your devices routing table to basically override the second route from the VPN. The route is still there, there just is another one that has a higher priority.
A VPN is not the ultimate authority over your network traffic. It is just another program sending and recieving taffic.
Thanks for the detailed explanation. I think I get it now!
I did look into it with
ip route showwhen using nothing vs portmaster vs openvpn and it is just like you said, when using openVPN it just creates additional routes with a higher priority, but the normal route is still open.I'm not saying it could not happen, but when you use VPN, the local network equipment does not determine protocols, the VPN infrastructure and it's configuration in the device do. Any local connection, including the internet gateway, just serve as the road for those packets to go out or come in.
If anyone thinks I'm wrong, please let me know, I'm not 100% certain this is the case, but it is my understanding of how VPNs work.
You aren't wrong, per se, I think you just don't fully grasp the attack vector. This is related to DHCP option 121, which allows routes to be fed to the client when issuing the ip address required for VPN connectivity. Using this option, they can send you a preferred default route as part of the DHCP response that causes the client to route traffic out of the tunnel without them knowing.
E. It would likely only be select traffic routing out of the tunnel. I could, for example, send you routes so that all traffic destined for Chase Bank ip addresses comes back to me instead of traversing the tunnel. Much harder to detect.
Oh crap! That's concerning as hell. I'm going to try that in my PFSense and test it with ProtonVPN, Tailscale, Wireguard to my UnRaid and NordVPN. See if maybe any of them have a way of hardening that, or at least completely dropping the packages if not.
If no VPN can be hardened for this, is there a chance that Tor or I2P can be used to avoid it instead?
Thank you very much for such a wakeup call.
This won't mitigate this specific attack, however running your VPN as a full tunnel will.
Full tunnel would not mitigate this attack because smaller routes are preferred over larger ones. So, sure, 0.0.0.0/0 is routed over the tunnel, but a route for 8.8.8.8/32 pointing to somewhere layer2 adjacent, pushed via DHCP option 121, would supercede that due to being more specific.
Full tunnel using routing wouldn't work but many full tunnel implementations use a shim where once the Tunnel is connected, the system route table isn't referenced anymore, so you can put as many static routes etc as you want, but all traffic will hit the VPN interface before routing is done. For example Cisco any connect removes route look-up from the TCP/IP stack of the local system.