DHCPwn: A DHCP exhaustion tool
github.com
DHCPwn: A DHCP exhaustion tool
1–10 of 26 posts
Re: DHCPwn: A DHCP exhaustion tool
#2This 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!
Re: DHCPwn: A DHCP exhaustion tool
#3Looks like it's a very thin wrapper around scapy: http://www.secdev.org/projects/scapy/
Re: DHCPwn: A DHCP exhaustion tool
#4This 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.
Re: DHCPwn: A DHCP exhaustion tool
#5PoCs 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.
Re: DHCPwn: A DHCP exhaustion tool
#6DHCP 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...
Re: DHCPwn: A DHCP exhaustion tool
#7This 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?
Re: DHCPwn: A DHCP exhaustion tool
#8I assume most guest wifi has some protection against this, if not, well shame on them.
Re: DHCPwn: A DHCP exhaustion tool
#9Somewhat 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.
Re: DHCPwn: A DHCP exhaustion tool
#10This 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?
> ... could you share some of your examples ...
I used `yersinia` many years ago for this exact purpose (DHCP exhaustion). It supports attacking several layer 2 protocols as well.