Re: Jiayi's Status Report - #17 of 17

[Daniel Miller <bonsaiviking () gmail com>]

Paulino,

On Wed, Sep 16, 2015 at 9:13 AM, Paulino Calderon <paulino () calderonpale com>
wrote:

> I find it very useful for those cases when the product name and version
> are not determined correctly. It allows you to enter a custom lookup
> string. Maybe we could also incorporate an option to even skip the check if
> the version is too generic and avoid returning a lot of false positives.


Would this be a problem with the product name Nmap sets via -sV, or with
the database, or with the version matching logic? If it's the first, then
maybe there are corrections we should make to the nmap-service-probes file.
If the last, then can that be improved? Does the matching process take into
account CPE descriptors, which are standardized for this very purpose?

Overall, though vulscan is an exciting idea, I am beginning to question
whether it really fits in NSE. The biggest clue is this interactive mode.
If the vulscan process can be interrupted for the user to fiddle with the
mapping of Nmap results to vulnerabilities, then can't the mapping process
happen after-the-fact, with Nmap results being provided in XML? A mapping
process like that could be re-run many times after making minor adjustments
without needing to re-run the actual scan or pause it for user input.

Also, what happens when the service is identified by a version-category NSE
script which is scheduled to run *after* vulscan does? This could be
avoided by running in the hostrule phase, but is just a symptom of the
issue I'm talking about.

The answer, as I see it, is to improve the output of Nmap's version
detection so that it can be properly consumed by tools that need to match
against databases for any reason. This is a purpose for which vulscan could
be helpful: to help identify weak areas in how Nmap identifies services
relative to the most common data sources that our users care about. But I
don't feel as though NSE is the best place for it

Dan

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