Re: [RFC] Vulnerability library proposal

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

Dear list,
Dear Djalal, (copy)
Dear Stefan, (copy)

> 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.

Those moduls are important for our pentesting work at scip AG[3] and 
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).

> * 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.

>   - 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).

Furthermore, external IDs shouldn't be mandatory. Sometimes we write 
checks for individual flaws or unreleased 0-days.

>    - "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].

> * 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.

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

--
Marc Ruef | marc.ruef () computec ch | http://www.computec.ch/mruef/
_________________________________________________________________
Meine letzte Publikation: "Effizientes Portscanning mit 
Porteinschränkungen" http://www.scip.ch/?labs.20110804
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/