Re: [NSE] Vulnerability Scan based on osvdb

[Marc Ruef <marc.ruef () computec ch>]

Hello David,

> > Your example with Apache proves the reasonability. But when nmap
> > determines "Microsoft IIS httpd 7.0" I've got a new problem.
>
> The "7.0" part of that will actually be separate; port.version.version
> instead of port.version.product. But the "Microsoft" problem remains.

I am sorry. You are right, of course. But because my initial intention 
was to take the port.version.version into account (osvdb provides the 
table object_versions) and to show that there may come some further 
problems (e.g. osvdb sometimes uses stuff like "2.0.x" as "wildcards"), 
I did use the "full" example.

> Maybe you can have a canonicalization table of common products that
> converts them to your preferred name.

Yes, this is what I thought initially (the "lookup table"). But I fear 
the large amount of data I would have to mangle (and that may change in 
the future for unknown reasons).

> (...)
> The output of this program is
>
> "Microsoft IIS httpd" ->  "IIS"
> "Apache httpd" ->  "Apache"
> "Apache Tomcat httpd" ->  "Tomcat"
> "thttpd" ->  "thttpd"

This is very nice code! I might use that one, if you don't mind. (I 
would not hardcode the CANON_TABLE and use an external mask file instead.)

If I am not able to handle the comparison with algorithms, I am going to 
choose this approach. My current testing looks not bad so far ;)

> > I am going to do some more experiments which shall reveal the best
> > approach. On a long-term view the support of CPE still seems to be the
> > best decision.
>
> I have to say that personally, I don't see the use of CPE happening. It
> would be nice, but not nice enough to justify what I expect will be
> enormous maintenance costs. Also we never did research to see if there's
> a similar system that would suit us better.

I have to agree, although it is sad :(

I am discussing my ideas with many different people at the moment. In 
one of the discussions I suggested that nmap is providing the 
fingerprint data in very dedicated variables. It would be great if nmap 
is providing very clean data in those separate fields:

port.version.vendor   => "Microsoft"
port.version.product  => "IIS"
port.version.version  => "7.0"
port.version.extras   => "X-Powered-By found"
port.version.language => "Spanish"
port.version.patches  => "MS10-XXX"
port.version.purpose  => "httpd"

This way it is easier to provide a human-readable output or to access 
the fields for further enumeration. This would solve my problem (and 
provide additional possibilities for the future). What do you think?

Regards,

Marc

--
Marc Ruef | marc.ruef () computec ch | http://www.computec.ch/mruef/
_________________________________________________________________
Meine letzte Publikation: "Facebook Anwendungen Design-Schwachstelle" - 
http://www.scip.ch/?labs.20100521
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/