Dynamic Host Configuration Protocol. Listening on 67 port. Sending from 68.
Mechanism
DHCP Discover (Broadcast) C-> S
[new PC] ð§ļ “I need an IP, I am new here. Only have this stupid useless 169.254.X.X address. Where do I register? Guys! Who knows where the DHCP is?”
DHCPDISCOVER
is broadcasted in the network. Every machine, even non-DHCP once, hear this message.
DHCP Offer (Broadcast/Unicat) S -> C
[DHCP server] ðĨļ “I’m DHCP. How can I help?”
DHCP server sends a DHCPOFFER to the [new PC] offering its help.
DHCP Request (Broadcast) C -> S
[new PC] ð§ļ “I want an IP!”
PC in question responds with a DHCPREQUEST packet.
DHCP Ack (Broadcast/Unicat) S -> C
[DHCP server] ðĨļ “Here you are. Fetch your configs also!” DHCP sends the PC IP address with the settings in a DHCPACK packet and put this data into its registry table as well, striking through the IP already in use now.
Mnemonics - DORA (Discover, Offer, Request and Acknowledge)
ð BTFM
ipconfig \refresh # Windows
DHCP starvation
Get a legitimate DHCP down, become a DHCP server for the network, config PCs with the new GW (gateway), DNS, domain, subnet mask, IP etc. Get the legitimate DHCP down and set up a rougue one. All traffic comes through the fake DHCP. Step 1. Change local MAC address so that DHCP thinks I’m someone else. Step 2. Send a lot of (hunderds, thousands) DHCPREQUESTs thus delpleting the server’s pool of available IP addresses. The overwhelmed and terrified legitimate DHCP crashes. Step 3. Introduce my own rogue DHCP server.
DHCP Snooping
Prevents DHCP starvation. It’s a layer 2 sec switch which blocks unauthorized DHCP servers. Switch have trusted and untrusted ports. Legitimate DHCP is connected to the trusted one when first set up. All other devices, even local machines, become untrusted.
- Switch will drop all DHCPOFFER, DHCPACK, DHCPNACK from untrusted ports.
- Drop requests for release/decline DHCPOFFER if these messages do not originate on the original machine then has send a DHCPREQUEST. This way attacker won’t be able to terminate/decline the DHCP offer from the client’s behalf.
- â DHCP relay agent forwards a DHCP packet that includes a relay agent IP != 0.0.0.0 or includes option 82 to an untrusted port.
- If source MAC (Ethernet) != client MAC (bootstrap protocol) - drop.
If either of the above scenarios happen, it’s logged. Apart from that, the switch will log the following:
- MACs of untrusted ports (UP).
- Leased addresses of UP.
- Lease time.
- Binding time.
- VLAN/interface the UP is associated with.
On lease time expiration or DHCPRELEASE, cleanup of the corrsponding entry in the DHCP Snooping Binding DB. DHCP assigns addresses, switch filters, logs and forwards. Switch/router = DHCP relay agent.
Tools
Expand …
https://www.ccexpert.us/port-security/gobbler.html http://dhcpstarv.sourceforge.net/ https://www.kali.org/tools/yersinia/Reference
Expand…
[1] Apple, all about MITM. About Mac DHCP bugs from PhDays 2019. [2]DHCP SNOOPING OPTION 82 [3] COMPLETE GUIDE TO DHCP SNOOPING, HOW IT WORKS, CONCEPTS, DHCP SNOOPING DATABASE, DHCP OPTION 82, MITIGATING DHCP STARVATION ATTACKS, DHCP HIJACKING, MAN-IN-THE-MIDDLE ATTACKS & ROGUE DHCP SERVERS
https://habr.com/en/companies/dsec/articles/333978/ https://habr.com/en/articles/338860/ https://habr.com/en/articles/338864/ https://habr.com/en/articles/339666/