'Re: Output|Input pipe and forcing script run'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nmap-dev
Subject:    Re: Output|Input pipe and forcing script run
From:       Patrik Karlsson <patrik () cqure ! net>
Date:       2011-04-30 10:21:54
Message-ID: 14E678A9-7648-481B-91FE-D5E92B21C3DA () cqure ! net
[Download RAW message or body]

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/

[prev in list] [next in list] [prev in thread] [next in thread] 