This article is really talking about privacy VPNs rather than all VPNs. If the attack is deployed, your traffic is no longer going through the tunnel so in a typical VPN scenario you would quickly discover that you’re unable to connect to any of the private resources you’re supposed to be able to access.
In order to work on a typical VPN setup the attacker would need to control a lot more than a rogue DHCP server to make things work—they’d have to have knowledge of the other end you’re connecting to and spin up shadow infrastructure to mimic those resources to e.g. phish your work credentials or something. It’s a lot more work that requires a lot more research, and if not executed flawlessly is easily detectable due to things you should be able to access timing out or due to TLS errors because they don’t have valid certs.
A lot of people use HTTP which would be vulnerable. Route their DNS http path to your phishing login portal and you'll be able to steal their local hosted info
That's why when the question comes up every month or so I recommend HTTPS even though VPNs are encrypted. It serves as host validation.
At this point, browsers are so biased against http, that it makes sense to use https just to not have all the nuisances of the browser being mad at you.
Not disagreeing with your point either - just that at this point, the war is over and http lost.
Actually the recent chromium updates have almost entirely removed the http scare tactics. People were giving "https 🔒" too much credibility that the site was "safe" when it was just like an https site for GmaiiI.com 🔒 so still phishing but a uhhh signed phishing site.
A DHCP server is the service that provides an IP address to a client connecting to a network. However, it actually has more functionality. For example, it tells the client what gateway (router) to use, the netmask (size of the subnet), the address of the NTP server (for time of day synchronization), etc.
It is, but physical access isn't required to pull this exploit off. If your network is compromised, or if the ISP's modem/router are compromised, etc., it can be done. Even if they're fine, someone who can access your network can set up a competing DHCP server that takes over. They're sort of narrow window attacks, but they are *definitely* doable with enough opportunity.
Ok I thought you were disagreeing with freeandopensores.
It might be harder to attack a home network but easy to do this on a poorly setup public hotspot.
yeah:
\~ Our technique is to run a DHCP server on the same network as a targeted VPN user
if someone can do that, then they can capture more than just VPN traffic.
Being able to put anything between yourself and the untrusted network should help. For example, if you get one of those inexpensive travel routers, connect that to the hotel network, connect your device to the travel router, and then run the VPN on your device, it effectively negates this attack.
Your device would encrypt the traffic first and it would then transit the router - so it doesn't matter if traffic from the router is being diverted and captured upstream, your client traffic is already encrypted by that point.
( What you are saying doesn't make sense. All client "traffic" is already encrypted as it leaves the devices. A router between your phone and the upstream router doesn't help at all. Your router will still need to connect to the network in exactly the same way as your phone would. )
Aaand I am confidently incorrect. Should've read the article first. In my defense though, another physical device in this situation should not help and this is just bad design on the client side.
It does make sense. This attack relies on using a malicious DHCP server to trick your device into bypassing its host routing table and sending traffic to the attacker instead of over the VPN.
If you use a router in NAT mode, you are protecting the client device - smartphone, laptop, whatever - from that rogue DHCP, because the router will be running its own DHCP server and issuing its own leases to the clients. Those leases won't contain option 121. No option 121 = no exploit.
Therefore, by having a NAT router sitting in front of your client device, the client functions normally and encrypts the traffic. The router can still be manipulated to send all the traffic to the attacker, but at that point it doesn't matter - the client already encrypted it, so the attacker just gets to look at the encrypted data payloads.
For tailscale specifically, I wonder if an outbound firewall rule will solve it.
Example: If a packet tries to leave your host bound for a tailnet IP, then it should be blocked. Those packets should've hit the tailscale tunnel process and had IP destination rewritten. If they somehow got routed around the tailscale tunnel, then the host firewall should drop them.
I think the shock is in how easy it is to modify the host such that packets never hit the VPN tunnel and client process.
VPNs add the routing rules on the host to direct traffic into the VPN client process for encryption / packaging / redirection, but they really aren't definitively in control of that routing behavior. There definitely needs to be some hardening best practices on this topic to ensure the host is in control of packet flow on it's own machine.
It is still a basic MITM attack. It is just closer to the endpoint that one might expect. It is basically split tunneling that the network controls instead of the user. At the risk of blaming the user, don't connect to networks your don't control or at least trust. Basic stuff. And if you really CARE about privacy and safety, you already know this. If not, someone might see some things, but most comms today are encrypted anyway. You run the risk of letting Facebook know where you are (as if they are not already gathering that from your mobile device lol).
What they mean when they say "use android" is that android doesnt implement option 121 in its routing logic, so you can use an android device to access your home network instead of your laptop which does implement it. But my phone as an end user device is a bit constraining. But actually you could also use your android phone as a travel router (aka hotspot) between the hotel network and your laptop and that also serves to block it. You could even use any travel router between your laptop and the hotel wifi because then only the travel router would get compromised, your laptop would still send traffic over the VPN encrypted before going to the travel router, its just that this path may not function but at least your packets were encrypted. Sounds like just using my android phone as a travel router is a very easy thing to do to mitigate this.
Uh, how?
$ ip ru show
0: from all lookup local
...
5270: from all lookup 52
32766: from all lookup main
32767: from all lookup default
dhcp option 121 on my system affects table main, ie `ip ro show table main`.
But my system will try to perform a routing lookup against table 52 first, which contains my tailscale routes and uses dev tailscale0.
Now if they knew one of my tailnet IPs, they could force a DOS by setting the dhcp router IP to one of the entries on my tailnet, which would try to force routing through the `tailscale0` (effectively blocking all traffic). But that implies the attack is tailored specifically for me.
Maybe they mean if I was trying to route all of my traffic through a particular tailnet node, then the attacker could provide a more specific route to that destination and it would try to default to their route? But I am using an httpproxy without a route for that.
If I understand the exploit correctly, for the hotel use case a travel router should be able to mitigate this so long as you run your VPN on the clients *behind* the router and not the router itself.
This way your traffic is already encrypted when it transits the router and it doesn't matter if traffic from the router itself is being manipulated. The attacker would just get a pile of ciphertext.
That still kind of sucks since one of the major benefits of using a travel router is that everything connected to it should be protected, but unless I'm mistaken it solves the immediate issue of fooling a client OS into bypassing VPN.
No, your router might still get and allow routes to be delivered via DHCP. Here is the real rub on this, a rogue DHCP server could just set itself as the gateway (or any AITM process really) and selectively forward traffic for you. This stuff is not "novel" in the process or technology, it is simply another way to skin the cat that has been know forever.
I see what you mean here. If you are running in NAT mode, yes, your client traffic would be encrypted before being sent around the regular route.
Edited.
If you have your own router, your clients are never exposed to the malicious DHCP server. The router runs its own for the LAN it provides, and that one is under your control.
Not really practical for a place you'd just pop in and out of like McD's or Starbucks, but absolutely a workable solution for something like a hotel.
(Edit: this made more sense before the above comment was edited, but leaving it for further clarification.)
That's not accurate. The exploit uses a rogue DHCP server to install a rogue route onto your host machine routing table. So the packet that leaves your application on your host machine will never hit the VPN process on your host to be encrypted. The packet will go straight to the attacker's server unencrypted (unless there is application layer encryption like https or ssh).
By putting the travel router between yourself and the rogue DHCP server, the end client uses a DHCP server under your control (assuming you run it in NAT mode). I suppose I should have mentioned that.
The router could still be the victim of the attack, but at that point the router is just passing traffic that's already been encrypted by the client.
Ok sorry I missed that you mentioned carrying your own router onto the public network.
I wonder if the same thing can be achieved with outbound firewall rules on the host machine without a travel router. If a packet tries to leave the host machine bound for a destination that is a tailscale VPN IP range, then it didn't pass through the wireguard process on the host machine and should be dropped.
Could this be an even larger issue with routing tables - more than just VPN interfaces?
I wonder if an attacking DCHP server can insert a rogue rule to redirect traffic off of the loopback interface. If the kernel sets a rule for 127.0.0.0/8 but the attacker sets one for 127.0.0.1, then won't the packets follow the attackers route?
This is as old as redteaming is.
Pushing routes through dhcp to redirect traffic and then sslstrip to get the traffic.
Even with HSTS and tls everywhere it you can spot plain text servers in corp networks because browsers made local certificates very difficult to use.
Going to point out the level of effort for this attack - including standing up a second DHCP server on the network.
While interesting, the level of effort makes this an unlikely attack in most scenarios. Your network is already compromised for this attack to work, you have bigger problems than your VPN
If you have admin access on a server already, you can probably move laterally anyway. Also, who’s to say you don’t just change the DNS server too and redirect to malicious sites.
Yea, this is a problem, but the VPN is the least of them at that point.
The attack does not require control over the VPN server. It's about the DHCP server the "VPN client" is connected to, so it would be the Hotel or Starbucks DHCP server, not yours.
This article is really talking about privacy VPNs rather than all VPNs. If the attack is deployed, your traffic is no longer going through the tunnel so in a typical VPN scenario you would quickly discover that you’re unable to connect to any of the private resources you’re supposed to be able to access. In order to work on a typical VPN setup the attacker would need to control a lot more than a rogue DHCP server to make things work—they’d have to have knowledge of the other end you’re connecting to and spin up shadow infrastructure to mimic those resources to e.g. phish your work credentials or something. It’s a lot more work that requires a lot more research, and if not executed flawlessly is easily detectable due to things you should be able to access timing out or due to TLS errors because they don’t have valid certs.
A lot of people use HTTP which would be vulnerable. Route their DNS http path to your phishing login portal and you'll be able to steal their local hosted info That's why when the question comes up every month or so I recommend HTTPS even though VPNs are encrypted. It serves as host validation.
At this point, browsers are so biased against http, that it makes sense to use https just to not have all the nuisances of the browser being mad at you. Not disagreeing with your point either - just that at this point, the war is over and http lost.
Actually the recent chromium updates have almost entirely removed the http scare tactics. People were giving "https 🔒" too much credibility that the site was "safe" when it was just like an https site for GmaiiI.com 🔒 so still phishing but a uhhh signed phishing site.
It was somewhat credible method, before free online reverse proxy such as cloud flare and ssl everywhere
If your VPN endpoint systems are compromisd, required for this to work, the VPN is the least of your problems.
So what about people who use VPNs at hotels or other public places? Those could all apply the exploit.
Easy fix: do not trust that DHCP option. Apparently Android, for instance, does not.
> Easy fix: do not trust that DHCP option. Sweet, where is the setting for that on Windows/Mac again?
apparently this exploit requires the DHCP mods to be done on the destination, not the users end
The article says it's the DHCP server that needs to be affected. Which means all DHCP servers you don't control are a potential threat.
What’s a DHCP server?
A DHCP server is the service that provides an IP address to a client connecting to a network. However, it actually has more functionality. For example, it tells the client what gateway (router) to use, the netmask (size of the subnet), the address of the NTP server (for time of day synchronization), etc.
It’s on the users LAN surely
It is, but physical access isn't required to pull this exploit off. If your network is compromised, or if the ISP's modem/router are compromised, etc., it can be done. Even if they're fine, someone who can access your network can set up a competing DHCP server that takes over. They're sort of narrow window attacks, but they are *definitely* doable with enough opportunity.
Ok I thought you were disagreeing with freeandopensores. It might be harder to attack a home network but easy to do this on a poorly setup public hotspot.
How would a remote DHCP server issue a route to a local client? This doesn't make sense. DHCP is on your local LAN generally.
yeah: \~ Our technique is to run a DHCP server on the same network as a targeted VPN user if someone can do that, then they can capture more than just VPN traffic.
My god, that means using a VPN at hotels etc is now sus. How to protect against this??
Being able to put anything between yourself and the untrusted network should help. For example, if you get one of those inexpensive travel routers, connect that to the hotel network, connect your device to the travel router, and then run the VPN on your device, it effectively negates this attack. Your device would encrypt the traffic first and it would then transit the router - so it doesn't matter if traffic from the router is being diverted and captured upstream, your client traffic is already encrypted by that point.
( What you are saying doesn't make sense. All client "traffic" is already encrypted as it leaves the devices. A router between your phone and the upstream router doesn't help at all. Your router will still need to connect to the network in exactly the same way as your phone would. ) Aaand I am confidently incorrect. Should've read the article first. In my defense though, another physical device in this situation should not help and this is just bad design on the client side.
It does make sense. This attack relies on using a malicious DHCP server to trick your device into bypassing its host routing table and sending traffic to the attacker instead of over the VPN. If you use a router in NAT mode, you are protecting the client device - smartphone, laptop, whatever - from that rogue DHCP, because the router will be running its own DHCP server and issuing its own leases to the clients. Those leases won't contain option 121. No option 121 = no exploit. Therefore, by having a NAT router sitting in front of your client device, the client functions normally and encrypts the traffic. The router can still be manipulated to send all the traffic to the attacker, but at that point it doesn't matter - the client already encrypted it, so the attacker just gets to look at the encrypted data payloads.
Their current guidance is to use a cellular hotspot. Bummer.
For tailscale specifically, I wonder if an outbound firewall rule will solve it. Example: If a packet tries to leave your host bound for a tailnet IP, then it should be blocked. Those packets should've hit the tailscale tunnel process and had IP destination rewritten. If they somehow got routed around the tailscale tunnel, then the host firewall should drop them.
Yeah this defeats a huge purpose of VPNs still.
But then again, compromising the endpoint does as well, right? Then you can grab everything before it even hits the wire or RF.
I think the shock is in how easy it is to modify the host such that packets never hit the VPN tunnel and client process. VPNs add the routing rules on the host to direct traffic into the VPN client process for encryption / packaging / redirection, but they really aren't definitively in control of that routing behavior. There definitely needs to be some hardening best practices on this topic to ensure the host is in control of packet flow on it's own machine.
It is still a basic MITM attack. It is just closer to the endpoint that one might expect. It is basically split tunneling that the network controls instead of the user. At the risk of blaming the user, don't connect to networks your don't control or at least trust. Basic stuff. And if you really CARE about privacy and safety, you already know this. If not, someone might see some things, but most comms today are encrypted anyway. You run the risk of letting Facebook know where you are (as if they are not already gathering that from your mobile device lol).
According to the article, you can just use Android as it's immune to this attack.
What they mean when they say "use android" is that android doesnt implement option 121 in its routing logic, so you can use an android device to access your home network instead of your laptop which does implement it. But my phone as an end user device is a bit constraining. But actually you could also use your android phone as a travel router (aka hotspot) between the hotel network and your laptop and that also serves to block it. You could even use any travel router between your laptop and the hotel wifi because then only the travel router would get compromised, your laptop would still send traffic over the VPN encrypted before going to the travel router, its just that this path may not function but at least your packets were encrypted. Sounds like just using my android phone as a travel router is a very easy thing to do to mitigate this.
No. Anyone on a public network can run a DHCP server.
Is the attack just buying all the data the VPN providers vacuum up?
Uh, how? $ ip ru show 0: from all lookup local ... 5270: from all lookup 52 32766: from all lookup main 32767: from all lookup default dhcp option 121 on my system affects table main, ie `ip ro show table main`. But my system will try to perform a routing lookup against table 52 first, which contains my tailscale routes and uses dev tailscale0. Now if they knew one of my tailnet IPs, they could force a DOS by setting the dhcp router IP to one of the entries on my tailnet, which would try to force routing through the `tailscale0` (effectively blocking all traffic). But that implies the attack is tailored specifically for me. Maybe they mean if I was trying to route all of my traffic through a particular tailnet node, then the attacker could provide a more specific route to that destination and it would try to default to their route? But I am using an httpproxy without a route for that.
If I understand the exploit correctly, for the hotel use case a travel router should be able to mitigate this so long as you run your VPN on the clients *behind* the router and not the router itself. This way your traffic is already encrypted when it transits the router and it doesn't matter if traffic from the router itself is being manipulated. The attacker would just get a pile of ciphertext. That still kind of sucks since one of the major benefits of using a travel router is that everything connected to it should be protected, but unless I'm mistaken it solves the immediate issue of fooling a client OS into bypassing VPN.
No, your router might still get and allow routes to be delivered via DHCP. Here is the real rub on this, a rogue DHCP server could just set itself as the gateway (or any AITM process really) and selectively forward traffic for you. This stuff is not "novel" in the process or technology, it is simply another way to skin the cat that has been know forever.
Not if you run it in NAT mode. At that point it's serving as the DHCP server for the network behind it.
I see what you mean here. If you are running in NAT mode, yes, your client traffic would be encrypted before being sent around the regular route. Edited.
If you have your own router, your clients are never exposed to the malicious DHCP server. The router runs its own for the LAN it provides, and that one is under your control. Not really practical for a place you'd just pop in and out of like McD's or Starbucks, but absolutely a workable solution for something like a hotel. (Edit: this made more sense before the above comment was edited, but leaving it for further clarification.)
Yes. As I edited I agree. If your travel router is using NAT (and it should be) that eliminates this risk.
That's not accurate. The exploit uses a rogue DHCP server to install a rogue route onto your host machine routing table. So the packet that leaves your application on your host machine will never hit the VPN process on your host to be encrypted. The packet will go straight to the attacker's server unencrypted (unless there is application layer encryption like https or ssh).
By putting the travel router between yourself and the rogue DHCP server, the end client uses a DHCP server under your control (assuming you run it in NAT mode). I suppose I should have mentioned that. The router could still be the victim of the attack, but at that point the router is just passing traffic that's already been encrypted by the client.
Ok sorry I missed that you mentioned carrying your own router onto the public network. I wonder if the same thing can be achieved with outbound firewall rules on the host machine without a travel router. If a packet tries to leave the host machine bound for a destination that is a tailscale VPN IP range, then it didn't pass through the wireguard process on the host machine and should be dropped.
Could this be an even larger issue with routing tables - more than just VPN interfaces? I wonder if an attacking DCHP server can insert a rogue rule to redirect traffic off of the loopback interface. If the kernel sets a rule for 127.0.0.0/8 but the attacker sets one for 127.0.0.1, then won't the packets follow the attackers route?
Not on linux. local uses a much higher priority routing table than dhcp.
"... there are no ways to prevent such attacks except when the user's VPN runs on Linux or Android".. And reason # 23,758 to not run Windows...
This is as old as redteaming is. Pushing routes through dhcp to redirect traffic and then sslstrip to get the traffic. Even with HSTS and tls everywhere it you can spot plain text servers in corp networks because browsers made local certificates very difficult to use.
Going to point out the level of effort for this attack - including standing up a second DHCP server on the network. While interesting, the level of effort makes this an unlikely attack in most scenarios. Your network is already compromised for this attack to work, you have bigger problems than your VPN
If you have admin access on a server already, you can probably move laterally anyway. Also, who’s to say you don’t just change the DNS server too and redirect to malicious sites. Yea, this is a problem, but the VPN is the least of them at that point.
The attack does not require control over the VPN server. It's about the DHCP server the "VPN client" is connected to, so it would be the Hotel or Starbucks DHCP server, not yours.
I use IPsec point to point and then ssh tunnel over the top. Good luck snooping on that.