Re: [RFC] Vulnerability library proposal

[Djalal Harouni <tixxdz () opendz org>]

On Mon, Aug 08, 2011 at 11:10:21AM +0200, Marc Ruef wrote:
> Dear list,
> Dear Djalal, (copy)
> Dear Stefan, (copy)
Hi Marc.

> > This is a proposal for a new NSE vulnerability library. The library is
> > designed to help managing discovered vulnerabilities and to make the
> > output more consistent.
>
> I'm very happy that this proposal has been made.
>
> It appears that some of our approaches discussed in [1] and [2] were 
> already included in the initial post.
Yes we have made plans for your vulscan script, I think that after we
finish this library we'll update the script, change the name into
osvdb-vuln.nse (making sure that we respect the OSVDB license terms) and
try to include it into Nmap.

> Those moduls are important for our pentesting work at scip AG[3] and 
Of course the script is your and scip AG contribution, I hope it will be
Ok.

> therefore we put a lot of effort to improve these. Since our public 
> releases mentioned before we've implemented a lot of enhancements. 
> Therefore I'd like to include our (latest) ideas and decisions in this 
> reply (some are also suggested by Stefan Friedli).
Thanks for sharing.

> > * The library must handle different states:
> >    UNKNOWN:  We don't know the state of the vulnerability.
> >    LIKELY_VULN: The program seems vulnerable (check and compare versions)
> >    NOT_VULN: The program was confirmed not to be vulnerable.
> >    VULN: The program was confirmed to be vulnerable.
>
> We have decided to use a percentage value to determine the accuracy of a 
> vulnerability. This makes it a lot easier to distinguish between 
> different likelihoods.
>
> This does also provide the possibility to assign checks to different 
> accuracy categories. As I have documented in my last book "The Art of 
> Penetration Testing"[4] we divide between:
>
> * Derivative (e.g. HTTP-only is enabled => Missing encryption is a flaw)
> * Scanning (e.g. banner-grabbing, CGI scanning as file detection)
> * Exploitation (e.g. read access via SQL injection)
>
> Usually we assign these accuracy levels to the categories by default:
>
> * Derivative   = 50%
> * Scanning     = 80%
> * Exploitation = 99%
>
> But it might be possible that some checks deviate from these default values.
I must admit this can be a nice idea that covers multiple security paradigms
and vulnerabilities, this can also extend Nmap checks. You even cover
exploitation states which are missing from our initial proposal.

To generate a _possible_ correct accuracy we must identify some input
keys that will be computed with the other presented vulnerability input.
I'll try to think more about this, however I'm sure that this is the kind
of research that requires time and a good knowledge with the
vulnerability environment.

> >   - IDS: CVE, OSVDB, BID ...  (mandatory field). The IDs entries will
> >                               help the library to reference
> >                               vulnerabilities and to track duplicate
> >                               ones.
>
> It appears important that NSE vulscan scripts also include their own 
> IDs. Dependence to title or other IDs isn't a good idea (e.g. what if no 
> CVE is available yet).
Ok, Rob Nicholls has also suggested this, it seems that I must find a
better way.

> Furthermore, external IDs shouldn't be mandatory. Sometimes we write 
> checks for individual flaws or unreleased 0-days.
To be clear, we do not require _external_ IDs just an ID. But perhaps
now I'll make the library generate an internal ID if the script did not
provide one, of course we'll not display it to users.

> >    - "Risk factor": if present then show it (optional).
>
> We may suggest to define a solid risk factor definition. Something like 
> CVSS would be good (but is also flawed, as I have documented in [5]). If 
> no formal approach is used, at least a clear formulation of risk levels 
> is required. Some comparison between our approach, Qualys and Nessus is 
> available at [6].
>
> We do also include a harmful and intrusive level field in our plugins. 
> This indicates access attempts which may cause DoS or manipulation of 
> data. This makes it possible to prevent to run those checks if necessary 
> (but might be handled by Script Categories[7].
Right.

> > * Search and return a list of vulnerability entries according to the
> >    specified selection filter.
> >    function vulns.find(selection_filter)
> >
> >    selection_filter is a table with the current fields:
> >      state: The state mask (optional field).
> >      hosts_filter: A function that will inspect the host table and returns
> >                    true or false. (Optional field).
> >      ports_filter: A function that will inspect the host and port tables
> >                    and returns true or false. (Optional field).
> >      risk_factor: The risk factor (optional).
> >      id_type: The ID type ('CVE', 'OSVDB' or whatever) (optional).
> >      id: The vulnerability ID (optional).
>
> It would be great if there are also vulnerabilities listed which were 
> not tested or/nor found.
If scripts register them then you can list any vulnerability, just use
the 'bitwise OR' to define the state mask.
 state = vulns.State.NOT_VULN
 state = bit.bor(vulns.State.NOT_VULN, vulns.State.VULN, ...)


> Regards,
>
> Marc
>
> [1] http://seclists.org/nmap-dev/2010/q2/726
> [2] http://seclists.org/nmap-dev/2010/q4/438
> [3] http://www.scip.ch/
> [4] http://www.computec.ch/mruef/?s=dkdpt
> [5] http://www.scip.ch/?labs.20101209
> [6] http://www.scip.ch/?labs.20090814
> [7] http://nmap.org/book/nse-script-format.html#nse-format-categories

Thanks Marc, Stefan for these suggestions and for the links.

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