Adding third party nasl plugins to OpenVAS. If you want to develop nasl plugins for OpenVAS, you might be interested how to import them in scanner. So, I was also interested.

First of all, I decided to copy one of existing nasl scripts. I chose script that successfully detected vulnerability on a target host. Thus, in the case of importing error, I would know for sure that it’s not because of syntax errors in script, but, for example, because non-existing plugin signature.

I scanned target CentOS host, chose and copied script file, changed id of the script (oid) and script title, rebuilt database. Then I rescanned target host.

As you can see, new script is also in results. Pretty straightforward.

Now, let’s review the actual commands.

I installed OpenVAS from sources using my openvas_commander script. Read more about it in “Installing OpenVAS 9 from the sources“.

To update plugins from Greenbone Community Feed I run:

./openvas_commander.sh --update-content-nvt

From vulnerability scan report I know that CESA:2017:1095 was detected on a target host.

Here is the corresponding script:

/usr/local/var/lib/openvas/plugins/2017/gb_CESA-2017_1095_bind_centos7.nasl

I change id (oid) of the script to 1882695, add “EDITED” to the title and save new script to gb_CESA-2017_1095_edited.nasl:

# cat /usr/local/var/lib/openvas/plugins/2017/gb_CESA-2017_1095_bind_centos7.nasl | sed 's/882695/1882695/' | sed 's/CentOS Update for bind CESA-2017:1095 centos7/CentOS Update for bind CESA-2017:1095 centos7 EDITED/' > /usr/local/var/lib/openvas/plugins/2017/gb_CESA-2017_1095_edited.nasl
# cat /usr/local/var/lib/openvas/plugins/2017/gb_CESA-2017_1095_edited.nasl | grep "oid"
script_oid("1.3.6.1.4.1.25623.1.0.1882695");

NB. Actually, this new oid “1.3.6.1.4.1.25623.1.0.1882695” is in Greenbone space. Third party scripts should have id like this “1.3.6.1.4.1.25623.1.[contributor number].[plugin number]“. Read more about the scheme here.

I check that there are now plugins with this oid in OpenVAS feed:

# grep -nr "1.3.6.1.4.1.25623.1.0.1882695" /usr/local/var/lib/openvas/plugins/
/usr/local/var/lib/openvas/plugins/2017/gb_CESA-2017_1095_edited.nasl:28: script_oid("1.3.6.1.4.1.25623.1.0.1882695");

Ok, this oid is unique. Now let’s try to rebuild the knowledge base.

I restart the processes:

# ./openvas_commander.sh --kill-all
ps -aux | grep "openvassd"
root 5621 0.0 0.2 4560 2280 pts/3 S+ 00:51 0:00 grep openvassd

# ./openvas_commander.sh --start-all
# ps -aux | grep "openvassd"
root 5637 0.3 1.1 35716 11676 ? Ss 00:51 0:07 openvassd: Waiting for incoming connections
root 5695 0.0 0.2 4560 2168 pts/3 S+ 01:24 0:00 grep openvassd

Make sure that openvassd loaded all plugins and is ready for incoming connections.

Rebuilding database:

#openvasmd --rebuild --progress
Rebuilding NVT cache... done.

If everything is fine, you should have script in some compact form in /usr/local/var/cache/openvas/2017/ directory:

# cat /usr/local/var/cache/openvas/2017/gb_CESA-2017_1095_edited.nasl.nvti
[NVT Info]
OID=1.3.6.1.4.1.25623.1.0.1882695
Version=$Revision: 6003 $
Name=CentOS Update for bind CESA-2017:1095 centos7 EDITED
Copyright=Copyright (C) 2017 Greenbone Networks GmbH
CVEs=CVE-2017-3136, CVE-2017-3137
XREFs=CESA:2017:1095, URL:http://lists.centos.org/pipermail/centos-announce/2017-April/022390.html
Tags=last_modification=$Date: 2017-04-21 14:25:10 +0200 (Fri, 21 Apr 2017) $|creation_date=2017-04-20 06:33:48 +0200 (Thu, 20 Apr 2017)|cvss_base=10.0|cvss_base_vector=AV:N/AC:L/Au:N/C:C/I:C/A:C|qod_type=package|summary=Check the version of bind|vuldetect=Get the installed version with the help \nof detect NVT and check if the version is vulnerable or not.|insight=The Berkeley Internet Name Domain (BIND) \nis an implementation of the Domain Name System (DNS) protocols. BIND includes \na DNS server (named) a resolver library (routines for applications to use \nwhen interfacing with DNS) and tools for verifying that the DNS server is \noperating correctly.\n\nSecurity Fix(es):\n\n* A denial of service flaw was found in the way BIND handled a query\nresponse containing CNAME or DNAME resource records in an unusual order. A\nremote attacker could use this flaw to make named exit unexpectedly with an\nassertion failure via a specially crafted DNS response. (CVE-2017-3137)\n\n* A denial of service flaw was found in the way BIND handled query requests\nwhen using DNS64 with 'break-dnssec yes' option. A remote attacker could\nuse this flaw to make named exit unexpectedly with an assertion failure via\na specially crafted DNS request. (CVE-2017-3136)\n\nRed Hat would like to thank ISC for reporting these issues. Upstream\nacknowledges Oleg Gorokhov (Yandex) as the original reporter of\nCVE-2017-3136.\n|affected=bind on CentOS 7|solution=Please Install the Updated Packages.|solution_type=VendorFix
Dependencies=gather-package-list.nasl
MandatoryKeys=HostDetails/OS/cpe:/o:centos:centos, login/SSH/success, ssh/login/release
Family=CentOS Local Security Checks
Category=3

Now we are ready to rescan the host and to see our new plugin in scan results: