Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Output|Input pipe and forcing script run
From: Patrik Karlsson <patrik () cqure net>
Date: Sat, 30 Apr 2011 12:21:54 +0200


On Apr 30, 2011, at 9:53 AM, David Fifield wrote:

On Mon, Nov 29, 2010 at 12:02:04AM +0100, Martin Holst Swende wrote:
Hi,

On 10/03/2010 04:48 PM, David Fifield wrote:
On Wed, Sep 29, 2010 at 10:47:37AM +0200, Martin Holst Swende wrote:
Also, a while ago there was a discussion about forcing a script to be
run . That is a feature I would really love. Is anybody working on that?
Fyodor suggested placing the patch in NSE, if that means in "lua-space"
I could implement that if given some hints on where to place it.
First you should try implementing this in the shortport library. Add a
check to each of the functions for the script argument "force":

local force = stdnse.get_script_args("force")

Then try running some scripts with this to see how it works. I think
there will be unexpected surprises when forcing scripts to run with the
large number of ports Nmap scans by default.

The next step is to make it apply to all scripts in nse_main.lua. Try
editing the "main" function in Script:new_thread. That's where the rules
are actually called and can be overridden.

Keep us updated with patches and your progress. I am interested to see
how this works.
A lot of other things have got in the way, but tonight I did a first
stab at it. It was trivial to implement, and you can check it out at the
usual place; at
http://martin.swende.se/hgwebdir.cgi/nsescripts/rev/48ee0f905d68 (<--
NOT tip) you can see the diff from the original. With my patch you can
do e.g.
nmap www.google.com -p80 --script firewalk --script-args=force=1 -d3

I want to reopen discussion about forcing a script to run. I tried this
patch and it works as I expect. The problem I see is that there are easy
ways to accidentally and confusingly use it.

nmap --script-args force -d2 localhost -sC -F

This is going to run every default script against every open port:

NSE: Starting runlevel 1 (of 1) scan.
NSE: Starting 'ms-sql-info' (thread: 0x91cb7d0) against 127.0.0.1.
NSE: Starting 'nbstat' (thread: 0x90dc580) against 127.0.0.1.
NSE: Starting 'p2p-conficker' (thread: 0x909b348) against 127.0.0.1.
NSE: Starting 'smb-os-discovery' (thread: 0x90c17f8) against 127.0.0.1.
NSE: Starting 'smbv2-enabled' (thread: 0x916aee8) against 127.0.0.1.
NSE: Starting 'auth-owners' (thread: 0x91ecad8) against 127.0.0.1:6000.
NSE: Starting 'backorifice-info' (thread: 0x90bf0e8) against 127.0.0.1:6000.
NSE: Starting 'dhcp-discover' (thread: 0x91ea950) against 127.0.0.1:6000.
NSE: Starting 'dns-recursion' (thread: 0x8fd3d40) against 127.0.0.1:6000.
NSE: Starting 'dns-service-discovery' (thread: 0x916c240) against 127.0.0.1:6000.
NSE: Starting 'dns-zone-transfer' (thread: 0x8fba2a8) against 127.0.0.1:6000.
NSE: Starting 'epmd-info' (thread: 0x8fd6288) against 127.0.0.1:6000.
NSE: Starting 'finger' (thread: 0x8fb8648) against 127.0.0.1:6000.
NSE: Starting 'ftp-anon' (thread: 0x9123040) against 127.0.0.1:6000.
NSE: Starting 'ftp-bounce' (thread: 0x91d8110) against 127.0.0.1:6000.
NSE: Starting 'gopher-ls' (thread: 0x8fcd4a8) against 127.0.0.1:6000.
NSE: Starting 'hddtemp-info' (thread: 0x920e1d0) against 127.0.0.1:6000.
NSE: Starting 'http-auth' (thread: 0x8fb83c0) against 127.0.0.1:6000.
NSE: Starting 'http-favicon' (thread: 0x90bfa88) against 127.0.0.1:6000.
NSE: Starting 'http-methods' (thread: 0x9123988) against 127.0.0.1:6000.
NSE: Starting 'http-open-proxy' (thread: 0x90c1390) against 127.0.0.1:6000.
NSE: Starting 'http-robots.txt' (thread: 0x9213b18) against 127.0.0.1:6000.
NSE: Starting 'http-title' (thread: 0x90ef6f8) against 127.0.0.1:6000.
NSE: Starting 'http-vmware-path-vuln' (thread: 0x91f0ca8) against 127.0.0.1:6000.
NSE: Starting 'imap-capabilities' (thread: 0x91ce880) against 127.0.0.1:6000.
NSE: Starting 'irc-info' (thread: 0x91d02c8) against 127.0.0.1:6000.
NSE: Starting 'mongodb-databases' (thread: 0x91c5f68) against 127.0.0.1:6000.
NSE: Starting 'mongodb-info' (thread: 0x91c1ea8) against 127.0.0.1:6000.
NSE: Starting 'mysql-info' (thread: 0x91bb298) against 127.0.0.1:6000.
NSE: Starting 'nat-pmp-info' (thread: 0x91b9a08) against 127.0.0.1:6000.
NSE: Starting 'netbus-info' (thread: 0x913ebc8) against 127.0.0.1:6000.
NSE: Starting 'ntp-info' (thread: 0x90fcd10) against 127.0.0.1:6000.
NSE: Starting 'pop3-capabilities' (thread: 0x90db0c8) against 127.0.0.1:6000.
NSE: Starting 'quake3-master-getservers' (thread: 0x90c6700) against 127.0.0.1:6000.
NSE: Starting 'realvnc-auth-bypass' (thread: 0x9047570) against 127.0.0.1:6000.
NSE: Starting 'rmi-dumpregistry' (thread: 0x9033318) against 127.0.0.1:6000.
NSE: Starting 'rpcinfo' (thread: 0x91f2940) against 127.0.0.1:6000.
NSE: Starting 'servicetags' (thread: 0x91ca4c8) against 127.0.0.1:6000.
NSE: Starting 'smtp-commands' (thread: 0x9168e20) against 127.0.0.1:6000.
NSE: Starting 'snmp-interfaces' (thread: 0x9158670) against 127.0.0.1:6000.
NSE: Starting 'snmp-netstat' (thread: 0x9157710) against 127.0.0.1:6000.
NSE: Starting 'snmp-processes' (thread: 0x91e7d60) against 127.0.0.1:6000.
NSE: Starting 'snmp-sysdescr' (thread: 0x923f990) against 127.0.0.1:6000.
NSE: Starting 'snmp-win32-services' (thread: 0x91c2b40) against 127.0.0.1:6000.
NSE: Starting 'snmp-win32-shares' (thread: 0x91bf2d8) against 127.0.0.1:6000.
NSE: Starting 'snmp-win32-software' (thread: 0x909ba20) against 127.0.0.1:6000.
NSE: Starting 'snmp-win32-users' (thread: 0x917e6f8) against 127.0.0.1:6000.
NSE: Starting 'socks-open-proxy' (thread: 0x9177f38) against 127.0.0.1:6000.
NSE: Starting 'ssh-hostkey' (thread: 0x9156f90) against 127.0.0.1:6000.
NSE: Starting 'sshv1' (thread: 0x9144378) against 127.0.0.1:6000.
NSE: Starting 'sslv2' (thread: 0x9237d40) against 127.0.0.1:6000.
NSE: Starting 'upnp-info' (thread: 0x913a048) against 127.0.0.1:6000.
NSE: Starting 'wdb-version' (thread: 0x91034b8) against 127.0.0.1:6000.
NSE: Starting 'wsdd-discover' (thread: 0x90cb6d0) against 127.0.0.1:6000.
NSE: Starting 'x11-access' (thread: 0x90d4e38) against 127.0.0.1:6000.

I think that a global "force" option only makes sense if 1) you are
narrowly targeting a list of ports and 2) you are narrowly limiting the
set of scripts. Can we think of a way to make this work naturally
without strange cases like the above?

My first thought is that you usually only want one or a few scripts to
be forced. So what if we invent a new syntax that allows applying the
force script to one script only? I don't think this is a good syntax,
but it will illustrate what I mean:

nmap www.google.com -p80 --script force:firewalk

This is no more typing in the (expected) case when only one script is
used. It would be possible to run one script forced and one non-forced,
though I don't have a realistic use case for that.

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


I've discussed this a number of times with Martin. As far as I remember Martin had the problem with RMI popping up on 
different ports and I had the same problem with MsSQL instances.
The use case (or problem) here is that you don't wan't to spend a humongous amount of time with the highest service 
detection intensity to discover a service you already know is running on a specific port.
What you wan't to do instead is basically tell Nmap that you know that port 1234 is MsSQL or RMI and that it should 
treat it that way a match all portrules as if it had been detected that way.
At some point I came up with the "named probe" approach, which would allow you to select a specific probe (or multiple 
ones) and simply run them against the ports you were scanning.
We both agreed that this would solve the problem in a more elegant way. I've sent a number of e-mails requesting 
feedback about this in the past but haven't received any response (except from Martin).
This could be either because I haven't been clear enough with the intensions or maybe the idea simply sucks.
Anyway, in my personal opinion, I would rather have something like that than the force argument. 
The problem with this approach is that it wouldn't cover your example with firewalk, which is triggered by a hostrule.

//Patrik

--
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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]