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

[Paulino Calderon <paulino () calderonpale com>]

Hey Daniel,

The script only takes in consideration the name of the service. For example, Apache servers correctly configured won’t 
reveal their version number and -sV will only determine the product name. Not really a problem with the version 
detection database or the probes. 

I think we can get rid of the version detection argument and force the script to only match results when a numeric 
version is obtained. This will basically lead to only execute script when version detection obtained the product name 
and version number. But leaving the script argument does provide more flexibility as it allow users to match only 
product names with the database if they want to. 

Yes, interactive mode is kinda odd (You can’t see the input or modify it ). The script does not change the value of the 
version information found by Nmap and it simply uses the user input to query the databases. For that reason I think 
your point about making the mapping process at the end is a good idea, specially since users would be able to basically 
query the database as many times as they need to. And of course maybe we will be better off without interactive mode as 
it seems some of the issues can’t be fixed. 

However, I feel the script is a good starting point to obtain possible vulnerabilities affecting hosts using our 
powerful version detection mode/database. In all the occasions when a version number is obtained correctly, the script 
will yield meaningful results. I agree it still needs more work to address all these issues but I definitely think it 
will be handy during penetration testing engagements. 

Cheers.

> On Sep 16, 2015, at 10:54 PM, Daniel Miller <bonsaiviking () gmail com> wrote:
>
> Paulino,
>
> On Wed, Sep 16, 2015 at 9:13 AM, Paulino Calderon <paulino () calderonpale com <mailto: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/