SN 973 - DHCP Option 121 "fix"

[mikebarber1]

@Steve - Regarding SN 973 and DHCP Option 121 / CVE-2024-3661

When using public or otherwise untrustworthy WiFi using a travel router should protect you.

If you have the travel router connect to the public / untrustworthy WiFi and then have your device connect to the travel router - your device will only see DHCP responses from the LAN side of the travel router. A malicious actor can publish whatever routes they want with Option 121 - those routes will not leak past the NAT of the travel router and thus protect you.

It's more friction to power up a travel router and connect to it and then login to the routers web interface and get it to connect to the public WiFi but making yourself more secure usually is more painful than not. When in a hotel I always have my travel router with me and it works like a charm.

 

[coffeeprogrammer]

I have used some DHCP options in the past on my own network. Windows Server makes it easy to use DHCP options. I was not aware of option 121. However, I have setup machines with multiple network connections. Mostly because I commonly use air gaped networks. I have used the route command to change and view the routing table. In fact, I might try and use option 121 because it could make things easier to setup. As far as being aware when something like Steve described, I think you would see it using the route print command. Below is a screen shot of route print from one of my machines. You can see that the network destination of 0.0.0.0 (the public internet) is gateway 192.168.40.1.

In what Steve described, I think what you would see is a network destination that would be the public internet IPv4 space, but would be destination as something other than 0.0.0.0. That network destination would then have a high priority than the network destination of 0.0.0.0, which during a VPN connection, would be your VPN providers gateway. In the screen shot below it is simply the locate router 192.168.40.1

So to put it simply, if you have more than one public internet destination, then you have a problem. At least that is what I think he was saying. Someone else can chem in with what they think.

 

[coffeeprogrammer]

I guess that does not fully answer you question, if your travel router gets it IP addresses that same as your laptop would, I think it would also have to have a routing table, therefore it could still filter specific IP to not use a VPN connection. One possible solution might be to use a virtual machine and then bridge it to the VPN adapter rather than your physical adapter. That is just an idea, I am not sure how the details would work out. I would start by understanding the output of the route print command. I also wonder if you could use wireshark and set it to filter on any packets leaving the physical network interface that are NOT going to the VPN provider. If you known the VPN providers gateway then all traffic leaving the the network interface should be going to their gateway and no where else on the public internet. Just a thought, not sure if the details work out.

 

[mikebarber1]

@coffeeprogrammer You're right the route table on the travel router would get polluted by malicious DHCP Option 121.

The computer behind the travel router is still safe if using VPN because the routing table on the system behind the router doesn't know about the routes on the travel router. The external (maybe malicious) DHCP do not telegraph thru the travel router. The LAN side of the travel router has it's own DHCP server and isn't going to pass along the Option 121 values it may have received when it asked for an address on the public WiFi.

Option 121 only breaks VPN because a malicious actor is able to influence the routes on the system running the VPN. In my scenario the travel router isn't running VPN - it's the system behind the router. Since there are no bogus routes - everything still gets routed into the VPN tunnel.

Upstream of the travel router even if the traffic is intercepted via Option 121 shenanigans all they're going to see is encrypted garbage.

 

[coffeeprogrammer]

Ok, that makes sense. For some reason I was thinking the travel router would be running the VPN client. One thing a person could be is try and set up such a route on purpose. For example, if you used a VPN providers software for Windows, loaded and connected to a VPN server. After which you added a entry in the routing table to the Sheilds Up server for your normal network interface and then did a Sheilds Up scan, I think Shields Up would see you ISP public IP and not your VPN providers. Again, not sure if the details work out, but the route command is not that hard to use, so just figure out what the Shields Up servers IP is and test.

 

[Mervyn Haynes]

What if the computer is using static IP addresses & not DHCP. Would that stop this problem of option 121? I am talking about home systems, not the hotel scenario.

 

[PHolder]

I am talking about home systems, not the hotel scenario.

If you have a rogue DHCP server on your LAN, you've got some serious issues with your network and you should maybe address them first before worrying about routing out of the network.

 

[Mervyn Haynes]

If you have a rogue DHCP server on your LAN, you've got some serious issues with your network and you should maybe address them first before worrying about routing out of the network.

I understand that, my question rephrased is, if you did have a rogue DHCP on your home network, but all the computers were using static IP addresses (not using the DHCP), could that stop the option 121 issue, or does DHCP still take effect even if it is not setting your IP NM DG & DNS.

 

[PHolder]

or does DHCP still take effect even if it is not setting your IP NM DG & DNS

That would be a platform specific question, I suspect. On Windows, my best GUESS is yes it will still run DHCP, it just won't override your static configuration.

 

[Mervyn Haynes]

On Windows, my best GUESS is yes it will still run DHCP, it just won't override your static configuration.

So you think by manually setting the IP & not using DHCP, this "option 21 feature" could still be set by the DHCP server?

 

[Mervyn Haynes]

Just done some research on this, and apparently it STILL can change option 21 even though addresses are set manually!

 

[robscurity]

Could DHCP snooping prevent rouge DHCP servers on the LAN?

 

[PHolder]

DHCP snooping

Well DHCP amounts to:

Step 1.  Device needing IP config broadcasts: Hi I am MAC 12:34:56:78:90:AB and I would like DHCP please.
Step 2.  A DHCP server (or all of them) broadcasts: I recognize that MAC and I am allowed to service it, so here's some DHCP config
            (The device usually hears the first response and takes it and uses it.)

So in theory anyone else on the same LAN segment could hear those broadcasts, and in particular note when the DHCP server IP is not as expected, or when there are multiple responses (a race.)

 

[robscurity]

Well DHCP amounts to:

Step 1.  Device needing IP config broadcasts: Hi I am MAC 12:34:56:78:90:AB and I would like DHCP please.
Step 2.  A DHCP server (or all of them) broadcasts: I recognize that MAC and I am allowed to service it, so here's some DHCP config
            (The device usually hears the first response and takes it and uses it.)

So in theory anyone else on the same LAN segment could hear those broadcasts, and in particular note when the DHCP server IP is not as expected, or when there are multiple responses (a race.)

Yes I know about that, but what I meant was that you enable DHCP snooping on the switch/router controlling the LAN. Then if someone connect a rouge DHCP server, DHCP snooping should stop that traffic.

 

[PHolder]

DHCP snooping should stop that traffic

I guess it depends on the shape and size of your LAN, but I have multiple switches and over 60+ devices... so my question would be HOW could it possible stop a device that is winning a race to reply to a DHCP request? It's generally lacking the power to do so... unless every device was plugged in to its own port on the router (i.e. a very small network.)

 

[cschuber]

Well DHCP amounts to:

Step 1.  Device needing IP config broadcasts: Hi I am MAC 12:34:56:78:90:AB and I would like DHCP please.
Step 2.  A DHCP server (or all of them) broadcasts: I recognize that MAC and I am allowed to service it, so here's some DHCP config
            (The device usually hears the first response and takes it and uses it.)

So in theory anyone else on the same LAN segment could hear those broadcasts, and in particular note when the DHCP server IP is not as expected, or when there are multiple responses (a race.)

DHCP is like the RARP protocol. Anyone can listen to RARP and DHCP requests. Not in theory, these are broadcasts.

The way DHCP works is:

1. The client issues a DHCP broadcast. The MAC address in the ethernet header contains six octets (network speak for bytes) of ones in the destination MAC address.
2. The server sends a directed reply (destination MAC address of the client) with DHCP reply options.
3. The client configures itself.

Anyone can snoop this and all other traffic on the network (in theory). In practice the switch will broadcast the DHCP solicitation to all ports but the reply will only be seen by the client, unless of course other machines on the network are a) listening in promiscuous mode and b) the switch has been configured to mirror all traffic to switch ports configured to receive ALL traffic.

Any machine on the network can be manually configured to use any other machine's IP address, creating a DoS. There is no mitigation of this attack. Though normally this isn't an attack but some careless admin fat fingering an IP address in a config. I've even seen people make the mistake of assigning the gateway's IP to their newly connected host to the network resulting a DoS of the entire LAN.

A rogue DHCP server can cause some trouble. In that case it's a race.

Most corporate networks are locked down enough to avoid multiple DHCP servers on the same network. We use an alternate DHCP server when kickstarting new Linux machines. The problem here is the other corporate DHCP server may reply before ours does resulting in failure to install Linux with tne new machine becoming comatose. We move our small DHCP server onto the network through VMware.

 

[PHolder]

There is no race.

If you have multiple DHCP servers present because one is malicious, it is indeed a race. The client will act on the first/fastest response.

 

[cschuber]

If you have multiple DHCP servers present because one is malicious, it is indeed a race. The client will act on the first/fastest response.

Yes. In that case we do. We run multiple DHCP servers one for installing Linux while the other a legacy DHCP server for a legacy installer. That can cause some trouble. Though our DHCP server is put on the network via VMware while the legacy DHCP server is actually a DHCP rely through the gateway.