Re: [BUG] Exclusions directive not honored by NSE version detection

[Tom Sellers <nmap () fadedcode net>]

On 5/17/10 9:35 PM, David Fifield wrote:
> On Fri, Apr 30, 2010 at 05:16:59PM -0500, Tom Sellers wrote:
> > I have recently come across a bug involving port exclusions when
> > performing version
> > detection.   I plan to work on finding a fix for the issue this weekend,
> > but I thought I would go
> > ahead and send the info to the list now in the event that my work was
> > delayed or someone
> > had an idea of exactly where the issue lay.
> >
> > Recent scanning shows that the Exclude directive in the
> > nmap-service-probes file is being
> > ignored by NSE version detection if more than one port is scanned on a
> > host.  The nmap
> > built in version detection skips the port, but NSE runs version
> > detection scripts against the
> > port anyway.
> >
> > Testing indicates:
> > 1.  Scanning 1 port in exclude list = proper behavior
> > 2.  Scanning 2 ports in the exclude list = proper behavior
> > 3.  Scanning 1 or more excluded ports and 1 or more non-excluded ports =
> > NSE service scan against excluded ports
>
> Are you sure about these conditions? It seems to me that NSE doesn't
> honor the excluded ports in any case. I made a version script that runs
> for every port,
>
> description = ""
> categories = {"version"}
> portrule = function(host, port)
>         return true
> end
> action = function(host, port)
>          port.version.name = "version-run"
>          port.version.product = "version script run"
>          nmap.set_port_version(host, port, "hardmatched")
> end
>
> It looks like it runs no matter what.
>
> $ ./nmap --datadir . -sV localhost -Pn -n -p 9100
> PORT     STATE SERVICE     VERSION
> 9100/tcp open  version-run version script run
>
> $ ./nmap --datadir . -sV localhost -Pn -n -p 9100,9101
> PORT     STATE SERVICE     REASON  VERSION
> 9100/tcp open  version-run syn-ack version script run
> 9101/tcp open  version-run syn-ack version script run
>
> $ ./nmap --datadir . -sV localhost -Pn -n -p 80,9100
> PORT     STATE SERVICE     VERSION
> 80/tcp   open  version-run version script run
> 9100/tcp open  version-run version script run
>
> (This is with Ncat listeners on the scanned ports.)
>
> I guess it makes sense for version-category NSE scripts to use the same
> exclusions as normal version detection, but I don't know that it has
> come up before.

Of course you are correct.

It looks like this problem I reported was fixed by you in change 17432 the
same day that I reported the issue originally.

I dug around a bit in the changes between my email and now and found that
reverting portlist.cc to the version 17432 reproduced the original issue.

For some time prior to this change the excluded port service was apparently
not being set which I think triggered the port rule in skypev2-version.nse.
Normally the portrule of this script would only run if the port was 80, 443
or if the service was nil, blank or unknown.  Historically this script would
skip 9100, and then at some point a change was made and the skype script
would (I think) see the service as unknown and scan it resulting in a couple
pages of print on printers.

After your change excluded port service names are looked up which I think is
enough to stop the Skype version script from hitting it as long as it doesn't
match other criteria.

What I still don't understand is why the behavior changed depending on whether
I was scanning only excluded ports vs a mix of excluded and non-excluded.

Ah well...

The end result is that the original functionality (skipping ports due to
intelligent port rules) has been restored.

To me it would make sense if ports flagged in Exclude directive were excluded
from both normal version scanning as well as script version scanning.  While
I could see an argument for scripts not being subject to this due to being
able to include better logic, it would seem that every script in the Version
category would have to keep in mind that some ports (which may change in the
future) should not be scanned unless you really know how to handle them.

Any thoughts on this?

Thanks much,

Tom









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