
DHCPwn: A DHCP exhaustion tool - svenfaw
https://github.com/mschwager/dhcpwn
======
roozbeh18
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...](http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-
switches/white_Paper_C11_603833.html)

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

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

~~~
AndyMcConachie
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...](https://github.com/smutt/mcastClients/blob/master/mcastClients.py)

------
exabrial
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!

------
coolj
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](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.

------
florianfunke
Looks like it's a very thin wrapper around scapy:
[http://www.secdev.org/projects/scapy/](http://www.secdev.org/projects/scapy/)

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

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

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

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

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

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

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

------
roeme
It must be the holidays, where the experienced netops spend time away from HN
and trivial poc's for old well-known attacks get upvotes.

------
kesor
scapy is awesome.

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

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

~~~
cpach
That’s not a very nice thing to say.

~~~
therein
Only in CS circles haha.

