Re: [NSE] Release of nmap nse vulscan 0.6

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

Hello Fyodor,

> >     http://www.computec.ch/mruef/?s=software&l=x
>
> Hi Marc.  This is exciting stuff, and I do think Nmap should include a
> script with this functionality!  I mean, in the ideal world, we would

Thank you for your kind words :)

> have checks for each important vulnerability which check in a more
> reliable way than simple OS, service, and version number comparison.

Of course. But as long as the data is available, why not using it.

> But we're not going to have such a comprehensive selection of checks
> any time soon, so there is a ton of value in a simple DB which just
> flags based on OS, service, application, and app version information.

I agree.

> We'd probably want disclaimers in cases where the results are
> reasonably likely to be off.  For example, if we don't know the app
> version number, it might make sense to still print the possible vuln,
> but note that it could already be patched in this version.  We'd want
> a similar disclaimer in cases where the app is commonly patched in
> place, without changing the version number.  We'd probably want to do
> the warning by default, and suppress it where signatures are marked as
> reliable.

The current implementation is relying on product names only. However, 
enhancing the correlations mode with additional version comparison is 
not that hard. (I didn't do that in the first release because I was a 
bit "disappointed" by the fact that osvdb is not linking all known 
product version to vulnerabilities.)

> Using OSVDB data is a clever idea, but it does have a couple concerns.
> One is the license (http://osvdb.org/license).  It imposes a number of
> (...)

Thank you for that feedback. I wasn't aware of that. I will take this 
into account within the next release of course.

> As you note, the OSVDB information is not canonicalize to match
> Nmap's version/OS detection strings.  So using OSVDB would presumably
> take a lot of work to modify one or the other.  And many OSVDB entries
> I've just browsed don't seem to have the vulnerable version numbers of
> the affected application.  We could do a rather brute-force text
> search like you're doing, but that seems to lead to many false
> positives.
>
> I haven't spent a lot of time examining the OSVDB data, so it may be
> the best approach.  But my initial thought is that it would be better
> for Nmap to have its own DB with simple signatures based on Nmap's
> service/application names, version numbers, and OS names.  Of course,
> during research, you could use factual data from OSVDB, CVE, and other
> sources to create signatures.  Also, the signatures would presumably
> include vuln reference numbers from OSVDB and CVE and/or a link to the
> original advisory on seclists or wherever, and/or a link to an NSE
> script for detecting or exploiting the vuln.
>
> My feeling is that if we could find a vuln DB which really has what we
> need, and then we can figure out the licensing to get it included in
> Nmap, that would be ideal.  So it is worth checking for that first.

Nope, I don't think so that there is a public and free vuldb available 
that comply our needs. (Perhaps Secunia is collecting this kind of 
detailed data. But an open project would be much nicer.)

> But assuming that can't be found, I think the best idea is to do our
> own system with signatures designed just for Nmap's needs.  That will

David Fifield and I were discussing adopting CPE earlier[1]. Perhaps we 
can follow the guidelines. Coincidentally Nessus announced CPE support 
just a few days after our discussion[2].

On the other hand: Why not enhancing the osvdb records with all the 
correct products-vulnerabilities linking and use this dataset? This 
would improve both projects at the same time.

> make it a much smaller and easier project than OSVDB as a whole.  I
> think if we started with a decent DB (even just 100 or 200 key
> vulnerabilities), we could get community contributions to help
> maintain it.  They key is that it has to start out in a useful enough

Do you think of this feature as completely independent from version 
detection? Wouldn't it make sense to merge version detection and 
"vulnerability detection" (e.g. naming conventions, data in the same 
fingerprint file, etc.)?

Otherwise I would prefer a simple and straight-forward approach (because 
of the easy maintenance and parsing):

<product> [version]\t<vuln_title>\t[CVE:<cve>|OSVDB:<osvdb>|...]\n

Example:

Apache httpd 1.2.3\tApache HTTP Server Example Buffer 
Overflow\tCVE:2010-xxxx;OSVDB:xxxx\n

Please take a look at my feedback at [3]. Perhaps the values in 
port.version.* could be enhanced/improved to enhance version detection 
and vulnerability detection? But this might be a core-dev issue.

> state to have critical mass to get people to start submitting new vuln
> sigs.  If it becomes popular enough, we could even create an online
> process for doing that as part of http://nmap.org/submit/.
>
> Anyway, thanks for starting this exciting project and I hope Nmap
> proper will have this functionality someday.

Of course, this would be great :)

Regards,

Marc

[1] http://seclists.org/nmap-dev/2010/q2/566
[2] 
http://blog.tenablesecurity.com/2010/05/common-platform-enumeration-cpe-with-nessus.html
[3] http://seclists.org/nmap-dev/2010/q2/568

--
Marc Ruef | marc.ruef () computec ch | http://www.computec.ch/mruef/
_________________________________________________________________
Meine letzte Publikation: "Nur ein Weg führt in den Server-Raum" - 
http://www.computec.ch/news.php?item.329
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/