Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add 'MAC Address' argument option to dhcp-discover script #1838

Closed
plittlefield opened this issue Nov 28, 2019 · 8 comments
Closed

Add 'MAC Address' argument option to dhcp-discover script #1838

plittlefield opened this issue Nov 28, 2019 · 8 comments
Assignees

Comments

@plittlefield
Copy link

I am trying to test a DHCP server to see if a specific MAC address receives the correct IP address assignment.

Would it be possible to add a command line argument option to allow a MAC address to be specified?

e.g.

nmap -sU -p 67 --script=dhcp-discover -m '80:ce:62:e4:6e:f5'

Thanks.

Regards,

Paully

@nnposter
Copy link

I will take this on. Stay tuned...

@plittlefield
Copy link
Author

Great, thanks!

@nnposter
Copy link

In commit r37878, scripts dhcp-discover and broadcast-dhcp-discover now take a new argument to force a specific MAC address:

nmap -sU -p 67 --script dhcp-discover --script-args dhcp-discover.mac=80:ce:62:e4:6e:f5 ...
nmap -sU -p 67 --script broadcast-dhcp-discover --script-args broadcast-dhcp-discover.mac=80:ce:62:e4:6e:f5 ...

Which of the two scripts to use depends on your specific situation. If the DHCP server is local to the scanner, or you want to follow the current DHCP relay agent path, then broadcast-dhcp-discover is likely a better choice. If you want to target a specific, non-default DHCP server then dhcp-discover might work for you.

You can run both:

nmap -sU -p 67 --script dhcp-discover,broadcast-dhcp-discover --script-args mac=80:ce:62:e4:6e:f5,dhcptype=dhcpdiscover ...

Caveats:

  • Script broadcast-dhcp-discover needs to sniff raw packets so the user must have adequate privileges.
  • Script dhcp-discover will generate the DHCP request packet but it might not be able to see the response, depending on your DHCP setup. You might be able to catch the response with a sniffer.

Example:

$ nmap -n -sU -p67 --script broadcast-dhcp-discover --script-args mac=cafebabec0de
Starting Nmap 7.80SVN ( https://nmap.org ) at 2020-01-14 18:41 MST
Pre-scan script results:
| broadcast-dhcp-discover: 
|   Response 1 of 1: 
|     IP Offered: 192.168.73.132
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 192.168.73.254
|     IP Address Lease Time: 30m00s
|     Subnet Mask: 255.255.255.0
|     Router: 192.168.73.2
|     Domain Name Server: 192.168.73.2
|     Domain Name: localdomain
|     Broadcast Address: 192.168.73.255
|     NetBIOS Name Server: 192.168.73.2
|     Renewal Time Value: 15m00s
|_    Rebinding Time Value: 26m15s

@plittlefield
Copy link
Author

Outstanding work, thank you!

@nnposter
Copy link

Please test, provide feedback and/or close the issue if satisfied

@TommyJerryMairo
Copy link

As for Nmap 7.80, the command sudo nmap -sU -p 67 --script broadcast-dhcp-discover --script-args broadcast-dhcp-discover.mac=rand sudo nmap -sU -p 67 --script broadcast-dhcp-discover --script-args broadcast-dhcp-discover.mac=rand and sudo nmap -sU -p 67 --script broadcast-dhcp-discover --script-args broadcast-dhcp-discover.mac=random result in using the actual MAC address and IP of the machine running it. In other words, the source address randomization seems not working.

@TommyJerryMairo
Copy link

Also, the script trace shows that the UDP package is sent with source address 0.0.0.0. However, it's has been changed to the actual IP when captured on the Wireshark.

@nnposter
Copy link

In other words, the source address randomization seems not working.

I have re-validated that both scripts are working as expected. The DHCP server is correctly picking up and responding to this random MAC address. Please make sure that you are inspecting field bootp.hw.mac_addr, not eth.src (in Wireshark-speak).

...the UDP package is sent with source address 0.0.0.0. However, it's has been changed to the actual IP when captured on the Wireshark.

Please create a new issue. Do not treat this closed issue as a catch-all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants