Nmap Development mailing list archives
Re: [RFC] Vulnerability library proposal
From: Djalal Harouni <tixxdz () opendz org>
Date: Tue, 9 Aug 2011 02:22:14 +0100
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/
Current thread:
- Re: [RFC] Vulnerability library proposal, (continued)
- Re: [RFC] Vulnerability library proposal Christian Heinrich (Aug 09)
- Re: [RFC] Vulnerability library proposal Djalal Harouni (Aug 09)
- RE: [RFC] Vulnerability library proposal Rob Nicholls (Aug 09)
- Re: [RFC] Vulnerability library proposal Christian Heinrich (Aug 09)
- RE: [RFC] Vulnerability library proposal Rob Nicholls (Aug 09)
- Re: [RFC] Vulnerability library proposal Djalal Harouni (Aug 09)
- Re: [RFC] Vulnerability library proposal Djalal Harouni (Aug 12)
- Re: [RFC] Vulnerability library proposal Djalal Harouni (Aug 09)
- Re: [RFC] Vulnerability library proposal Christian Heinrich (Aug 09)
- Re: [RFC v2] Vulnerability library proposal Marc Ruef (Aug 12)
- Re: [RFC v2] Vulnerability library proposal Djalal Harouni (Aug 12)