Nessus is one of those tools that is both wonderful and, at times, wonderfully frustrating.
I recently ran into a situation where I wanted to run a Nessus vulnerability test against a service running on a non-standard port. Quite a few of Nessus’ bundled plugins use hard-coded ports. Rather than just copying the plugin and making a second version with the custom port number, I thought that it would be fun to build a Preferences screen for the plugin. This would allow me to scan for the service on multiple different ports using a scan Policy per port.
It turned out to not be too difficult, but required reading the NASL documentation as well as looking at some existing plugins with port settings. Hopefully this write-up will save you some time doing this on your own.
First, Nessus needs to be configured to allow unsigned plugins. On Backtrack, you will have to edit /opt/nessus/etc/nessus/nessusd.conf , and change the line that starts “nasl_no_signature_check = “. Set it to ‘yes’.
Then, make a copy of the plugin that you want to customize. Nessus plugins are stored in /opt/nessus/lib/nessus/plugins/ . I just call it <originalName>2.nasl. In my example, I am customizing a copy of the Oracle Glassfish TRACE method authentication bypass plugin. So I make a copy and call it “glassfish_trace_auth_bypass2.nasl”.
Now it is time to edit the new plugin. This new plugin needs a unique ID. I start my custom plugins to begin with id number 99001 and count up. I have seen various tutorials (even ones from Tenable) suggesting the use of plugin IDs in the 50000-60000 range, however these IDs are now being used by Tenable’s signed plugins. So go high. Change the script_id() call to use whatever number you come up with. It is wise to change the script_name() and script_summary() calls to reflect that this is a modified plugin, and so that you can more easily find it in Nessus.
Next, you want to deal with the hard-coded port itself. In the Glassfish TRACE plugin, the port is hard-coded to the value 4848. The first use of the port is at a line:
This line tells Nessus that it should perform an action to verify that the (hard-coded) Glassfish port is actually a web server. Just before this line, I add two items:
script_add_preference(name: “Glassfish port :”, type: “entry”, value: “4848”);
tcpport = script_get_preference(“Glassfish port :”);
This tells Nessus to make a Preferences page for the TRACE auth bypass plugin, and to give it a single preference entry. The user will be able to edit the field, and it will have a default value of 4848. The second line will populate the variable tcpport with the setting from the first line’s preference entry. Now I modify the hard-coded port, changing it from 4848 to tcpport:
The TCP port used by the standard Glassfish test is hard-coded in two locations. Both need to be changed. One down, one to go. The next place that it is hard-coded is just a few lines down:
port = get_http_port(default:4848);
This line is responsible for opening a connection to the web server. Change it to be:
port = get_http_port(default:tcpport);
This part of the file should look like so:
Now you have to rebuild the plugins and make Nessus load the new one up. First, you have to stop Nessus from the command line.
sh# /etc/init.d/nessusd stop
Now you have to rebuild Nessus’ plugin index.
sh# /opt/nessus/sbin/nessusd -R
This part is painfully slow, and is a great time to chair joust. When it finishes, start the Nessus server back up:
sh# /etc/init.d/nessusd start
Now, under the Preferences pane, your plugin will have a preference.
This modification has some limitations. Obviously if there is a future vulnerability in Glassfish, it won’t be detected — the new plugin won’t look to your preference for the old plugin. Still, this modification can be very useful if you are a paranoid system administrator who wants to keep an eye on some server settings for which the plugin exists today, or you are performing a security assessment and want to have a .nessus file to give to your client showing a vulnerable service.
Image by cote