Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DHCPwn: A DHCP exhaustion tool

github.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: DHCPwn: A DHCP exhaustion tool

#11

Post by bluedino »

ck2 wrote: post #8

I assume most guest wifi has some protection against this, if not, well shame on them.

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.

Re: DHCPwn: A DHCP exhaustion tool

#12

Post by AndyMcConachie »

accessleech2848 wrote: post #7
AndyMcConachie wrote: post #4

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

Re: DHCPwn: A DHCP exhaustion tool

#14

Post by roeme »

accessleech2848 wrote: post #5

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.

I wouldn't be surprised if you were a markov chain.

Re: DHCPwn: A DHCP exhaustion tool

#15

Post by commandar »

bluedino wrote: post #11
ck2 wrote: post #8

I assume most guest wifi has some protection against this, if not, well shame on them.

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…

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.

Re: DHCPwn: A DHCP exhaustion tool

#17

Post by cpach »

roeme wrote: post #14
accessleech2848 wrote: post #5

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.

I wouldn't be surprised if you were a markov chain.

That’s not a very nice thing to say.

Re: DHCPwn: A DHCP exhaustion tool

#20

Post by pbhjpbhj »

bluedino wrote: post #11
ck2 wrote: post #8

I assume most guest wifi has some protection against this, if not, well shame on them.

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

Post reply on HN