DHCP Exhaustion Issues?

[W0lfy]

Hello Guys,
I'm writing a multi-purpose network exploitation tool and I'm towards the end. One of the functions my tool does is DHCP Exhaustion which works great on my network at work (2k3 DHCP Server). But when I try to use it on my laptop connected to wifi somewhere, the router doesn't respond to the DHCP Discovers.

The program generates a random MAC Address for each DHCP Discover packet it sends out. I'm starting to think the generated MAC might have to be authenticated against the router before it will respond to it.

Any Ideas?

Thanks,

[orgcandman]

Are you sure you're generating the request properly? I don't know how you're trying to accomplish this - I'm guessing you're sending out over a raw eth socket. Try this - try physically plugging into the wireless network first. My guess on why it wouldn't be working is a few fold:

1) you've bound your socket to the wrong interface
2) you've not sent the message formatted properly for wireless (don't know what kinds of mac extensions are required)

[W0lfy]

Im using the libnet library, but the only thing that differs from the ones I created and a real one is the parameter request list from my control group at home, which if im not mistaken should vary depending on dhcp client software.

I know im using the right interface.
What do you mean by mac extensions?

Are you sure you're generating the request properly? I don't know how you're trying to accomplish this - I'm guessing you're sending out over a raw eth socket. Try this - try physically plugging into the wireless network first. My guess on why it wouldn't be working is a few fold:

1) you've bound your socket to the wrong interface
2) you've not sent the message formatted properly for wireless (don't know what kinds of mac extensions are required)

[orgcandman]

I'm not sure if there are any specific 802.11 headers that need to be set, it's an avenue for investigation.

[randalth0r]

Hello Guys,
I'm writing a multi-purpose network exploitation tool and I'm towards the end. One of the functions my tool does is DHCP Exhaustion which works great on my network at work (2k3 DHCP Server). But when I try to use it on my laptop connected to wifi somewhere, the router doesn't respond to the DHCP Discovers.

The program generates a random MAC Address for each DHCP Discover packet it sends out. I'm starting to think the generated MAC might have to be authenticated against the router before it will respond to it.

Any Ideas?

Thanks,

First and foremost, have asked for permission to exhaust all the addresses in the "wifi somewhere"? The way you phrase yourself doesn't seem legitimate at all. This is essentially a denial-of-service attack and it shouldn't be executed without proper permissions from the network owners.

[W0lfy]

First and foremost, have asked for permission to exhaust all the addresses in the "wifi somewhere"? The way you phrase yourself doesn't seem legitimate at all. This is essentially a denial-of-service attack and it shouldn't be executed without proper permissions from the network owners.

yes, lol the reason I said "somewhere" was because I didnt want to explain. The two wifi places I tried where at my house with a linksys WRT54G and on my Android phone. Nether which would respond to my DHCP Discover packets.

I started thinking the other day about aircrack, and how you have to authenticate your mac against the AP before it will accept your injected packets, and Im wondering if the same has to be done with my generated MACs?

[W0lfy]

Here is a capture of one of the DHCP Discover packets my program sends out.

No. Time Source Destination Protocol Info
22 2.360908 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x502100d

Frame 22: 331 bytes on wire (2648 bits), 331 bytes captured (2648 bits)
Arrival Time: Jan 6, 2011 08:43:29.343771000 EST
Epoch Time: 1294321409.343771000 seconds
[Time delta from previous captured frame: 0.124144000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 2.360908000 seconds]
Frame Number: 22
Frame Length: 331 bytes (2648 bits)
Capture Length: 331 bytes (2648 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ip:udp:bootp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: 25:91:80:72:09:49 (25:91:80:72:09:49), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
Source: 25:91:80:72:09:49 (25:91:80:72:09:49)
Address: 25:91:80:72:09:49 (25:91:80:72:09:49)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00)
0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 317
Identification: 0x0000 (0)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (17)
Header checksum: 0x39a1 [correct]
[Good: True]
[Bad: False]
Source: 0.0.0.0 (0.0.0.0)
Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Source port: bootpc (68)
Destination port: bootps (67)
Length: 297
Checksum: 0xd6d8 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x0502100d
Seconds elapsed: 0
Bootp flags: 0x8000 (Broadcast)
1... .... .... .... = Broadcast flag: Broadcast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: 25:91:80:72:09:49 (25:91:80:72:09:49)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (t=53,l=1) DHCP Message Type = DHCP Discover
Option: (53) DHCP Message Type
Length: 1
Value: 01
Option: (t=116,l=1) DHCP Auto-Configuration = AutoConfigure
Option: (116) DHCP Auto-Configuration
Length: 1
Value: 01
Option: (t=61,l=7) Client identifier
Option: (61) Client identifier
Length: 7
Value: 01259180720949
Hardware type: Ethernet
Client MAC address: 25:91:80:72:09:49 (25:91:80:72:09:49)
Option: (t=12,l=4) Host Name = "Howl"
Option: (12) Host Name
Length: 4
Value: 486f776c
Option: (t=60,l=8) Vendor class identifier = "ISFT 5.0"
Option: (60) Vendor class identifier
Length: 8
Value: 4953465420352e30
Option: (t=55,l=11) Parameter Request List
Option: (55) Parameter Request List
Length: 11
Value: 010f03062c2e2f1f21f92b
1 = Subnet Mask
15 = Domain Name
3 = Router
6 = Domain Name Server
44 = NetBIOS over TCP/IP Name Server
46 = NetBIOS over TCP/IP Node Type
47 = NetBIOS over TCP/IP Scope
31 = Perform Router Discover
33 = Static Route
249 = Private/Classless Static Route (Microsoft)
43 = Vendor-Specific Information
Option: (t=43,l=2) Vendor-Specific Information
Option: (43) Vendor-Specific Information
Length: 2
Value: dc00
End Option

[vvpalin]

With just barely glancing at the output you posted it looks legit.

Best advice i think .. or maybe not best, however its what i would do. Is to join to the router either with windows or nix and pcap it. The switch your mac clear the dhcp lease and pcap it again. Then compare those 2 against the one your program outputs that doesn't work. So that in the end your program exactly mimics the working leases you got. Once you have that, you can go back in and "fuzz" around with the dhcp option codes and see what works and what doesn't.

Hope that was of some help, altho i probably missed the point entirely

edit: If your having to auth to the wifi then yes you need to "pretty sure atleast" reauth for each lease that you grab if your clearing it first .. you could always request another tho without switching the mac. I could be over thinking it ... but it does sound like a nifty little experiment.

[orgcandman]

Yikes! Why do you have the multicast bit set on your source mac address?

[W0lfy]

With just barely glancing at the output you posted it looks legit.

Best advice i think .. or maybe not best, however its what i would do. Is to join to the router either with windows or nix and pcap it. The switch your mac clear the dhcp lease and pcap it again. Then compare those 2 against the one your program outputs that doesn't work. So that in the end your program exactly mimics the working leases you got. Once you have that, you can go back in and "fuzz" around with the dhcp option codes and see what works and what doesn't.

Hope that was of some help, altho i probably missed the point entirely

edit: If your having to auth to the wifi then yes you need to "pretty sure atleast" reauth for each lease that you grab if your clearing it first .. you could always request another tho without switching the mac. I could be over thinking it ... but it does sound like a nifty little experiment.

Thanks for the info, I ended up resolving the issue by using the authenticated mac used to connect to the wireless. The only down fall is if someone is watching the packets they could trace it back to your pc, but then again, if your going to be attacking a network you should always change your mac address first!

Yikes! Why do you have the multicast bit set on your source mac address?

That was a randomly generated mac address. The only time it was used was to send out that DHCP Discover, and to send a DHCP Request.

Although I have done some more work on the program and it now generates realistic addresses, instead of just 0-9.