8 ms·
Novel attack against virtually all VPN apps neuters their entire purpose
- agwa 2y agoI mentioned attacks using DHCP option 121 (aka "classless static routes") nearly 9 years ago in my blog post about attacks on OpenVPN: https://www.agwa.name/blog/post/hardening_openvpn_for_def_con https://www.agwa.name/blog/post/hardening_openvpn_for_def_co... (under "Attacks on redirect-gateway") It's really hard to make a robust VPN.
- mycall 2y agoHow hard is it for a firewall to block option 121 (and 33)? Cloudflare WARP made a robust VPN but is not cheap.
- agwa 2y agoIgnoring or blocking these options is trivial but ineffective since the DHCP server can still send a malicious subnet mask. (Edited to replace "default gateway" with "subnet mask")
- peddling-brink 2y agoForgive my ignorance, but what could a malicious gateway do in this instance?
- agwa 2y agoWhoops, I posted too early in the morning, I meant to say "malicious subnet mask" :-) Basically, the DHCP server sends a subnet mask for an absolutely huge subnet (e.g. a /2), and the route for that subnet takes precedence over the VPN route. The attacker can only intercept 25% of the IPv4 address space with a /2 but that's still pretty bad.
- peddling-brink 2y agoClever, thanks!
- gruez 2y agoIt's probably more straightforward to have the firewall block all traffic from using the non-VPN interfaces (ie. blacklist approach) instead. In the other thread[1] there was disagreement about whether commercial VPN services actually implement their 'killswitch" in this way. Apparently NordVPN does not (hearsay), but neither side provided a good survey of other providers. [1] https://news.ycombinator.com/item?id=40279632 https://news.ycombinator.com/item?id=40279632
- felixg3 2y agoCloudflare Warp is free, I think - if you create a Zero Trust Organisation for free and configure the Warp client to use it, you can use unmetered Warp+ with Argo routing without charge.
- JeremyNT 2y agoYour writeup is IMO much better than the way this is being reported. FWIW, I remember reading something similar years ago (I'm not certain it was your specific post, but it might have been). It's strange to see this being described as "novel" now, unless there's something new to it that I am missing.
- yaris 2y agoDupe? https://news.ycombinator.com/item?id=40279632 https://news.ycombinator.com/item?id=40279632
- londons_explore 2y agoIt's because networks/routing tables aren't really designed with security principles in mind. If they were, it would be a simple setting to set an ACL on the network interface to say "DENY all traffic except from VPN application".
- ta1243 2y agoYou seem to be conflating routing and firewalling/access control. You can control your routing table using standard tools (ip route add). You can have helper applications work on it, and get hints from external sources like dhcp, where you can listen to its suggestions (IP, subnet, DNS, extra routes, and other options), or ignore them. If you take those hints then that's your choice. With icmp redirects you can choose to allow them or not with settings like net.ipv4.conf.all.accept_redirects. Then as a belt and braces you have iptables. If you want an ACL on the network interface to say "DENY all traffic except from VPN application", then set your input/output/forward chains to default deny and have a rule to allow from pid=$vpn_pid. I believe you can use pid in pre/postrouting chains. Personally when I'm travelling I have rules which only allow access to my vpn targets, and from memory just DHCP and arp. Have to temporarily disable it for captive portals but then it's back on. Sometimes a network won't accept UDP, so I generally have to tether for normal response.
- zokier 2y agoIt is pretty simple to set routing like that on Linux.
- avsteele 2y agoSo every company who uses VPNs to allow their people to get into the network from offsite (customer site, airport, hotel) now can't safely? You basically have to trust everyone on the remote LAN to not act like a malicious DHCP server. Reading the other thread, this wouldn't even be just the gateway.. Sounds bad!
- prmoustache 2y agoOn the other hand, it is fairly easy to obtain an ip, change your config to static ip reusing same ip, then and only then connect to the VPN.
- mschuster91 2y agoIt's incredibly brittle. The more frequented a network is the shorter the DHCP leases will be, I've seen public hotspots with 10 minutes of lease time.
- prmoustache 2y agoThat doesn't mean the dhcp reuse the ip if it sees it used. Some old clients do not behave correctly and I believe DHCP servers take that into account.
- dspillett 2y ago“Fairly easy” for those of us with a technical background. I'm not volunteering to explain that to the CEO when he hears about this and asks how he can access internal company resources safely while mobile!
- skywhopper 2y agoPresumably most corporate VPNs are used to access specific resources on internal company networks, so if you were affected by this, those resources would fail to load entirely. But also, if you were using more specific routes for your corporate VPN traffic and not just forwarding all traffic through it, then the simple attack of sending two /1 rules wouldn’t interfere. You’d still leak some metadata, but you leak a lot by using public networks anyway.
- dmm 2y agoWould isolating a Wireguard interface using namespaces as described here[0] mitigate this? [0] https://www.wireguard.com/netns/#the-new-namespace-solution https://www.wireguard.com/netns/#the-new-namespace-solution
- agwa 2y agoYes, namespaces are the gold standard solution.
- bscphil 2y agoIn addition, wg-quick appears to use the rule-based solution with multiple tables by default. As I understand it this should make Wireguard (with wg-quick) users on Linux immune to this attack. My default route sends traffic to my gateway, not my VPN: default via <gateway ip> dev host0 proto static So there's nothing for an attacker to do here. They could make themselves my gateway perhaps, but the `ip rule` would still send my traffic to Wireguard and the result would not be readable. The issue described in the article is what happens if you take the most basic approach, which is described in the Wireguard article: "instead of replacing the default route, we can just override it with two more specific rules that add up in sum to the default, but match before the default". This is historically what OpenVPN has done, and it's vulnerable to this issue.
- agwa 2y agoIn general, rule-based solutions are good if they use fwmark, but this gives me pause: > And finally we add a convenience feature for still accessing the local network, whereby we allow packets without the fwmark to use the main routing table, not the WireGuard interface's routing table, if it matches any routes in it with a prefix length greater than zero, such as non-default local routes. [https://www.wireguard.com/netns/#improved-rule-based-routing https://www.wireguard.com/netns/#improved-rule-based-routing] Doesn't that completely neutralize the protection against a DHCP server sending malicious routes or a gigantic subnet mask?
- 2y ago
- jaggs 2y agoAndroid phones running VPNs are apparently still secure. They're recommending using phone as hotspots if you can.
- this_user 2y agoThe real problem with all of this is that DHCP has a lot of weird legacy options that most people are not aware off and that may or may not be fully implemented on most clients, but some of which that are pretty powerful. And in practice, clients trust DHCP servers implicitly, because it's an old protocol that didn't really consider the possibility that you may be on a LAN where the DHCP cannot be trusted.
- agwa 2y agoThat's not really the problem - DHCP's subnet mask option is definitely not weird or legacy but can also be used to execute these attacks. The real problem is that encrypted packets from the VPN client use the same routing table as unencrypted packets from applications. This makes it very difficult to create a robust routing policy that says "all unencrypted packets are routed via the VPN, and all encrypted packets are routed via the physical network interface".
- zokier 2y ago> The real problem is that encrypted packets from the VPN client use the same routing table as unencrypted packets from applications worth noting that this really is very dependent on the specifics of your VPN implementation. For example StrongSwan (ipsec) and WireGuard by default afaik use separate route tables. In general using separate route tables for virtual vs physical networks is not exactly rocket science.
- bell-cot 2y agoAnd yet another time when a strict policy of "Always Ban the OhSoCoolConvenientKludgeTech for anything that could matter" turns out to look like a genius move. :(
- hifromwork 2y agoI don't understand your comment, can you explain? What is the "OhSoCoolConvenientKludgeTech" that should be banned in this case? VPN?
- bell-cot 2y agoI was thinking of DHCP - though the VPN tech certainly doesn't look good either.
- gipsies 2y agoThere needs to be extra evidence before claiming that "virtually all VPNs apps" are vulnerable. From my understanding, they tested WireGuard on multiple platforms. However, other VPN clients may install extra firewall rules, I've seen that happen with VPNs on Windows/macOS/Linux.
- fxtentacle 2y ago"there are no ways to prevent such attacks except when the user's VPN runs on Linux or Android" I guess it really is the year of the Linux desktop :)
- 51Cards 2y agoSadly, I've read similar comments for 10+ years now and yet, here we still are.
- rokkitmensch 2y agoDon't worry: Apples desktop quality is degrading so quickly it will be The Year of Linux on the Desktop by the end of the decade!
- 999900000999 2y agoDo we want Linux going mainstream? Do you want every distro turning into Ubuntu with cloud services and telemetry all over the place ?
- anthk 2y agoAs long as Trisquel, Hyperbola or Guix exist, who cares.
- Zuiii 2y ago> who cares. Oh most of us will definitely care once linux developers start targeting the Ubuntus instead of the Trisquels (like how developers now target "android" instead of AOSP). I mean just look at how Gnome behaves now that it is the default DE. A truly mainstream distro would be the death of the Linux desktop. I hope that year never comes.
- anthk 2y agoAs long as the code is libre, the Ubuntu LTS releases will perfectly map the Trisquel ones. Today, if some service needs propietary code, it's doomed to rot. For firmware with desktop users and programmers/devops using Ubuntu at work -not an issue on servers- , it's preferable to use the Xanmod kernel with Trisquel than falling into thw whole cascade of propietary code in Ubuntu. At least nonfree firmware it's a non burnt hardware ROM; that setup it's 90% free according to the FSF values. Also, you don't get overlayed taxing crap as snaps.
- jacob019 2y agoIt seems that this is only an issue if there is a malicious actor present on the remote network. I've always considered VPN services to be snakeoil, and this doesn't really seem like a problem with VPN technology at all. If you are connecting to an untrusted network, then you are at risk. This has always been true. From the VPN service providers perspective, can't this be mitigated by blocking direct traffic between clients?
- bscphil 2y ago> It seems that this is only an issue if there is a malicious actor present on the remote network. As I understand it, the problem comes not from the remote network provided by the VPN, but by the local network - the physical link over which the user accesses the Internet.
- gruez 2y agoeg. malicious wifi hotspot
- jacob019 2y agoAh, thanks for explaining. So this is only an issue if there is a malicious actor present on the local network. I would say that you are already compromised at that point. Say you are using public WIFI, a VPN service is pointless, you already have an anonymous public IP. Anything sensitive is encrypted end-to-end. And most public WIFI has client isolation. I suppose it could be a problem in certain countries, if your ISP can find out that you're visiting banned sites with a VPN.
- WirelessGigabit 2y agoBut VPNs are sold as the solution for when you are on an untrusted network, like at Starbucks. But, because of this someone can have a Pineapple with a Starbucks SSID, push option 121 and capture a WHOLE bunch of traffic, even though the person using it has configured NordVPN on their iPhone with the killswitch on.
- 2y ago
- betaby 2y agoWait til they learn you can initiate booting the whole OS through DHCP + tftp.
- blueflow 2y agoAll of which has been common knowledge for network admins 20 years ago. Where did we go wrong?
- betaby 2y agoAttack assumes that someone already controls DHCP. If bad actor controls DHCP you have a bigger problem.
- pid-1 2y agoIf one is working from a non trusted network (idk, a coffee shop), isn't that true?
- betaby 2y agoI would break it down in two parts. 1. Coffee shop Wi-Fi router is compromised. Than that's a possible vector. 2. Bad actor sitting in the coffee shop and trying to carry out attack similar to the one described on the link. Fortunately that won't work on any decent WiFi infra from Meraki, Ubiquiti or similar. DHCP attacks are always a problem on dumb wired switches though.
- harveyrook 2y agoDoesn't this blow up the attack surface area to any isp and to any place that offers free wifi? With this attack, I can't assume that it's safe to bring my laptop to a coffee shop and enable the VPN.
- digitalsushi 2y agoIf you dont run your network, you should assume there is a bad actor. Many wifi/router combos have a password of 'admin' or just as easy. Even if the coffee shop giving you wifi is innocent, the person that reconfigured their network in 10 seconds might not be.
- flufluflufluffy 2y agoNot my area of expertise — can somebody clarify if the DHCP server runs on your router, or your local machine? The article keeps mentioning it needs to be on the “same network” but the graphic seems like it’s all on one device. edit: ahh I’m dumb, it’s the router (correct me if I’m wrong!). So as others have said, you have to already be on a compromised network, yes?
- tithe 2y agoDHCP is a client-server protocol, so it "runs" both on the router (as a server program vending available IP addresses) and the local machine (as a client program initiating the request for an IP address, and ultimately accepting the given IP address from the DHCP server on the router).
- numpad0 2y agoDHCP is bit like hotel front and key slip. When a laptop connects to a Wi-Fi, it broadcasts DHCPDISCOVER message using the Wi-Fi card's MAC address, to which local DHCP server responds with IP address + option strings, such as subnet mask, gateway IP, local timezone(but not time), local X Window Manager address, network FQDN, and so on. Every consumer Wi-Fi router has DHCP server program included and set to auto configure, and that is how it's normally operated, but technically multiple servers can coexist within the same subnet, and the server computer doesn't have to be itself the default gateway. Among the options strings that DHCP server may provide is DHCP option 121 Classless Static Routes, added in 2002, that can "push" routing information to clients for convenience. Apparently this option 121 can be abused to trick your laptop into set and prioritize `route add [google.com] via [malicious_host] dev wlan0` over `route add [google.com] via [vpn_right] dev vpn0` which routes traffic to [google.com], or 0.0.0.0/0 for that matter, through [malicious_host]. DHCP is more of a convenience feature for private IP address LANs, not strictly necessary for operating IP LAN. I've heard generations prior to ours sometimes leased clothespins labeled with IPs off the wall to guests, along instruction papers. DHCP completely automates that.
- yencabulator 2y agoAdding routes via DHCP does nothing to my VPN that is activated by fwmark.
- gz5 2y agoEncapsulate and encrypt in the app itself, or in the browser. App (via the openziti sdk): https://blog.openziti.io/no-listening-ports https://blog.openziti.io/no-listening-ports Browser (the openziti js sdk loads on the fly): https://blog.openziti.io/introducing-openziti-browzer https://blog.openziti.io/introducing-openziti-browzer Disclosure: openziti (apache v2) maintainer
- russfink 2y agoAgree. The stated attack is not against an end to end solution.
- username135 2y agoOne thing ive seen overlooked is the mention of trusted vs untrusted networks.
- M95D 2y agoTLDR explanation: - User connects to an untrusted network (public wifi). - That network uses DHCP to assign IP address for the user. - A malicious DHCP would push static routes via DHCP that are more specific than a common default route, and send traffic via a malicious gateway. - User connects to his/her VPN thinking his/her traffic is secured over the insecure network. - The malicious static routes, being more specific, take precedence over the default route added by the VPN.
- PeterStuer 2y agoMy VPN provider claims I'm not vulnerable to this by default (running this VPN endpoint on a spare ASUS Router (https://www.expressvpn.com/blog/tunnelvision-expressvpns-statement-and-assessment-of-the-technique/ https://www.expressvpn.com/blog/tunnelvision-expressvpns-sta...)