When connected to a hostile network.
All networks will become hostile. Airport/airplane wifi is no longer safe as a simple example.
Attackers can decloak routing-based VPNs
111–120 of 238 posts
Re: Attackers can decloak routing-based VPNs
#112This is a slight variation on the "Poison Tap" attack from Samy Kamkar in 2016, where you do the same thing but with a USB/Thunderbolt network adapter. You plug it into the victim device, advertise two more specific routes of 0.0.0.0/1 and 128.0.0.0/1 and then you get all the traffic in preference to other system interfaces despite interface ordering: https://github.com/samyk/poisontap I imagine there is also probabl…
Well said. This is a nothing-burger for all VPNs except the ones that are likely heavily leaking already due to the absence of basic firewall rules.
Their "side channel attack" also made me spit out my drink.
EDIT: looks like NordVPN (at least on mac) doesn't have those basic firewall rules and so IS vulnerable to this exploit.
Re: Attackers can decloak routing-based VPNs
#113Earlier quoted context omitted.
You wrote three different ways to end up with all traffic dropped and a broken VPN connection. Traffic sent to the VPN interface gets encapsulated by the VPN client software and then routed to the Internet. If your firewall rule is dropping all traffic not destined for the VPN interface, it will drop the encapsulated traffic. You need two (sets of) rules: one allowing traffic on the VPN interface and one allowing tra…
Yes. I just provided simplified firewall rules in my answer. You also need to whitelist either the VPN endpoint itself (and add a route to that endpoint) or you need to whitelist the process (such as wireguard or openvpn) that hits that endpoint. Not sure how a DHCP server is relevant in the slightest here except for the initial host network config of course. But the host network should already be configured before t…
If you're connected to a random network, whose configuration you don't know in advance, how do you route packets to your VPN server?
The usual answer is that the network's router tells you how to do that, by supplying DHCP options.
The point I'm making here is that you can't just configure a firewall rule and have it work properly. What actually needs to happen is that the VPN client software is using one routing table - let's call it "host routing" - and everything else on the system is using a second routing table - let's call that "VPN routing".
The DHCP server inserts rules into the host routing table, and the only software using those rules is the VPN client for its management and tunnel traffic.
Otherwise, what if the network to which you connect says "the next hop for all internet traffic is 10.10.10.10"? You need to respect that rule when sending traffic to your VPN server, and ignore it for applications whose traffic will be tunneled.
Re: Attackers can decloak routing-based VPNs
#114Earlier quoted context omitted.
Pretty sure the attacker has to control your DHCP server, which in ex. a home environment is usually the router.
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…
You should play with IPv6, you can bypass IPv6 RA Guard on some switches (including Cisco) https://blog.champtar.fr/VLAN0_LLC_SNAP/, allowing attacks in 'trusted' networks
Re: Attackers can decloak routing-based VPNs
#115Earlier quoted context omitted.
Pretty sure the attacker has to control your DHCP server, which in ex. a home environment is usually the router.
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
I invite you to not trust blindly L2 security features, anything that use denylist approach can miss some corner cases, have a good read :) https://blog.champtar.fr/VLAN0_LLC_SNAP/
Re: Attackers can decloak routing-based VPNs
#116Earlier quoted context omitted.
Yes. I just provided simplified firewall rules in my answer. You also need to whitelist either the VPN endpoint itself (and add a route to that endpoint) or you need to whitelist the process (such as wireguard or openvpn) that hits that endpoint. Not sure how a DHCP server is relevant in the slightest here except for the initial host network config of course. But the host network should already be configured before t…
If you're connected to a random network, whose configuration you don't know in advance, how do you route packets to your VPN server? The usual answer is that the network's router tells you how to do that, by supplying DHCP options. The point I'm making here is that you can't just configure a firewall rule and have it work properly. What actually needs to happen is that the VPN client software is using one routing tab…
Let's walk through this step by step because there's a lot of confusion on your end.
* Step one - You connect your computer to a network - yes you'll get a DHCP lease, and you'll get an ip address, and a default gateway. This default route will be added to your routing table.
* Step two - If the TunnelVision exploit (DHCP option 121) is at play you'll also get a few MORE SPECIFIC routes than the default gateway. These also get added to your routing table
* Step three - You connect your VPN. The VPN will bring up a firewall. It will also bring up `128/1` and `0/1` routes that point at the VPN tunnel. The VPN tunnel now takes over the default route. This firewall will block all traffic that's not on the tun device (the VPN interface). Further, it will whitelist the VPN endpoint IP and create a route for it (it can do this since it already received the default gateway from the DHCP server)
* Step four - Your host starts sending traffic - either this traffic will go through the VPN tunnel (the default route) OR it will attempt to go through the more specific option 121 pushed malicious routes added by the compromised DHCP server (depending on the destination ip of the outbound packets).
* Step five - All traffic that would go down the malicious option 121 routes are BLOCKED by the firewall rule. Hence nullifying the TunnelVision exploit.
That's all. Done. Where's the complexity in that? As i said before i've done this dozens of times. I'm talking from experience. I know this works.
Further you say:
> The point I'm making here is that you can't just configure a firewall rule and have it work properly. What actually needs to happen is that the VPN client software is using one routing table - let's call it "host routing" - and everything else on the system is using a second routing table - let's call that "VPN routing".
You are aware we're talking about consumer VPNs right? The majority of users are on Windows and Mac. Neither of those OSes support multiple routing tables. Only Linux supports multiple routing tables.
You're also just plain wrong - as i demonstrated above - you CAN just configure a firewall rule and it WILL just work properly. Again, i'm talking from experience.
Re: Attackers can decloak routing-based VPNs
#117The 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..
"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.
That's not at all guaranteed. The residential gateway most likely contains a hardware switch and a CPU, which also does the routing. The CPU is attached to the switch like any other device, though probably with less physical-layer bits, and some of them aren't all that fast.
Re: Attackers can decloak routing-based VPNs
#118You 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+.
Is there a way to run an app in a specific VRF nowadays?
[deleted]
Re: Attackers can decloak routing-based VPNs
#119This is a perfect example of the CVE mining. There is nothing novel in the attack nor it's a security problem. DHCP environment must be trusted. We do have IP Source Guard and DHCP Snooping for decades to avoid scenarios from that link ( and many other).
I have never heard anyone claim that VPNs only work if DHCP can be trusted. Note that that means trusting all devices on a network because any device can be a DHCP server. This is a great find and a real security bug. I cannot believe how many people are downplaying this work.
It has nothing to do with VPN. Attack on the mined CVE is a general type of the malicious DHCP attack described in any CCNA level book since 90s.
Re: Attackers can decloak routing-based VPNs
#120Earlier quoted context omitted.
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…
Just accept you were not the target audience and skim like the rest of the world. Not every article is written for you. It's available for you to read, but was more than likely not with you in mind. Some of us still like words and the reading of them when they provide details and more in-depth understanding than a tweet.
I hate tweet culture as much as anybody, but this is not the alternative. This article is so painfully long, I got bored even just trying to skim it. Reading it word for word will turn any noob into a seasoned greybeard through the sheer passage of time. If you really like words and reading them this much, I'd recommend adding some dictionaries to your reading list.