DHCPwn: A DHCP exhaustion tool
github.com
github.com
It's also a bit dubious to claim that DHCP is connectionless. It takes 4 packets to complete a DHCP request. While maybe not connection oriented, it's definitely at least a handshake.
I've written numerous packet generators to test DHCP servers, and DHCP Snooping implementations. This is really nothing new.
I appreciate you sharing that it doesn't seem new to you, could you share some of your examples so we can learn from your experience also?
To prevent this program from doing its evil, DHCP snooping could be configured to only allow one source IP address on a port. In fact, to prevent this kind of attack you don't even need DHCP snooping. Since it requires MAC spoofing you can configure the switch to only learn one MAC on that port, or only allow frames with a limited number of MACs to ingress the switch.
Hope this helps.
A while back I wrote opensourced some code I wrote for work that emulated IGMPv2 behavior of triple-play set top boxes. It's meant to stress IGMPv2 implementations, but it also emultates multiple DHCP clients. https://github.com/smutt/mcastClients/blob/master/mcastClien...
I used `yersinia` many years ago for this exact purpose (DHCP exhaustion). It supports attacking several layer 2 protocols as well.
They are not in the 99.99% of corporate environments outside of startup-land.
Remember, not all of your enemies are outside your firewall!
https://tools.ietf.org/html/rfc2131#page-31
Because the servers have not committed any network address assignments on
the basis of a DHCPOFFER, servers are free to reuse offered
network addresses in response to subsequent requests. As an
implementation detail, servers SHOULD NOT reuse offered addresses
and may use an implementation-specific timeout mechanism to decide
when to reuse an offered address.
At this point you can start your own rogue AP and people will join that.
These days it seems like most shops converted over to AP's that use wireless network segregation and are smart enough to not let one of those networks gobble up > 1 address.
A couple of years ago, we started having issues with our wifi like you're describing. Connecting devices would work, but nothing new could join the network. The issue? DHCP lease times were set to 30 days in a facility where hundreds of transient devices per day could connect up to the wireless network. The IP pool unsurprisingly got exhausted.
Our network engineer at the time was... not very good. It took two separate incidents with MDs complaining and me finally sniffing DHCP traffic on a spare laptop and emailing it to his boss to get it fixed.
If you spoof your MAC then how would they know to only give one address?
From the OP:
>"Depending on the server's method of releasing IP addresses associated with a given MAC address this attack will either be more, or less effective. For example, if a server quickly releases allocations that it doesn't receive responses from, the attack will be less effective."
Why not respond to the responses on all those MACs then, surely in promiscuous mode you could send responses (and even fake a little traffic) for each MAC used. My home router is preconfigured to allow only 253 connections (lease time 1 day) - seems you could easily mess with SOHO routers with this?
Why is your lease time so very, very long? Why not set it to something like 60 or 30 minutes?
IIRC, devices will start renewing their leases long before they get to the expiry period, so it's not as if short leases do anything more than substantially increase what is almost certainly a minuscule amount of traffic on your LAN.
If I set my DHCP server's lease time as you suggest, I would often have to wait several seconds for my laptop to reacquire an address after waking up if there was any packet loss in the DHCP handshake, and if I happened to get a different IP, my SSH sessions would die. Seeing as 99.9% of device-hours logged on my router are the same four devices, I have no reason not to have a long lease time (3 days, my router's default). It's not like I'm running a Starbucks.
Odd. My non-systemd machine gets an address long before I'm able to unlock the lock screen... and I'm a fast typer. It's entirely possible that my machine is an outlier, tho. :)
> ...and if I happened to get a different IP, my SSH sessions would die.
You don't have "static leases" for all of your known devices that live in a range that's not served to unknown devices?
Anyway. Here's hoping that I hear from pbhjpbhj. :)
I did try with Yersinia but couldn't get it working immediately; perhaps there's protection built in?