DHCP Consumption Attack is nothing new and prevented on enterprise level switches and routers using DHCP Snooping and Dynamic ARP Inspection (DAI). anyone interested in reading upon this sort of attack, cisco has a good white paper on it here. http://www.cisco.com/c/en/us/products/collateral/switches/ca...
This is nothing new, and won't work in any properly configured environment using DHCP Snooping.
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.
DHCP snooping prevents rogue DHCP servers. I have only seen a handful
of switches in orgs configured for hard limits MAC/lease per port. OOB most things will dish up leases at will, how else are folks spinning up countless bridged VMs, containers, etc in workstations.
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?
DHCP snooping can do different things dependening on how it's configured. It can prevent ARP spoofing attacks, or DHCP server exhaustion, by limiting the amount of source IPs that can ingress a given port on a switch.
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...
This is a real threat in today's BYOD world, fortunately it can be easily defeated on the most basic of network switches. Cisco SG300s (fairly common distribution switches) have classic port locking and would be the simplest solution. 802.1x would be significantly more complicated, but provides other benefits. Something like PacketFence would be the ultimate solution.
Remember, not all of your enemies are outside your firewall!
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.
I'm curious if common DHCP servers like dnsmasq actually do reuse IPs from pending OFFERs, and what timeout they have, if any, before reuse. I poked around dnsmasq config but I did see any specific tuning for that.
Somewhat related to this, yay for SLAAC on IPv6. DHCP is only used for auxiliary info like DNS servers, search suffix, etc. This is known is DHCP Lite.
This was an old trick to use at places with slow wifi. Exhaust the DHCP database with a short perl script. Everyone comes in asking why the wifi isn't working while you're still plugging away. Of course, the staff can 'fix it' by rebooting the router but eventually they'd quit because it only solves it for a few minutes.
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.
We had issues with this at work. We're a healthcare facility that grew faster than our IT infrastructure or admin expertise did.
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.
>smart enough to not let one of those networks gobble up > 1 address //
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?
> My home router is preconfigured to allow only 253 connections (lease time 1 day)...
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.
My laptops are often asleep for more than 60 minutes at a time. When I open them up, I expect network availability pretty much immediately (I am rather impatient), and (preferably) my SSH sessions intact.
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.
> 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...
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. :)
As it happens I only have a max of about 15 devices ever (when friends are over) and AFAICT no one is trying to DDoS my router. Those settings were the default and there doesn't seem any reason for me to change it - my point was that exhausting all the leases should be easy. Of course then power-cycling is easy too, but then exhausting all the leases again would be super-annoying for a neighbour who hadn't got a clue what was going on.
I did try with Yersinia but couldn't get it working immediately; perhaps there's protection built in?
PoCs like this are cool. This is a valid and potentially catastrophic attack against network segments. One should study and consider countermeasures against such attacks on your turf. Python and Scapy are super cool and if you haven't had a play it's well worth your time.
