Writing simple Nessus plugin

One of the key aspects of penetration testing is the automation of routine actions. Someone writes standalone programs for this, but now there are many products that allow you to extend their functionality with the help of additional modules. An example of a free vulnerability scanner with custom modules support is OpenVAS, but this article is about Nessus, which isn't free, but in my humble opinion, finds more and generates fewer false positives (although OpenVAS started as a fork of Nessus, but that was a long time ago). Let's get started.

Most Nessus modules are just plain text files written in some kind of scripting language and .nasl extension. Some modules are shipped in a binary form with .nbin extension, but let's not talk about those. The default paths for modules (or plugins) are the following (https://community.tenable.com/s/article/Location-of-Plugin-Directory):

There're lots of modules, more than 100 thousand, some of them were written a long time ago (judging by the code) and are almost not updated, although they implement scanning basics (for example, searching for common directory names), while often they are not parameterized in any way, which makes it necessary to manually edit the code, for example, in order to expand the built-in dictionary. But in this diversity you can always find a sample code to implement some specific function for your module.

As an example, we will write a trivial module for searching the database administration script Adminer (https://github.com/vrana/adminer/). There is a similar Nessus module for phpMyAdmin (https://phpmyadmin.net/).
Our module will search Adminer through possible paths, detect the version and set the resulting severity depending on it (before 4.6.3 version it was possible to read arbitrary files on a server with LOAD DATA LOCAL INFILE, more info on this issue is here).

It is worth noting that the documentation on the available API is peculiar and fragmentary, same actions in standard modules are sometimes implemented in different ways for no apparent reason, naming of some internal functions is questionable, possibly due to legacy code layer that Tenable (Nessus developer) does not clean out (maybe they don’t want to rewrite old modules and keep it for compatibility).

Here we go. Our module code begins with a unique internal identifier for it, as well as a description, release date, severity, CVE, etc. Practically everything is optional and serves only for convenient presentation in the web interface (modules can also be launched via console). I recommend using Ruby syntax highlighting. Actually modules are written in NASL, but resulting highlighting is acceptable.

Since the code is simple, I will describe the heart of the matter in paragraphs after the code fragments. In the fragment above, we set a unique identifier, version, date, description, and other attributes of the module. The attribute list is not complete, if there is a need to add an associated CVE, CVSS, etc. — see the examples in the standard modules. At the end we set the category of the module - "CGI abuses" - and several conditions. We need the webmirror.nasl module to run before the start of our module. This module searches for standard paths and stores them in some global structures that can then be used by other modules. Next, we set the conditions so that our module does not start if CGI scanning is explicitly disabled by the scanning policy (https://www.tenable.com/blog/nessus-web-application-scanning-new-plugins-configuration) or web applications testing is disabled. Next, we add a requirement, so that Nessus will scan for and identify ports of web servers before our module starts. Finally, we set the running timeout for our module.

This is how the information about module looks like in the Nessus web interface.

To search for possible paths, we need a list of versions, as well as possible naming. All of this can be obtained from the official Adminer repository on Github - https://github.com/vrana/adminer/. I have created a complete list of possible naming, taking into account all available languages: https://github.com/kaimi-io/web-fuzz-wordlists/blob/master/adminer.txt. In our module, we will use a shortened version, which, if necessary, can be extended, and we will partially generate this list, instead of hardcoding the contents. But at first we will add some more extra things:

We include modules that contain global variables and implementation of some necessary functions. Next, we get the port, where Nessus has detected a running web server. Now, to draw the rest of the fucking owl the main code:

That's a large code snippet. In general, based on the repository, we have compiled a list of versions, prefixes, and naming suffixes of the paths where Adminer can be located. We use several arrays to store the paths, the versions, and a total count of detections. For a port with a web server, we launch the scanning process using the paths detected earlier. Next, we build an URI and send a regular GET request. Pay attention to the name of the function to send a GET request and recall the passage above about legacy code and the quality of the API. We retrieve the version using the regular expression and put it into arrays. We also set a flag if an old version was found, which is vulnerable to unauthorized server file reading. After checking all the directories, we generate a report, where we specify paths and detected versions. Depending on results we return, that nothing was found (AUDIT_WEB_APP_NOT_AFFECTED), a low level vulnerability (if version >= 4.6.3) or a high level one.
Here are the results of our module run in the web interface:

As I've mentioned before, the module can also be started from the command line as follows:

You can read more about the Nessus command line arguments here.
Finally, after the module is completed and moved to the proper location with other modules, it is necessary to update the plugins database via the web interface or from the console (https://community.tenable.com/s/article/Rebuild-the-Plugin-Database):

First command will disable signature check for Nessus plugins. Everything is finished and ready for use. For those who want to read a more structured description of the module development process, you can look through the book Nessus Network Auditing, pretty old, but gives an idea of the process and the available API description.

Ready-to-use module: adminer_detect.nasl.zip