Nessus and custom plugins
The best way to learn something is to teach it to someone else, so as I write this first sentence, my knowledge of NASL (let’s Google that (Nessus Attack Scripting Language)) is limited to basically what it’s used for. I suppose a brief explanation of Nessus is also warranted before I dive into one of the many cornerstones of the application.
Nessus is a computer security vulnerability scanner, which is capable of generating reports on:
- Discovery – What ports are open? What banners are returned by services such as HTTP or SSH? While not necessarily attack vectors within themselves, all but the most autonomous attacks require some sort information gathering in order to steer the course of (in this case) the penetration test
- Configuration auditing – Checking the environment for states which are likely the result of insecure configurations. Looking at the marketing material, it appears Nessus can recommend on configuration hardening for services and network devices. I’d like to see this from a technical perspective – my guess is that local configuration files can be searched and then scanned for insecure configuration settings, using the local checks available to Nessus (SSH or similar access required)
- Asset profiling – Files containing keywords can be flagged by Nessus during transit over networks (and maybe prevented leaving the network?). This appears to be a feature of Tenable’s Passive Vulnerability Scanner, but merits mention because I thought it was cool, albeit being practically useless if encryption is being used
- Sensitive content auditing – The Nessus vulnerability scanner can be used to search for Social Security Numbers and credit card information, again, something I think the PVS would have a say in, especially over networks
- Patch auditing – Subdivided into integration and coverage, Nessus seems to be able to check the patching levels of machines and report on discrepancies
- Compliance auditing – Lot’s of three, four, and five letter words are mentioned on their compliance page, apparently Nessus can search for ‘specific policy settings’
Okay enough fluff, let’s get down to the grit – NASL.
The NASL2 documentation is available here and from reading much less than half of it, I can see that:
- If you want to define variables in functions, you should really use local_var <variable_name>, because you might overwrite a global variable of the same name if you don’t!
- The booleans (TRUE and FALSE) are just variables which can be overwritten (FALSE = 1 and TRUE = 0 anyone?)
- The guy who wrote the documentation was probably not a native English speaker. Good show old chap, at least you can speak another language..
Writing a plugin written in NASL
First things first, I’m not up for making this plugin ‘official’ so I need to disable plugin signing checks. To do this you need to edit your /opt/nessus/etc/nessus/nessusd.conf file. Although plugin signing should only be disabled if your custom plugin requests objects which are considered of elevated privilege, I’m just going to be safe. Search for:
nasl_no_signature_check = no
And make sure it’s set to:
nasl_no_signature_check = yes
At this point I dived into /opt/nessus/lib/nessus/plugins and opened up the apache_server_info.nasl plugin source file to see roughly what was going on. NASL is a lot like C in many respects, so the syntax didn’t look too alien to me. I tried changing the synopsis attribute, and then figured it would be worthwhile knowing how to perform a plugin reload, as caching the plugins would make sense (at the time of writing, the plugin directory had 59799 files in it). To reload the Nessus plugins, run:
You can shave some time off here by issuing:
/opt/nessus/sbin/nessusd -t # (this only reloads plugins whose timestamps have changed since the last reload (this call causes nessusd to hang for me in Kali))
Once this is done you need to restart Nessus:
For this particular plugin, you need to be looking under ‘Web Servers’ -> ‘Apache mod_info /server-info Information Disclosure’ (page 6 for me).
Let’s create a new plugin which checks for /awstats/ (if you don’t specify the trailing slash the scan may not work! I found the 301 on /awstats in my access.log) – it looks like this will be fairly simple considering all that needs to change is a couple of strings. The code for this customised plugin can have found here.
This post just scratches the surface of the capability of NASL and integrating custom plugins with Nessus, but it’s a start. I won’t be covering any more detailed work surrounding NASL, but you might see some custom plugins for it at some point if I happen to find some 0day.. That would be nice wouldn’t it.