PAC URL distributed via DHCP option 252
medium
DHCP answers are plaintext broadcasts with no authentication in practice. A rogue DHCP responder on the same segment can hand out its own PAC URL and take over routing for every client that trusts option 252. Switch-level DHCP snooping or explicit configuration closes the gap.
Why it matters
RFC 2132 defines the option space and RFC 3118 the (effectively undeployed) authentication for DHCP. In a flat segment, the first DHCPOFFER wins; an attacker who answers faster than the real server controls the PAC URL and therefore the proxy for all web traffic. DHCP snooping (trusting only the real server’s switch port) and 802.1X segmentation are the network mitigations; distributing the PAC URL by policy (GPO/MDM) and disabling automatic discovery removes the dependency entirely. Draft: the rule is advisory and depends on the user stating the delivery method; it cannot be derived from the file.
How to fix
Prefer explicit AutoConfigURL via GPO/MDM; where DHCP-WPAD stays, enable DHCP snooping on access switches.
Examples
Bad
# DHCP option 252 on an access segment without DHCP snooping
option 252 "http://wpad.corp.example/wpad.dat"
Good
# explicit AutoConfigURL from GPO/MDM; automatic discovery disabled on managed clients
https://pac.corp.example/proxy.pac
Related rules
- PAC served over plain HTTP PAC-D001
- PAC distributed via WPAD DNS discovery PAC-D007