Nmap Development mailing list archives
Re: Adding new NSE discovered targets to Nmap
From: Ron <ron () skullsecurity net>
Date: Thu, 12 Aug 2010 16:02:32 -0500
On Thu, 12 Aug 2010 22:52:38 +0200 Patrik Karlsson <patrik () cqure net> wrote:
About broadcast in NSE, do you need to do something to set SO_BROADCAST on the socket or is this taken care of?
I'm *guessing* that's the issue, and I remember talking about enabling SO_BROADCAST on the list in the past. I don't think NSE has the ability to enable SO_BROADCAST, but I could be wrong.
//Patrik On 12 aug 2010, at 22.35, Ron wrote:Attached a script that does a DHCP request then scans the DHCP address range. I ran into a couple issues, though. First, if I do socket:connect("255.255.255.255", 67, "udp") - it doesn't work. It appears to, but packets don't get sent. I've run into issues with broadcasting like that before, and I don't understand exactly what's going on, but does anybody have any ideas? For now, in this script, I hardcoded 192.168.1.1 as the router's address -- definitely not optimal. Second, I have to use pcap_receive() to get the response from the DHCP server (because DHCP is crazy). pcap_receive() requires an interface and a MAC address. Since this is a prescan rule, there's no interface so I hardcode "eth0". Is that going to break on non-Linux or is that standard for Nmap? Is there some way I can enumerate ethernet interfaces so I can send out the DHCP request on all of them? If not, would it be hard to add? And third, I ran into some segfaults on this branch related to target selection: $ nmap -d Starting Nmap 5.35DC18 ( http://nmap.org ) at 2010-08-12 15:33 CDT Segmentation fault $ nmap abc Starting Nmap 5.35DC18 ( http://nmap.org ) at 2010-08-12 15:33 CDT Segmentation fault $ nmap 1.2.3.4 Starting Nmap 5.35DC18 ( http://nmap.org ) at 2010-08-12 15:34 CDT Segmentation fault I haven't looked into why that's happening yet. Other than that, this worked great! This script isn't commit quality yet, it's definitely PoC. I need to abstract out the DHCP into a nselib. I just wanted to try out the prerule/target code. :) Ron On Thu, 12 Aug 2010 15:06:47 +0100 Djalal Harouni <tixxdz () gmail com> wrote:Hi list, I've created a new NSE library 'target.lua' which will handle adding new discovered targets to Nmap. This feature is only available for NSE scripts (prerule, hostrule and portrule ones, postrule scripts can't add targets). First this is the NSEdoc of the target.lua library: --- -- Utility functions to add new discovered targets to Nmap scan queue. -- -- The library lets scripts to add new discovered targets to Nmap scan -- queue. Only scripts that run in the script pre-scanning phase -- (prerule) and the script scanning one (hostrule and portrule) are -- able to add new targets, post-scanning (postrule) can't do that. -- @args newtargets If specified, lets NSE scripts to add new targets. -- This is a special variable and it is a global one, so -- scripts can check it to see if adding targets is allowed, -- before calling <code>target.add()</code> function. -- It will be set to true if the script argument -- <code>newtargets</code> was specified. ALLOW_NEW_TARGETS = false --- Adds the passed arguments to the Nmap scan queue. -- -- Only prerule, portrule and hostrule scripts can add new targets. -- -- @param targets A variable number of targets. Target is a -- string that represents an IP or a Hostname. If this function -- is called without an argument then it will perform a check to -- test if it can add new targets to the scan queue. -- @usage -- local status, err = target.add("192.168.1.1") -- local status, err = target.add("192.168.1.1","192.168.1.2",...) -- local status, err = target.add ("scanme.nmap.org","192.168.1.1",...) -- local status, err = target.add(unpack(array_of_targets)) -- local status, err = target.add() -- @return True if it has been able to add a minimum one target, or -- False on failures and if no targets were added. -- @return String error message in case of failures. add = function (...) ... end To test the feature, you can checkout nmap-exp/djalal/nmap-add-targets Comments and opinions are welcome: * First consider that Nmap scanned targets are not saved, and when we add this feature some parts of the following plan will change. * Currently targets are strings, they can be IPs, hostnames and networks. I think that for the moment we should consider target filtering and parsing in the target.add() function, to only allow IPs and perhaps hostnames and to avoid other network targets specification until we have a better solution to filter all Nmap scanned targets. e.g: avoid this situtation: target.add("192.168.0.1/30") target.add("192.168.0.1/29") with the current implementation we'll scan the same targets twice or perhaps more if they are specified as Nmap targets, but we can't add the *same* *string* twice: target.add("192.168.0.1/30") target.add("192.168.0.1/30") only one string will be added, so these hosts will be scanned only a one time if they are not specified as Nmap targets. Filtering and parsing network blocks on NSE will take lot of memory, and since Nmap handles this perfectly we should let Nmap do the job for us. * If we took scanme.nmap.org as an example: scanme.nmap.org == 64.13.134.52 target.add("scanme.nmap.org","64.13.134.52") this code will add two new targets. Nmap will do the DNS lookup for us and will scan the same IP twice, so should we add NSE DNS lookup functions (Kris has already done some part of it, in his resolveall prerule script [1]) and do the DNS lookup in target.add () function ? Personally I prefer to allow only IPs targets for the moment and when we have a better target filtering engine that checks for already processed IPv4/IPv6 in TargetGroup::parse_expr () and nexthost() functions, then we should allow hostnames and different network specifications that are supported by Nmap, and we could even use a vector to store the new added targets instead of a tree so it will be easy to read and remove the targets from the new_targets_cache vector. Any new NSE valid IP checking should go in the ipOps.lua library. To sum it up: I'm for allowing only new IPs for the moment and make adding new hostnames and networks targets future features, what do you think ? Other points: * Should we make target filtering a default behaviour and add an Nmap option to disable it like: "--no-targetfilter" or disable it by default and add an option to enable it ? Scanning the duplicate IPs can also be useful if we want to scan http virtual hosts. * Should we create a new Nmap option "--max-newtargets <num hosts>" that will set the maximum of the new added targets ? it will only be used if the user specified it. --max-newtargets=0 means to not allow any addition of new targets even if the script argument "newtargets" is specified. Of course with this we'll give *more* *control* to the user, but in the other hand he is supposed to do network exploration and if set then it will for sure ignore some new discovered targets (hidden IPs!!). I prefer to add support for this option and let the user take his responsability. Your opinion ? N.B: currently new NSE Added targets are processed like targets that are from: cmdline target specification, or iL <inputfilename> or -iR <num hosts>. Thx. [1] http://seclists.org/nmap-dev/2010/q3/327 -- tixxdz _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/-- Ron Bowes http://www.skullsecurity.org http://www.twitter.com/iagox86 <dhcp-find-targets.nse>_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/-- Patrik Karlsson http://www.cqure.net http://www.twitter.com/nevdull77 _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
-- Ron Bowes http://www.skullsecurity.org http://www.twitter.com/iagox86
Attachment:
_bin
Description:
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Adding new NSE discovered targets to Nmap Djalal Harouni (Aug 12)
- Re: Adding new NSE discovered targets to Nmap Ron (Aug 12)
- Re: Adding new NSE discovered targets to Nmap Patrik Karlsson (Aug 12)
- Re: Adding new NSE discovered targets to Nmap Ron (Aug 12)
- Re: Adding new NSE discovered targets to Nmap Daniel Miller (Aug 13)
- Re: Adding new NSE discovered targets to Nmap Djalal Harouni (Aug 13)
- Re: Adding new NSE discovered targets to Nmap Patrik Karlsson (Aug 13)
- Re: Adding new NSE discovered targets to Nmap Fyodor (Aug 15)
- Re: Adding new NSE discovered targets to Nmap Ron (Aug 15)
- Re: Adding new NSE discovered targets to Nmap Patrik Karlsson (Aug 15)
- Re: Adding new NSE discovered targets to Nmap Fyodor (Aug 16)
- Re: Adding new NSE discovered targets to Nmap Patrik Karlsson (Aug 16)
- Re: Adding new NSE discovered targets to Nmap Ron (Aug 16)
- Re: Adding new NSE discovered targets to Nmap Patrik Karlsson (Aug 12)
- Re: Adding new NSE discovered targets to Nmap Ron (Aug 12)
- Re: Adding new NSE discovered targets to Nmap David Fifield (Sep 19)