Nmap Development mailing list archives

Previous By Date Next
Previous By Thread Next

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/
Previous By Date Next
Previous By Thread Next

Current thread: