Using the 'nasl' Nessus Command Line Tool

This blog entry will discuss the usage of the Nessus nasl binary tool. It will also discuss which plugins work well with the tool, how credentials and other information can be supplied at scan time and how the tool can make use of data saved in a prior scan's knowledge base.

The nasl Binary

The nasl tool allows NASL scripts to be invoked, traced and analyzed. This can help in debugging new NASL scripts and analyzing the logic of various plugins. On Linux distributions of Nessus, the nasl binary is located in /opt/nessus/bin/nasl. This is the directory that also contains the nessus client and nessus-fetch tools. Running it without any arguments will offer the usage page and running it with the '-v' option will show you the version information.

Configuring Your System to run the nasl Binary

The nasl binary is installed with each version of Nessus 3. You can run the nasl binary as any user that has access to execute the binary. Some options, such as forging packets, require root access. The nasl binary is also installed with Nessus 2, but does not support execution of .nbin files or dynamic reading from the knowledge base. Also, the nasl binary does not support plugins with the .nes extension. These plugins are written in the C language and implement platform specific logic.

If you will be running the nasl command a lot, you should consider placing /opt/nessus/bin into your executable environment path. This allows you to do work in the /opt/nessus/lib/nessus/plugins directory and not re-type the full path to the nasl binary.

The nasl binary works with  plugins from the Registered and Direct Feeds. If your Nessus 3 scanner is subscribed to the Direct Feed, it will be able to perform configuration, sensitive content and SCADA scans. Instead of invoking the nasl binary with a plugin that has a .nasl extension, some Direct Feed plugins are shipped with .nbin extensions which signifies that their code has been shipped in binary format.

Which Plugins work best?

Of the more than 15,000 Nessus plugins available in the Direct or Registered feeds each can be classified into two types: those dependent on other plugins for input and those that can run stand-alone. The nasl binary can run any NASL script, but if the script expects to work with data produced by another plugin, the specific knowledge base (KB) must be referenced. We will discuss the KB in a moment, but first let's look at some example plugins being invoked by the nasl binary which don't depend on the KB.

All plugins that require credentials such as performing file content checks or reading the registry will be dependent on other plugins for input.   

Example Network Banner Check

We will start off by connecting to port 80 on an older Fedora Apache server:

[root@ghidra plugins]# telnet 192.168.20.8 80
GET / HTTP/1.0

Trying 192.168.20.8...
Connected to 192.168.20.8 (192.168.20.8).
Escape character is '^]'.
HTTP/1.1 200 OK
Date: Sun, 24 Jun 2007 13:16:35 GMT
Server: Apache/2.0.47 (Fedora)

This system is running Apache 2.0.47. Now let's run two of the Apache NASL checks against this host:

[root@ghidra plugins]# /opt/nessus/bin/nasl -t 192.168.20.8 ./apache_2_0_47.nasl
[root@ghidra plugins]# /opt/nessus/bin/nasl -t 192.168.20.8 ./apache_2_0_48.nasl
./apache_2_0_48.nasl: Success

We can see that the apache_2_0_47.nasl script didn't find anything while the apache_2_0_48.nasl did. These checks are a good example of a network check that doesn't require authentication information or access to the KB. Both checks basically connect to the web server, obtain the banner and look for a certain version number.

Some of the more than 15,000 Nessus plugins are very useful is a pure "stand-alone" type of audit. A good example of this is the  ssl_supported_ciphers.nasl plugin which reports a wide variety of information about the encryption available on remote systems. Below is an example run which has had it's output curtailed for this blog entry:

[root@ghidra plugins]# /opt/nessus/bin/nasl -t 192.168.20.8 ./ssl_supported_ciphers.nasl

Synopsis :

The remote service supports the use of weak SSL ciphers.

(Description and solution removed)

Plugin output :

Here is a list of the SSL ciphers supported by the remote server :

(Low Strength and medium Strength Ciphers removed)

  High Strength Ciphers (>= 112-bit key)
    SSLv2
      DES-CBC3-MD5               Kx=RSA        Au=RSA     Enc=3DES(168)    Mac=MD5
      RC2-CBC-MD5                Kx=RSA        Au=RSA     Enc=RC2(128)     Mac=MD5
      RC4-MD5                    Kx=RSA        Au=RSA     Enc=RC4(128)     Mac=MD5
    SSLv3
      EDH-RSA-DES-CBC3-SHA       Kx=DH         Au=RSA     Enc=3DES(168)    Mac=SHA1
      DES-CBC3-SHA               Kx=RSA        Au=RSA     Enc=3DES(168)    Mac=SHA1
      RC4-MD5                    Kx=RSA        Au=RSA     Enc=RC4(128)     Mac=MD5
      RC4-SHA                    Kx=RSA        Au=RSA     Enc=RC4(128)     Mac=SHA1
    TLSv1
      EDH-RSA-DES-CBC3-SHA       Kx=DH         Au=RSA     Enc=3DES(168)    Mac=SHA1
      DHE-RSA-AES128-SHA         Kx=DH         Au=RSA     Enc=AES(128)     Mac=SHA1
      DHE-RSA-AES256-SHA         Kx=DH         Au=RSA     Enc=AES(256)     Mac=SHA1
      DES-CBC3-SHA               Kx=RSA        Au=RSA     Enc=3DES(168)    Mac=SHA1
      AES128-SHA                 Kx=RSA        Au=RSA     Enc=AES(128)     Mac=SHA1
      AES256-SHA                 Kx=RSA        Au=RSA     Enc=AES(256)     Mac=SHA1
      RC4-MD5                    Kx=RSA        Au=RSA     Enc=RC4(128)     Mac=MD5
      RC4-SHA                    Kx=RSA        Au=RSA     Enc=RC4(128)     Mac=SHA1

Of course Nessus can be used to scan a local network to look and report this sort of information, but so can the nasl tool. Instead of supplying a target IP address, a network mask or range can be used such as:

nasl -t 172.20.10.0/24 someScript.nasl

This will run your script on many different hosts and report results accordingly. This can be very useful to test many different types of targets and ensure that your plugin logic is correct.

Example Network and Credentialed Plugin Check

For our next example, we will look at the iTunes 6.0.5 vulnerability. There are two checks for this, a network check and a credentialed check. Running the network check is very straightforward:

[root@ghidra plugins]# /opt/nessus/bin/nasl -t 192.168.20.16 itunes_605_banner.nasl
[root@ghidra plugins]#

There were no results found. Let's try the credentialed version of this check (itunes_605.nasl). This time, let's use the '-T' option of the nasl binary. This option traces each API used and its results to either a file , or use the minus sign for standard output. Here is an example trace:

[root@ghidra plugins]# /opt/nessus/bin/nasl  -t 192.168.20.16 -T - itunes_605.nasl
(TRACE) call #nasl_str2intarray(.91)!....:2*"....;3+#....<4,$?7/'....>6.&....=5-%........ )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(.........................)4.%/7.(3-!0,1'8"5.*2$.  )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(.:2*"....<4,$....>6.&....@80( ...91)!....;3+#....=5-%....?7/'.... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(. ............................................. . )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(..................... ........... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(.(.0.8.@ './.7.?.&...6.>.%.-.5.=.$.,.4.<.#.+.3.;.".*.2.:.!.).1.9. )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(................. )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(........................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(................................................. )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(................................................. )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(......................................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(......................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(......................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(......................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(......................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(......................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(................................................................. )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(................................................................. )
(TRACE) ret -> <array>
(TRACE) call get_kb_item(SMB/Registry/Enumerated )
(TRACE) ret ->
(TRACE) call exit(0 )

The key to understanding this trace is the last call to the get_kb_item() API. This NASL script is expecting to find a user name and password stored in the knowledge base and when it doesn't it exits immediately.

We'll consider working with the KB in a moment, but first let's discuss modifying the actual script to hard-code some credentials. I don't advise hard-coding credentials located in the Nessus plugins directory. Copying the script to a new directory and editing it there will avoid re-using any edited plugins for production scans. If you end up working on live plugins keep in mind that a new plugin update may overwrite your  changes. Also if you create a local copy of a plugin, it will have the same Nessus ID or plugin name as before and this will cause problems if Nessus attempts to use both scripts.

To hard-code credentials into the itunes_605.nasl plugin, you can edit the section of code which queries the KB for scan information such as shown below:

# Connect to the appropriate share.
#if (!get_kb_item("SMB/Registry/Enumerated")) exit(0);

name    =  kb_smb_name();
port    =  kb_smb_transport();
if (!get_port_state(port)) exit(0);
login   =  "Administrator";
pass    =  "password";
domain  =  kb_smb_domain();

Notice that the line invoking the get_kb_item() API has been commented out and that the login and pass variables have been given fixed values. Here is an example run:

[root@ghidra plugins]# /opt/nessus/bin/nasl -t 192.168.20.16 /home/rgula/blog/itunes_605.nasl
[root@ghidra plugins]#

There was no output this time since no vulnerabilities were found. Using the '-T' option to trace this edited program though would provide a much different output than before. I won't list the trace here, but each API invoked for logging into the remote machine, checking for iTunes and then gracefully closing the Windows SMB connection would be itemized.

Working With the Knowledge Base

For plugins which have multiple dependencies, running the nasl binary with the '-k' option can allow it to retrieve data from previous scans. In order to do this, you must perform a scan and have the results, including data learned during the scan, saved to the knowledge base (KB).

The KB is stored in the /kbs directory under the name of the Nessus user which performed the scan. For example, while writing this blog entry, my Nessus scanner didn't have any existing data for the 192.168
network for the 'nessus' user:

[root@ghidra rgula]# ls /opt/nessus/var/nessus/users/nessus/kbs/192/168/*
ls: /opt/nessus/var/nessus/users/nessus/kbs/192/168/*: No such file or directory

To create a KB entry, configure a nessusrc file with credentials for a host to scan and also enable KB support with the "save_knowledge_base = yes" setting.

For this blog entry, I created a nessusrc scan policy that performed a full Windows patch audit, an invoked most Windows local security audits. After performing the scan (which isn't shown), we now have a KB:

[root@ghidra rgula]# ls /opt/nessus/var/nessus/users/nessus/kbs/192/168/*
192.168.20.16

Now that the KB is in place, we can run almost any NASL script and just use the KB to feed information into our plugins.

Here is an example of running the smb_enum_softwares.nasl script which lists all installed software on a Windows host:

[root@ghidra plugins]# /opt/nessus/bin/nasl -k /opt/nessus/var/nessus/users/nessus/kbs/192/168/20/192.168.20.16 -t
192.168.20.16 smb_enum_softwares.nasl

Synopsis :

It is possible to enumerate installed software.

Description :

This plugin lists software installed on the remote host by crawling
the registry entries in :
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Solution :

Remove software that are not compliant with your company policy.

Risk factor :

None

Plugin output :

The following software are installed on the remote host:

Security Update for Windows Server 2003 (KB914388)  [version 1]
Security Update for Windows Server 2003 (KB928090)  [version 1]
(remaining output deleted)

Here is another example of a simple test for Microsoft bulletin MS07-017. This particular test was dependent on another plugin and is basing some of its analysis off of the results in the KB.

[root@ghidra plugins]# /opt/nessus/bin/nasl -k
/opt/nessus/var/nessus/users/nessus/kbs/192/168/20/192.168.20.16 -t
192.168.20.16 smb_nt_ms07-017.nasl
smb_nt_ms07-017.nasl: Success

Our last KB example makes use of the new OS Fingerprinting NASL script. This script is dependent on many other plugins. Invoking it with the KB from our last scan shows how the scan target of 192.168.20.16 was fingerprinted as a Windows 2003 server.

[root@ghidra plugins]# /opt/nessus/bin/nasl -k /opt/nessus/var/nessus/users/nessus/kbs/192/168/20/192.168.20.16 -t 192.168.20.16 os_fingerprint.nasl

Remote operating system : Microsoft Windows Server 2003, Standard Edition (English)
Confidence Level : 100
Method : SMB

The remote host is running Microsoft Windows Server 2003, Standard Edition (English)

Running the same script without the KB offers no results: 

[root@ghidra plugins]# /opt/nessus/bin/nasl -t 192.168.20.16 os_fingerprint.nasl
[root@ghidra plugins]#

Example Compliance Scan

The last example of using the nasl tool considers running the various .audit files from the Nessus Direct Feed. Any of the .nbin files used in the Direct Feed can be executed by the nasl tool and fed credentials and scan policies from the command line.

In the example below, the nasl tool invokes the compliance_check_windows_file_content.nbin plugin, and the user enters the credentials and scan policy to be used.

[root@ghidra plugins]# /opt/nessus/bin/nasl -t 192.168.20.16 ./compliance_check_windows_file_content.nbin

            Windows File Contents Compliance Checks, version 1.0.11

Which file contains your security policy : ./content_credit_card.audit
Login : Administrator
Password : password
Domain :
"Determine if a file contains a valid American Express 15 Digit Card Number" : [FAILED]
- error message:
The following files do not match your policy :
Share: C$, path: \new folder\datatest.xls    (XXXXXXXXXXX1000)
Share: C$, path: \new folder\datatest.pdf    (XXXXXXXXXXX1000)
Share: C$, path: \new folder\datatest.txt    (XXXXXXXXXXX1000)
Share: C$, path: \share\new folder\credit-card-list.txt    (XXXXXXXXXXX1000)

This method also works with the Windows and UNIX configuration audits. This can be very useful for trying different types of .audit files settings, diagnosing custom .audit policies and testing connectivity.

Conclusion

The nasl tool can be used for many different types of Nessus plugin activities including writing new plugins, writing new .audit files and diagnosing Nessus results.

Previously we've blogged about the smbshell.nbin plugin. This is a good example of a  stand-alone application written entirely in NASL and invoked through the nasl tool.