[HN Gopher] Attackers Can Decloak Routing-Based VPNs
___________________________________________________________________
Attackers Can Decloak Routing-Based VPNs
Author : dsr_
Score : 84 points
Date : 2024-05-06 21:19 UTC (1 hours ago)
(HTM) web link (www.leviathansecurity.com)
(TXT) w3m dump (www.leviathansecurity.com)
| the8472 wrote:
| linux not affected _if_ network namespaces are used to separate
| vpn and physical interfaces.
| acer4666 wrote:
| Is there a tl;dr so we don't have to wade through swathes of AI
| generated text explaining what a network is?
| rahimnathwani wrote:
| Scroll down to "What is DHCP option 121?" and start reading
| there.
| yjftsjthsd-h wrote:
| 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...
| )
| sixothree wrote:
| Will static IP and gateway alleviate this threat? I guess at
| what level too.
| krebsonsecurity wrote:
| I interviewed some smart people about their research in story
| published today:
|
| https://krebsonsecurity.com/2024/05/why-your-vpn-may-not-be-...
| morattisec wrote:
| You probably followed the advice to read from the 121 section
| already but if you're sharing this others it might be helpful
| to link our website that serves as a TLDR + FAQ.
| https://tunnelvisionbug.com/
|
| There's also a general public advisory there that's supposed to
| be for anyone non-technical but who wants to understand the
| issue. All this content was also written by hand over 8ish
| months too, no AI was used
| wrs wrote:
| This is a great explanation of basic networking mechanisms
| that most people know almost nothing about. Don't listen to
| the haters.
|
| I feel that I'm in a high percentile for networking
| knowledge, but I didn't know about option 121!
| Aloisius wrote:
| I 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).
| morattisec wrote:
| 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 should skip to
| the POC section". I'll make sure that gets updated/more
| obvious.
| bimguy wrote:
| Great write up by the way. Even some technical people might
| not know about this, not all technical people are network
| experts after all.
| tgsovlerkhgsel wrote:
| The PoC section doesn't explain the issue. I think a one-line
| TL;DR similar to the summary above would be best, e.g. "A
| malicious DHCP server can use DHCP Option 121 to set routing
| rules, which can override the routing rule used by VPNs and
| cause traffic to be routed outside the VPN"
|
| (I like it that you provide the background for people who
| need it, but also found the actually relevant information
| extremely annoying to find.)
| wolverine876 wrote:
| > found the actually relevant information extremely
| annoying to find
|
| Skip down to the DHCP section?
| wolverine876 wrote:
| What I read does a great job of explaining the technology; I
| know it pretty well but it's great to have an updated, clear,
| concise, well-organized, integrated explanation all in one
| place. I can't imagine how long that took to make it that
| clear!
|
| (Everything posted here gets similar complaints about the
| writing, headline, too short, too long, too hot, too cold,
| etc. Goldilocks is never pleased here. Welcome to HN! :)
| nonrandomstring wrote:
| Good call. For a general IT audience you are speaking to,
| context building really helps refresh the scene before
| dropping the exploit. Well communicated.
| banister wrote:
| 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 already then
| it's likely already leaking so all this exploit demonstrates
| is that "A VPN without leak protection, leaks".
|
| (I won't even mention the "side channel" attack as it's
| completely ridiculous)
|
| I liked your write-up and option 121 is a little known
| option, so it's good to know about. But let's not pretend
| this thing is bigger than it is.
| barbariangrunge wrote:
| Looking at mozilla vpn, I can't tell if there is such a
| setting, unless it's just enabled by default. Can anyone
| clarify?
| SushiHippie wrote:
| > 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
| CommitSyn wrote:
| 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.
| banister wrote:
| 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.
| formerly_proven wrote:
| tldr 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.
| ikiris wrote:
| because unless you have matching routes, most specific wins
| Aloisius wrote:
| More specific routes are higher priority than less specific
| ones, so 0.0.0.0/1 is chosen over one for 0.0.0.0/0 even with
| metric 1.
| bedobi wrote:
| VPN 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)
| lxgr wrote:
| What is a trivial way to reveal a VPN-using website visitor's
| actual IP these days? Browsers have improved a lot over the
| last ten years.
|
| > 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.
|
| This is mostly a function of the VPN client, not the OS. Some
| clients will reinstate default routes pretty quickly when they
| lose connectivity, others are pretty sticky.
|
| At least Android even offers a specific "always-on VPN" option
| to prevent leaks like that.
| dinobones wrote:
| Are there any router/cheap "bridge" devices that can sit
| between your router and the internet and force outbound
| communication to go through the VPN, as if it were your ISP?
| bedobi wrote:
| apparently lots of folks use Raspberry Pi's for this, which
| has added benefit of PiHole filtering out of ads etc
|
| no personal experience but sounds nifty, maybe there are
| other options too
| Hikikomori wrote:
| Just use iptables and only allow the vpn traffic. Or do the
| same with a small Linux box.
| bedobi wrote:
| apparently lots of folks who do this still have problems
| that a lot of software that promises to do this actually
| only does it for ipv4, so ipv6 traffic still exposes them,
| lol
| mftrhu wrote:
| Pretty much any of the GL.iNet devices should be able to do
| that.
| GardenLetter27 wrote:
| On Linux this is easy with a network namespace and nftables.
| wepple wrote:
| There have been a bunch of these, although if you're really
| that concerned, you might as well go all in with tor
|
| A modern version of this: https://github.com/grugq/portal
| whoomp12342 wrote:
| is there reading on this matter?
| m463 wrote:
| Can just be location services - it uses known bluetooth devices
| and known wifi networks to deduce your location
| bedobi wrote:
| can be but that wasn't what i was experiencing
| pushedx wrote:
| The 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..
| radiowave wrote:
| Or become the DHCP server on whatever third party wifi you're
| connected to.
| smarx007 wrote:
| > arbitrary attacker can somehow become the DHCP server on your
| LAN, which is unlikely but not impossible
|
| Coffee shop wi-fi? A.k.a merely the no. 1 selling point for
| most VPN offerings.
|
| The proper course of action in this case is to use your 4G/5G
| connection and not to connect to shady networks you don't
| trust.
| SahAssar wrote:
| > A.k.a merely the no. 1 selling point for most VPN
| offerings.
|
| I thought the selling point was protection against hackers.
| No, was it your ISP seeing your (basically always HTTPS
| encrypted) traffic? Or facebook/google harvesting your data?
| Or russian hackers? Or watching netflix from other countries?
| Or data-harvesters watching your traffic? Or if you just
| really like downloading linux ISOs? I also think I heard
| something about snowden and NSA tracking in a few ads.
| Something something cheaper airplane tickets?
|
| Either way, it's all scary and for the low fee of 5$ per
| month (sign up for 3 years and you get 3 months free with my
| code!) you don't have to worry your pretty little head about
| it anymore. Don't worry about that our company is registered
| in Bermuda and is just 3 months old.
| Aurornis wrote:
| The risk is outside the home: Using a VPN at the coffee shop,
| hotel, office, etc.
| tgsovlerkhgsel wrote:
| That's one of the commonly advertised reasons to use VPNs:
| protection in untrusted WiFi networks.
| flir wrote:
| Surely one of the big use-cases for a VPN is that the network
| you're connected to is untrusted?
| CodeWriter23 wrote:
| You mean like a pwned home router?
| threePointFive wrote:
| "the DCHP server" implies it is somehow a special device on
| your network, which is a flawed assumption. DHCP works on an
| broadcast protocol and your device will accept the first offer.
| The fact that the most common residential configuration is for
| your DHCP to be hosted on your router and thus likely the first
| to respond is inconsequential to the fact that any hostile
| device on your network could use this exploit.
| fargle wrote:
| always the breathless sensationalized vulnerability headlines...
|
| it's interesting, but of limited usefulness - the device has to
| accept responses from a dhcp server. if an attacker controls a
| dhcp server, he's either on the network already or has already
| had to do a lot worse than installing a couple static routes to
| get there.
|
| it's not nothing - a compromised home gateway could use this
| technique to sneak into a corporate VPN via a users' laptop, but
| if you have a compromised home gateway, you have a _lot_ of other
| problems that could lead to the same result.
| Aloisius wrote:
| I think a public wifi network effectively being able to disable
| someone's VPN is pretty bad.
| JackSlateur wrote:
| There are lots of ways to disable vpn : basic firewall on the
| router, if you have access ARP poisoning if you do not.
| Aloisius wrote:
| Yes, but this disables a user's VPN without alerting the
| user.
|
| Firewalling off their VPN service would cause a visible
| connection failure.
| ls612 wrote:
| So for this attack does the attacker need to control your
| internet router? Or does it only need to control ISP
| infrastructure?
| yjftsjthsd-h wrote:
| Pretty sure the attacker has to control your DHCP server, which
| in ex. a home environment is usually the router.
| tinco wrote:
| No, the attacker just has to be on the network. When on the
| network the attacker can deploy various techniques to become
| the DHCP server. Since it's (relatively) easy to become a
| DHCP server on a network, it's considered a big deal when the
| DHCP server can trick you into doing something like in this
| case decloaking your VPN traffic.
| ls612 wrote:
| What is the fix for this vulnerability? Is it the router
| that needs to get a software update, the VPN client, the
| OS, or some/all of the above?
| morattisec wrote:
| This is mostly correct, in our POC video we showcase a lab
| where we go from being an adjacent host on the network to
| being the DHCP server.
|
| We did this by DHCP starving the true DHCP server and
| hoarding all the leases. Then we serve our own and do not
| have to compete with the true DHCP.
|
| There's network protections against this such as guest
| network isolation or switches with DHCP snooping protections.
| However, those are usually on enterprises and relying on
| those being in place kind of removes the point of "securing
| an untrusted network" like many VPN providers claim.
| lsllc wrote:
| Many networking switches/systems (e.g. UniFi from Ubiquiti)
| let you enable DHCP Snooping which drops Layer 2 traffic from
| rogue DHCP servers to prevent this:
|
| https://en.wikipedia.org/wiki/DHCP_snooping
| tristor wrote:
| There 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.
| AnotherGoodName wrote:
| 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 from Australia with a VPN to an Australian server
| and lastly the standard home Internet wifi.
|
| It's super easy to do if you have a couple of old wifi routers
| and even cheap home ones seem to have some VPN support these
| days. A big advantage, aside from centralizing the VPN setup so
| you don't screw it up is that it's trivial to connect any
| device to the VPN. Just join the relevant wifi address! Boom
| I'm now in a VPN to Australia from any device without messing
| around setting up that device specifically because I connected
| to the 'Australia' wifi.
|
| I do this with multiple old routers but I actually think
| there's probably a market for a single home router that vpns to
| multiple locations in the world with a different wifi network
| for each of those just for the sake of easily having your
| TV/Roku/iPad appearing to be from somewhere else trivially.
| CommitSyn wrote:
| Is there a simple DIY? Is it as simple as running a custom
| router firmware or software on a small mini PC?
| wolverine876 wrote:
| If you could list some hardware and software, it would save us
| the effort ...
| Aloisius wrote:
| I'd imagine most travel routers are still vulnerable to this.
| k0ss_net wrote:
| I swore I had already read about this attack from some other
| author, so I went searching and after sifting through tons of VPN
| provider spam in search results I found the prior work [1].
|
| This new article goes into some more depth on how to exploit the
| flaw and has some code to help PoC it though.
|
| 1:
| https://www.usenix.org/conference/usenixsecurity23/presentat...
| gnabgib wrote:
| That article is referenced in the Appendix:
| However, neither technique described in the August 2023 paper
| leveraged DHCP option 121 to push routes. Pushing routes
| through DHCP has a significantly higher impact from the same
| attacker vantage point (the ability to hand out IP leases for a
| non-RFC1918 range or spoofing DNS replies).
| isodude wrote:
| You can also mitigate this by placing the VPN interface in a VRF
| on Linux. I.e. systemd-networkd have support for doing that out
| of the box. One thing to watch out or is that when enabling VRF,
| the ip rule entry for l3mdev is listed as 1000 but rule for local
| traffic is listed as 0, the local rule should be moved to 1000+.
| sargun wrote:
| Is there a way to run an app in a specific VRF nowadays?
| tuetuopay wrote:
| Just like with netns using ip: `ip vrf exec <vrf> <command>`.
| It's been available for a while now
| isodude wrote:
| Look here: https://jerryxiao.cc/archives/1004
|
| Yes, it's eBPF but the solution is quite neat to be honest.
| EasyMark wrote:
| I haven't seen anywhere that said there can be a "fix" for this
| outside of not allowing "option 121" to be in use at all the DHCP
| server. Is there no way to mitigate this in the VPN client, or is
| it simply too fundamental to the way the networks work that there
| is and never can be a "fix" on the VPN client? I wouldn't expect
| a malware laden network's "admin" to ever fix this or even hear
| about it.
| morattisec wrote:
| 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
| mitigations we saw were firewall based rules, which create a
| side-channel that be used to leak the destination of traffic.
| banister wrote:
| 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.
| banister wrote:
| Most decent VPNs are already protected against it. It's a
| simple firewall rule known as leak protection or a kill switch
| which blocks all off-VPN traffic including on option 121
| routes.
|
| This article is 99% FUD IMO.
| isodude wrote:
| I saw a github project that tries to make wireguard+netns more
| easy to setup: https://github.com/kalken/eznetns
| rnewme wrote:
| 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?
| isodude wrote:
| 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.
| jeroenhd wrote:
| > We noted that because Android does not implement support for
| DHCP option 121, it was uniquely unaffected.
|
| Phew, that was my biggest concern. This would've been pretty
| difficult to work around (as are Android's well-known VPN
| bypasses through system apps, but those need local execution
| privileges).
| mrbluecoat wrote:
| > 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..
| skissane wrote:
| 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.
| banister wrote:
| 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 already then
| it's likely already leaking so all this exploit demonstrates is
| that "A VPN without leak protection, leaks".
|
| I won't even mention the "side channel" attack as it's completely
| ridiculous.
|
| I liked your write-up and option 121 is a little known option, so
| it's good to know about. But let's not pretend this thing is
| bigger than it is.
___________________________________________________________________
(page generated 2024-05-06 23:00 UTC)