Re: Script force

[Patrick Donnelly <batrick () batbytes com>]

Hi Martin,

On Sat, Dec 3, 2011 at 4:41 PM, Martin Holst Swende <martin () swende se> wrote:
> > > Here are some test cases I tried:
> > >
> > > script name                  dport   runs?
> > > http-title                   -p22            no
> > > +http-title                  -p22    yes
> > > http-title,http-title                -p22            no
> > > http-title,+http-title               -p22            no
> > > +http-title,http-title               -p22            no
> > > +http-title,+http-title              -p22    yes
> > > http-title or http-title     -p22            no
> > > http-title or +http-title    -p22            no
> > > +http-title or http-title    -p22            no
> > > +http-title or +http-title   -p22            no
> > All of them are supported.
> These are my results when testing the patch:
> nmap scanme.nmap.org -p22 --script +http-title -d2
> #NSE: Script http-title.nse was selected by name and forced to run.
> nmap scanme.nmap.org -p22 --script "http-title,+http-title" -d2
> #NSE: Script http-title.nse was selected by name and forced to run.[1]
> nmap scanme.nmap.org -p22 --script "http-title,+http-*" -d2
> #NSE: Script http-title.nse was selected by name.[2]
> #All other http-* was were forced
> nmap scanme.nmap.org -p22 --script "+http-title,http-title" -d2
> #NSE: Script http-title.nse was selected by name and forced to run.
> nmap scanme.nmap.org -p22 --script "+http-title,+http-title" -d2
> #NSE: Script http-title.nse was selected by name and forced to run.
> nmap scanme.nmap.org -p22 --script "http-title or http-title" -d2
> #NSE: Script http-title.nse was selected by name.
> nmap scanme.nmap.org -p22 --script "http-title or +http-title" -d2
> #NSE: Script http-title.nse was selected by name and forced to run.
> nmap scanme.nmap.org -p22 --script "+http-title or http-title" -d2
> #NSE: Script http-title.nse was selected by name and forced to run.
> nmap scanme.nmap.org -p22 --script "+http-title or +http-title" -d2
> #NSE: Script http-title.nse was selected by name and forced to run.
> nmap scanme.nmap.org -p22 --script "http-title or +http-*" -d2
> #NSE: Script http-title.nse was selected by name. [3]
> #All other http-* was were forced

I've followed the development of this patch and find it very
interesting. I have some concerns:

o --script is used for choosing which scripts may run. I'm concerned
that the purpose will become convoluted because not only is the user
now choosing which scripts are allowed to run, the user is also
choosing which scripts *will* run. I feel like changing the meaning of
--script will only explode with the addition of other useful features
into something terribly difficult to manage and, most importantly,
difficult to explain to users.

o I'm worried about problems arising from the portrule being "skipped"
and the action function missing data set in the portrule. For example,
dns-zone-transfer.nse sets a few values in the portrule which would
not exist if the script were forced to run against an abnormal port.
Further, a script can't know it's being forced (with the current
patch) to run.

o Scripts would run against *every* open open|filtered port and would
probably produce meaningless output that is as much a burden on the
user as the original problem.

With that said, I have a suggestion. The '+' should be a prefix to a
pattern. It should not be a prefix to a filename, category, or boolean
expression. It should change the meaning of the entire expression:
"any script chosen as a result of this expression is forced to run".
So, you might have: --script '+not intrusive and not discovery'. This
would mean, "forcibly run all scripts that are not in the intrusive
and not in the discovery categories". [As an aside with respect to the
implementation: note that most script filenames are usually matched
and loaded via the Entry function. The code that runs after this
comment "-- Now load any scripts listed by name rather than by
category." loads files and directories that are not found in the
script database (the script database is a series of calls to the Entry
function). For example, that fallback code would load scripts
specified by "my-scripts/foo.nse" or a directory "my-scripts".

With that changed, I think the patch would be much nicer. However...

My position would be that this is better solved by the user with
--script-args and scripts having some abstraction to make forcing
execution simple. In your original use-case, you describe the problem
of having scripts run against services on non-standard ports:

"The primary usecase people seem to have is that they e.g. do a
configuration review of a lot of ms-sql servers, say you have a list of
20 servers where the database is located on an uncomon port. They don't
want to have to do -sV --version-all just to run a script, since they
already know what's on the port.

I myself was recently stung by this when testing the new hadoop-*
scripts [1]. If I were to write a solution using the current system, I
would probably change the shortport "port_or_service" function to
allow the user to say "this port is running this service". A user
might say --script-args "services.ms-sql-s = {23,24}" where 23 and 24
are the non-standard ports. Scripts which then do:

portrule = shortport.port_or_service({standard_ports}, {"ms-sql-s"},
"tcp", "open");

would still run. The shortport function would take into account the
--script-arg and understand that the ms-sql-s service is running on
the port(s) 23 and 24 even though version checking wasn't done.

As a specific example for my problem with the hadoop scripts [2]. I
would see running the following command instead:

nmap --script hadoop-* --script-arg
'service.hadoop-region=8000,service.hadoop-tasktracker=8000,service.hadoop-namenode=8001,service.hadoop-datanode=8002,service.hadoop-jobtracker=8003'
namenode.hadoop.example.edu disc1.hadoop.example.edu ...

What's nice about this design is that if the port is closed, the
shortport won't blindly run the script anyway against the port. The
script-arg would essentially be manually setting the service for each
port. The shortport function would ignore the version for the port and
instead use the service -> port mapping given in the script-arg. On
the other hand, if the user doesn't know which ports the services are
running on, the user would be out of luck. But isn't that why we have
version scanning?

This solution I propose is indeed more complicated and gives more work
to the user. There is a good side and bad side to that argument.
Something to think about...

[1] http://seclists.org/nmap-dev/2011/q4/102
[2] http://seclists.org/nmap-dev/2011/q4/58

-- 
- Patrick Donnelly
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/