English | Deutsch
Home »

NVT Development

This page collects hints and guides for developing Network Vulnerability Tests.

How to start

The NVT development is not well documented.
But you will find other developers for questions and discussions on the NVT Development Mailing List

The best start is to learn from existing NASL scripts.
There is also a template you can begin with: template.nasl

License requirements: We welcome any contribution licensed under GNU GPLv2+.
These can easily go into the OpenVAS Feed to benefit everyone.
Other licenses might create legal conflicts and in doubt you should simply ask the other NVT developers.

Golden Rules

This is a collection assembled over time from lessons learned.

How to write a product detection NVT

It is very important for the NVT Feed that we separate the work of the detection a certain product from actual vulnerability evaluation. The actual detection NVTs should result a CPE code for the product. If none is available yet, it needs to be registered with NIST. Also it is very important to explain the method how the product was detected (description) and where it was detected (result).

A good example for a authenticated product detection is gb_openssl_dectect_lin.nasl. Watch out for these elements:

How to write a policy NVT

A policy NVT does not search for a documented general vulnerability. It rather tests a target system for properties that a user defines.

In order to allow the user to configure the severity level, a policy is split into 4 parts. For the following example you will find a reference implementation with NAME=file_checksums:

The routines "_violation", "_ok" and "_error" report log level. The user can define appropriate Overrides in the Manager and assign severities as felt appropriate. Those Overrides are typically configured to be applied generally for all tasks and/or IPs.

Developers should implement their policies as close to the reference example as possible, especially in terms of naming scheme and code structure.

Miscellaneous

How to assign a CVSS to a NVT

Any new NVT must be provided with a CVSS Score and a CVSS Base Vector.

Common Vulnerability Scoring System (CVSS) is an industry standard for assessing the severity of computer system security vulnerabilities. CVSS is composed of three metric groups:

  1. Base Metrics
  2. Temporal Metric Group
  3. Environmental Metric Group

For NVT development purposes, we only use Base Metrics. Where linked to other security information (for example CVE), these are automatically updated over time. The information is captured in the following tags in NVT:

script_tag(name:"cvss_base", value:"x.x");
script_tag(name:"cvss_base_vector", value:"AV:N/AC:M/Au:N/C:P/I:C/A:C");

Follow these steps for assigning a CVSS:

  1. If there is a CVE for which NVT is being developed, take the CVSS score already computed from NVD (National Vulnerability Database), http://web.nvd.nist.gov/view/vuln/search.

    In case multiple CVEs are referenced, pick the one with the Maximum CVSS Base and take the corresponding CVSS Base Vector.

    It is not allowed to apply any other CVSS in case at least one CVE is referenced that offers a CVSS. In case author likes to apply another CVSS, a second NVT should be added that has no CVE reference and a CVSS of its own. However, the better approach is to submit a rationale to NIST if you think the CVSS is wrong for the respective vulnerability.

  2. If there is a CVE for which NVT is being developed and if CVSS is not yet available at NVD, manually compute the CVSS score based on the guideline described below.

  3. If there is non-CVE vulnerability reference for which NVT is being developed, manually compute the CVSS score based on the guidelines described below.

Scoring Guidelines

Base score is a score in the range of 0.0-10.0 at steps of 0.1. The attributes for computing CVSS Base Score are:

  1. Access Vector

    The metric reflects how the vulnerability is exploited. Possible values are:

    • Local(L): local system, shell account
    • Adjacent Network(A): Attack is from an adjacent network
    • Network(N): Through network

  2. Access Complexity

    Measures the complexity of the attack required to exploit the vulnerability. Possible values are:

    • High(H): If it is too complex to perform an attack. For example, not a default configuration race condition
    • Medium(M): Some kind of privilege is required, non-default setting
    • Low(L): easy to exploit

  3. Authentication

    Measures the number of times an attacker must authenticate to a target in order to exploit. Possible values are:

    • Multiple(M): multiple authentication is required
    • Single(S): one instance of authentication is required
    • None(N): No authentication is required

  4. Confidentiality

    Measures the impact on confidentiality of a successfully exploited vulnerability. Possible values are:

    • None(N)
    • Partial(P)
    • Complete(C)

  5. Integrity

    Measures the impact to integrity of a successfully exploited vulnerability. Possible values are:

    • None(N)
    • Partial(P)
    • Complete(C)

  6. Availability

    Measures the impact to availability of a successfully exploited vulnerability. Possible values are:

    • None(N)
    • Partial(P)
    • Complete(C)

Base Metrics: AV:[L,A,N]/AC:[H,M,L]/Au:[M,S,N]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C]

The following tips can be applied while scoring: