I just happen to be writing a series of articles covering such network attacks from a practical point-of-view. Here is the article on DHCP, ARP will follow.
DHCP and ARP are indeed two different attacks allowing the attacker to achieve a MITM within a subnet.
DHCP Spoofing is done by a rogue DHCP server on the network which
replies to DHCP requests from hosts(Attacker can run a DHCP starvation
attack on the legitimate DHCP server to stop it from handing away IP
addresses). The rogue server can spoof the gateway & DNS servers
therefor all DNS & Traffic going away from local subnet will start to
flow to the attacker. The attacker then forward the received traffic
accordingly so the hosts won’t notice any disruption in connectivity
and effectively pulling off a MITM attack.
This is right.
In ARP Poisoning, attacker send spoofed arp messages to the network
and arp cache of the switch will have wrong information so the switch
starts to send traffic to the attacker (which should originally go to
another host or default gateway)
The classical ARP attack doesn't target the switches but end-devices.
Each devices given an IP, need to obtain the corresponding MAC address to establish a communication. This is what the ARP is for.
The attack consists in forcing a device into resolving an IP as the attacker's MAC address instead of the legitimate one.
Nevertheless, there is also a less common attack targeting the switch, making it believe that a certain MAC address can be reached through the attacker's port instead of the legitimate one.
This attack is less convenient and reserved for situations where the previous one doesn't work (MAC address hardcoded in devices configuration for instance).
DHCPDISCOVER, DHCPOFFER, DHCPREQUEST & DHCPACK are broadcast messages
DHCPDISCOVER and DHCPREQUEST are indeed broadcasted, the two other usually aren't.
so typically all hosts in the local subnet will receive all this
messages anyway. Even if the attacker has already done some ARP
poisoning on the local subnet it won’t affect the process of DHCP.
It depends the degree of chaos the attacker has already spread in the network ;) , but fundamentally you're right: ARP is not related to DHCP here.
ARP is used for resolving Internet layer addresses into link layer
addresses.Since ahost does not have an IP address until DHCP process
is completed ARP attacks seems useless on DHCP
I think of two cases where ARP-based attacks may be a good complement to DHCP-based attacks:
DHCP client messages are usually only broadcasted during the initial network configuration, when a network device is brought up (or when the legitimate DHCP server doesn't reply... DOS?). When a device needs to renew a DHCP lease, the DHCP REQUEST message usually isn't broadcasted anymore but is only a unicast message sent to the DHCP server which initially offered the lease.
DHCP MITM attacks are therefore usually only possible during the boot process of a device or when a running device is joining to the network.
Using ARP would allow to impersonate the DHCP server and intercept the client's DHCP REQUEST message. This may be for instance a way to push a new default router IP to a device where the MAC address of the legitimate router has been hardcoded, but its IP hasn't.
More fun: the case of DHCP DOS attacks. Check the DHCPig tool, it is a DOS tool implementing a DHCP starvation attack: the attacker leases all available IP addresses from the DHCP server so that no new address will be available for the other devices.
The core of this attack is basic and only rely on DHCP messages, but DHCPig adds a few features I like, and which involve ARP messages:
Using an ARP scan, DHCPig detects the other currently running devices and their IP and then sends a DHCP RELEASE message to the DHCP server, therefore marking their IP as free so they can now be stolen by the attacker.
Once the DHCP server has been DOSed-out, DHCPig can broadcast ARP messages which will simulate an IP conflict for each IP address composing the subnet. For Unix-like systems, this won't do much, but when Windows systems detect such conflict they immediately drop their current IP address and request a new one to the DHCP server... which is unable to fulfill the request, leaving the Windows client unconfigured. In other words, the ARP packets allowed to kick the Windows devices out of the network.
