Network Knobs

DHCP¹ allows a server to specify routes to the client, which has pluses and minuses. One minus is when a malicious DHCP server (or malicious local network traffic) sets inappropriate routes

> CVE-2024-3661 - Decloaking Full and Split Tunnel VPNs

> "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." — tgsovlerkhgsel. The Orange Site. 2024.

or a plus is the ability to have your DHCP server specify a custom route so you can access your home devices regardless of what the work Enterprise VPN wants the routes to be. (This might get you in trouble with the security folks at that Enterprise, if they find out.) There are various other ways that custom routes can be specified over a network; a client system may accept them (so that the network will actually work) or could ignore them (to make the life of an attacker more difficult). That is, there are knobs to fiddle with here, and with knobs comes the potential for abuse, misconfiguration, and terribly clever tricks.

There is some wiggle room; on a maybe hostile network (e.g. the free wi-fi at the coffee shop, or where the local router has been hacked) a client system could check what the DHCP server offers, review the options presented, and after that all checks out accept a DHCP address but then set the IP and route statically. This could also be highly inconvenient, may result in a broken network, and could very much annoy the local network admin if they discover your system squatting where it should not be.

A downside is that the folks who most need to guard against malicious local networks are those who may know the least about networking, e.g. journalists who spend their time reporting on things that are not esoteric network knobs, and maybe who do not have suitable software that does policy based routing (e.g. Linux network namespaces, FreeBSD vnet, or OpenBSD rdomains).

Full WireGuard setup with OpenBSD

Firewalls, routing, and VPN are hilariously operating system specific, even incompatible between different releases of the same system. Check the fine manual for details. Handy tools include ipcalc or sipcalc, especially if you are trying for a very small netmask unlikely to be discovered or made more specific by a DHCP provided route. How big of a network do you really need for a laptop to that one cloud host link?

RFC 3330 might be handy, and is probably an easier number to memorize than RFC 5735, if you want to know about well-known network addresses such as 192.0.2.0/24.

On the DHCP debugging front, Wireshark can decode network traffic, but on the other hand Wireshark may present a rather large attack surface especially where there is malicioiusly forged local network traffic. Other packet decoders may also bring in a large amount of software, and DHCP client software may not have knobs to change what options are honored or logged. There may be room for improvement or more research on this front.

Rogue DHCP Servers

Rogue DHCP servers can accidentally be a thing, though most decent (prosumer and up) network switches will have a feature to squash rogue DHCP traffic. This was more a problem back in the 2000s when Apple had a promising looking checkbox for "share the network" that instead of turning on file sharing would instead create a rogue DHCP server, and then any DHCP client that got a response first from that Mac would have a misconfigured network (the network switches were pretty dumb and open, back then and there). There are legitimate uses for custom DHCP servers, most notably for automated host builds using KickStart or autoinstall(8), though these can and probably should be put on a private network.

—

¹ Dynamic Host Configuration Protocol (DHCP) - RFC 2131, RFC 3442.