Live data from Hacker News

DHCPwn: A DHCP exhaustion tool

github.com

21–26 of 26 posts

Re: DHCPwn: A DHCP exhaustion tool

#21

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?

> OOB most things will dish up leases at will, how else are folks spinning up countless bridged VMs, containers, etc in workstations.

They are not in the 99.99% of corporate environments outside of startup-land.

Re: DHCPwn: A DHCP exhaustion tool

#22

Earlier quoted context omitted.

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…

>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…

> 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.

Re: DHCPwn: A DHCP exhaustion tool

#23
Since this is just sending out DISCOVERs and never REQUESTs on any OFFERs that come back, servers can technically reuse IPS from outstanding offers:

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.
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.

Re: DHCPwn: A DHCP exhaustion tool

#24

Earlier quoted context omitted.

>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…

> 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.

Re: DHCPwn: A DHCP exhaustion tool

#25

Earlier quoted context omitted.

> 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 happ…

> 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. :)

Re: DHCPwn: A DHCP exhaustion tool

#26

Earlier quoted context omitted.

>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…

> 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.

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?

Post reply on HN