Using the 'nasl' Nessus Command Line Tool

<a href="http://blog.tenablesecurity.com/2007/06/using-the-nasl-.html">http://blog.tenablesecurity.com/2007/06/using-the-nasl-.html</a>

<a href="http://www.virtualblueness.net/nasl.html">http://www.virtualblueness.net/nasl.html</a>

<a href="http://michel.arboi.free.fr/nasl2ref/">http://michel.arboi.free.fr/nasl2ref/</a>

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, thenasl binary is located in

/opt/nessus/bin/nasl. This is the directory that also contains thenessus 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 thenasl binary as any user that has access to execute the binary. Some options, such as forging packets, require root access. Thenasl 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 thenasl binary.

.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. Thenasl 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

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

Of course Nessus can be used to scan a local network to look and report this sort of information, but so can thenasl 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]#

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+#....&lt;4,$?7/'....&gt;6.&amp;....=5-%........ )

(TRACE) ret -&gt; &lt;array&gt;

(TRACE) call #nasl_str2intarray(.........................)4.%/7.(3-!0,1'8"5.*2$.  )

(TRACE) call #nasl_str2intarray(.:2*"....&lt;4,$....&gt;6.&amp;....@80( ...91)!....;3+#....=5-%....?7/'.... )

(TRACE) call #nasl_str2intarray(. ............................................. . )

(TRACE) call #nasl_str2intarray(..................... ........... )

(TRACE) call #nasl_str2intarray(.(.0.8.@ './.7.?.&amp;...6.&gt;.%.-.5.=.$.,.4.&lt;.#.+.3.;.".*.2.:.!.).1.9. )

(TRACE) call #nasl_str2intarray(................. )

(TRACE) call #nasl_str2intarray(........................................... )

(TRACE) call #nasl_str2intarray(................................................. )

(TRACE) call #nasl_str2intarray(......................................................... )

(TRACE) call #nasl_str2intarray(......................................... )

(TRACE) call #nasl_str2intarray(................................................................. )

(TRACE) call get_kb_item(SMB/Registry/Enumerated )

(TRACE) ret -&gt;

(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

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:

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.

[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)

[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

[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

Example Compliance Scan

The last example of using the nasl tool considers running the various.audit files from the Nessus

.nbin files used in the Direct Feed can be executed by thenasl 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.