Watch out for rogue DHCP servers decloaking your VPN connections A newly discovered vulnerability undermines countless VPN clients in that their traffic can be quietly routed away from their encrypted tunnels and intercepted by snoops on the network. Dubbed TunnelVision by the eggheads at Leviathan Security Group who uncovered and documented it, the technique (CVE-2024-3661) can result in a …
I’m no networking expert but I suspect that your travel router will request DHCP from the public network when it joins. At that point it becomes vulnerable and your DNS traffic can be sniffed. Although I’m guessing it will be easier for you to configure your router to avoid this (by disabling option 121) rather than trying to configure your OS.
Never heard of travel routers, sounds cool.
What I don’t get is how the rogue DHCP server is issuing valid sessions to clients. If the public wi-if network had a proper DHCP server correctly issuing IP addresses to guests, then the rogue DHCP server joins, how can that rogue issue valid IP addresses? Maybe the rogue first pretends to be a guest to find out what the next valid address is but this article didn’t make that sound likely. I need to do some reading but this problem sounds unfixable for some time to come. I’m staying at home.
"What I don’t get is how the rogue DHCP server is issuing valid sessions to clients."
Pretty simple. Two options. The first one is a rogue admin compromising the real/only DHCP server of the network. From the hollywood scenario of an uber-hacker spy posing as a maintenance employee in the cozzy little cafe frequented by the target to insert a rouge DHCP, to the more likely scenario in poor countries of a spy bribing an employee to look the other way for 10 min.
The second one, which is the one you probably are most curious for: the normal behaviour of DHCP is that the client broadcasts a DHCP request, and there may be more than one DHCP server in the network, any or all of them can answer, and is to the client to choose which request to accept, however it sees fit.. Most clients go for fist answer.
If your rogue DHCP server can answer faster than the network's real one, you are golden.
This can be prevented by using client issolation in the AP/router, but then your laptop will not be able to chromecast to the smartTV in the room. And in the case of CyberCafees, they will forget the setting, or will not use it because they are using the same AP (with different SSIDs and passwords) for internal and guest traffic... Also preventable by configuring the Eth switch or router to drop all DHCP response packages not originationg from the IP/MAcAddr/port of the real DHCP server (preffer the port, the IP can be spoofed) . Not all Eth switches or routers can do this.
As for the valid leases, many a provider of prosumer gear (say, the router for a small cafe) and pro gear (say, the router for a medium hotel), send the gear pre-configured to assign addresses in the 10/8 or 172.16/12 range. Plenty of addresses to spoof without fearing you assigning an address already used. Double points if an attacker maps the network beforehand. And even if you are in 192.168/16, more often than not, there is a bunch of addresses reserved, outside of the DHCP range, for things that need a static IP address (like servers, printers and such).
Heck,the rogue router can even dish addresses in an address range different from the one the network uses (if the hotel wifi uses 10/8 you can dish addresses in 172.16/12) but that means you have to provide other services aside from DHCP, including NAT, and that is on top of the horsepower needed to Spy the traffic. That Workstation replacement laptop the attacker is using will start to struggle, and be noticed like a sore thumb amid the fan noise ;-)
> What I don’t get is how the rogue DHCP server is issuing valid sessions to clients.
Lets say that the rogue DHCP server initially joins the network as a client, then cycles through a bunch of valid looking MAC addresses and requests all the IP numbers that the real DHCP server can provide. Now that knows all the IP addresses that it can allocate (for the lease duration), it changes into a DHCP server and hands out fully valid IP addresses with whatever options that it wants (including increasing the lease duration). The real DHCP server ran out of free IP addresses, so it is not like it can respond to any new clients DHCP requests, so the rogue DHCP server is the only DHCP server that can respond to requests for at least the lease duration.
Then you are safe. That case is similar (almost equal) to using a VPN inside a VM with a NON-Bridged adapter.
DHCP option 121 works by over-riding the routing tables if your machine. If your t-router connects to the network, the T-ROUTER's tables will be infected, but, when your laptop gets a DHCP lease fromn the t-router, the LAPTOP's routing tables are not altered.
I'm actually curious about whether Windscribe is vulnerable on Windows. It can override the OS DNS options with options like OpenDNS, Cloudflare, or their own DNS service. Granted someone could always covertly poison those servers, but ostensibly they're employing some sysadmins to monitor for things like that, so it's at least less likely compared to some public wifi at a McDonalds or an airport where it's unlikely anyone's paying any attention to it unless it goes down, and then all they do is powercycle it.
This is an issue with DHCP, not DNS. Even if your VPN software specifies it's own DNS servers, those requests can still be re-routed by an attacker, along with any other traffic. Allowing them to at least monitor all your communications, even if they can't easily decrypt things like HTTPS.
I can never figure out this "classless" business. Does that mean that original option 33 "Static Route Option" does not present the same problem?
In any case, option 121 ("classless static routes") was added because it had already been implemented by DHCP servers as a private option: for MS, it was option 249 before it was standardized as 121. All your old (95, NT, 2K, 2003, XP) Windows DHCP clients will support 249, not 33 or 121.
¿remember that there were class A (/8 addresses), class b (/12), class c (/16) and class d (/8) addresses?
Well that was very inneficient (my university has a /16, even if we do not need more than 1000 addresses, but at the time we got our assignment, the classless system was not invented yet)
Since there were only 4MM IP addresses and many were reserved for stuff like multicasting, something had to be done, the solution was the classless address sytem, were things like a /10 address space could be givem to an organization that only needs 1000 addresses (like my university).
Problem was, routing that stuff was quite hard, so, new infrastructure and methods to assign and route that stuff was needed.
Tanenbaum's book on networks has a great explaining on it.
This is one of those rather naff "security as theatre" things. Note how nauseatingly long the blog post is, with silly graphics - its thesis can be boiled down to one sentence (own your routing tables). Its all about fiddling with routing tables and sod all to do with VPNs but by pulling in VPNs this nonsense gets on a few front pages.
If you don't control your network, then you might not own your network. Obvs.
What a load of tosh. It would be nice if, instead of trying to gain internet points with a fright night article, they simply spelled out how routing tables can be abused and here is our recommendations on how to fix it.
I utterly despise this sort of wankery.
Surely the "official" DHCP server will suddenly start seeing traffic from addresses it knows it didn't issue ?
At which point some sort of alert thingy could be flagged up ?
Also my experience of multiple DHCP servers on the same network is that it causes almost instant network failure. Certainly did when we allowed laptops running Windows Server with DHCP enabled t connect to our guest network.
Also my experience of multiple DHCP servers on the same network is that it causes almost instant network failure.
It depends what parameters those DHCP servers are set up to allocate to their clients, doesn't it, it's not the mere fact of having multiple DHCP servers that causes an issue. If your laptops are setting themselves up as the default gateway and DNS server for clients they serve, when they can not, in fact perform those functions usefully, then yes, it will cause network failure. However, if they were handing out working gateway and DNS settings, and were taking care not to allocate IP addresses that already exist on the network, problems would be much less noticeable, although you'd probably end up with IP address conflicts sooner or later. But if you're running a nefarious DHCP server that you don't want people to notice, you're going to make sure that clients do have a configuration that *appears* to work normally, and that's seems perfectly doable. At least, that's how it looks to me, I'm not a networking guy.
Surely the "official" DHCP server will suddenly start seeing traffic from addresses it knows it didn't issue ?
It would be the same effect as if you'd set up a device on a static IP.
Furthermore, in an attack on a simple network (eg free wifi in a cafe), the attacker would probably route all traffic through their machine for inspection, before forwarding it on to the correct router. So the only sign would be that all traffic would appear to be coming from a single client.
Even then, an attacker could request multiple IPs from the 'real' DHCP server (possibly as part of requesting all the DHCP addresses it can grant, so it won't interfere with the attacker's rogue DHCP server), and route outgoing traffic over multiple IPs so it would all look pretty normal.
On my (now very old) Windows network, when the windows DHCP server notices a rogue DHCP server, it goes offline and there is a message in the server log. I won't notice it at all until things fall off the network.
It's not unknown for residential routers to power up in pass-through mode, request a DHCP address from the ISP, and leak the response onto the internal network, before the firewall and netmask come up.
It's worse than that. Part of the DHCP spec allows it to push a static route that is guaranteed to have a higher priority than your VPN gateway. A malicious actor can use it so your OS never sends your network traffic to the local VPN entry point but instead to the rogue network.
This post has been deleted by its author
My limited understanding of E2EE is that encryption occurs before it leaves the device, be it a cell phone or desktop.
If intercepted as described in the article there’s only an unencrypted file to look at.
If this is all true then maybe ensure the important communication is all performed using E2EE?
Yes, if you are using E2EE (or even HTTPS), the data is encrypted before it leaves THE APPLICATION (which is even better than the device). So, yes, Is important to use as much E2EE as possible.
Still:
1.) there may be holes/weaknesses in the Encryption. For instance, if a website has both an HTTP and an HTTPS variant which have the same static data, it means that we can get encryped and decripted data for the site, leading to a cryptographic attack (see point 4)
2.) The app may be misconfigured.
3.) A MITM Attack may be performed.
4.) Even in E2EE Scenarios, there is info that is exfiltrated in plaintext, for instance, the IP and port of the receiving device, and, to give a concrete example, in HTTPS, the Address of the WebPAge goes as plaintext, therfore, can be either censored or logged by the attacker.
So, E2EE is not a cure-all.
Bulk surveillance will probably not be possible using this vuln, but spying on high-value tragets probably is.
On large campuses DHCP requests were (are) often relayed by the switches back to the enterprise DHCP service(s) so there is usually enough latency for a rogue DHCP server to get in first. Saw this a few times when students (and those who should have known better) would connect a cheap wifi modem/access point to the lan for wifi access to the campus network. I used to run dhcp_probe to flush out the culprits. :)
Saw it again ten years later long after campus wide wifi had be deployed when a student (?) plugged his phone into his computer to charge and the phone started handing out dhcp leases to the lan that his computer was connected to. Never did find out the details as it was "rectified" by others to save someone further embarrassment I suspect. :)
If you can get dhcp server onto a lan segment and the clients trust its leases and options you are pretty much done. :)
I suppose you could do something with IEEE 802.1x port security but I have never been anywhere •1x has been implemented for wired ethernet. :(
Another issue is that most DHCP servers and deployments aren't aggressively performance tuned. Attack code can be, and a whole host of 20 year old layer 2 attacks have shown that at the scale of an attacker on the local network, it is easier to speed optimize most attack code than a fully compliant and general purpose server for most network services.
The nut of it is a valid server needs to do stuff like integrity checks, while an attacker needs to get the first packet in. If they do then they become the MITM and can potentially spoof traffic to fool a vailid DHCP server. Defensively you'd probably need to be sniffing the local traffic on the wire to spot it.
This is another example of relying on old protocols from before the existence of a robust security model. Blind trust in the results of and ARP, DHCP, or DNS request break the security of too many of the bolt on security measures we have tacked on to IP networks. This problem extends up to the CA/SSL model, where any CA can sign or spoof a cert that will flag as trusted, even if that CA is run by the government of a hostile nation. That system is also totally dependent on flawed assumptions about DNS being trustworthy.
(as a side note, 802.1x is kind of a hot mess, as the connection setup time is kind of awful. On wireless networks where roaming is happening, repeated 802.1x negotiations will convince your users your wifi is broken or the internet is down on a daily basis. Expect revolt under those circumstances. That's what happens when it's all dependent on a dino like RADIUS...)
Of course, the simple answer to this (and other DHCP based attacks) is to harden your LAN. These days you don't need to be all that far up the feature tree for a network switch to include things like filtering DHCP packets from bogus servers. Turn this on for every port except your own authorised DHCP server(s) and the problem disappears. That doesn't help users on other networks where the operator wouldn't know what DHCP is, let alone how to mitigate such risks - so most non-corporate networks then.
And of course, that's where the big risks lie. As a responsible security minded organisation (or just pro level home admin) you can properly configure you own network, and configure your user devices - but when your user goes and connects to ${random_wifi} you lose that control.
Sorry, this ais a load of bollocks.
The crux of the argument is that if you accept unsolicited routing directives from your lan, then they can be set to divert traffic to another system.
Well, duuuh
We were playing with this sort of thing 30 years ago.
No system I use, or have ever set up would be vulnerable to this, and that's would be across many operating systems.... even windows!
A better summary for this article could be "Incorrectly configured computers can behave incorrectly"
And as is so often the case, I'm glad it "works for you" but not everybody has enough control over the devices they use to fully secure them from these issues.
So it would be better to beat up the vendors to provide people a secure configuration out of the box, warnings about potentially dicey settings being offered when a device connects to a network, and access to the settings needed to resolve them.
If the devices you use and the networks you use them on are fully secure, great. I'll even applaud you for already having locked yours down. Maybe share that expertise instead of mocking people. But don't forget that is explicitly not true for most people, and many of them are using devices where they CAN'T fully lock the settings down from their side. Not knowing that can get good people hurt, arrested or killed in some parts of the world. I hope you are lucky enough not to live in one, but not everyone reading this probably is.
So don't pretend there isn't a place for and utility in articles like this.
You totally miss the point, in more than one way.
1) I wasn't mocking users, I was mocking the over-sensationalist way that the report (not this Reg article, but the original one that was being reported in) was written.. "ALL OS's AFFECTED (but android)". "NO WAY TO FIX IT". "RECENTLY DISCOVERED VULNERABILIITY" etc.
Crying wolf like that desensitises people to REAL issues.
2) Relating to criticising the sensationalist report, I was criticising any vendors who would be taken in by such a basic gaffe. I don't expect users, presented with a "plug and go" solution to assume anything is wrong. I grew up in a household of tech-illiterate people (maybe I was swapped at birth), and I would never expect them to understand this sort of thing.
If it was reported that some critical software was released with a stupidly basic vulnerability gaffe, and it was treated as almost the end of the internet world that couldn't be fixed, and someone replied "errr, thats' daft. it can be fixed, just by logging in and changing the password", would you chastise them for criticising the end users, or the hype of the report, and the stupidity of the programmers.?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
