Tenable Network Security has made available a BETA version of the new NessusClient 3.0. This Nessus client can be used to connect to any Nessus scanner and perform scans, manage scan policies and analyze results. It has a consistent user interface across Mac OS X, Windows and Linux operating systems. The BETA currently includes support for:

• instant availability of results during active scans
• managing connections and credentials for multiple Nessus scanners
• managing multiple vulnerability scan policies
• saving the Nessus scanner information, scan polices and results as a unique document-based "session"
• dynamically offering plugin preferences management for scan settings
• new report results format which combines scan policy with results

If you are a current Mac OS X Nessus user, you will recognize that the Nessus Client on Windows and Linux versions is the same as on Mac OS X. Below are screen shots of the new client:

Connecting to a Nessus Scanner	Plugin Selection	Plugin Prefs Selection
Live Scan Results	Content Audit	USB WMI Audit

The New .nessus Report Format

The BETA of the NessusClient 3.0 has the ability to save vulnerability reports in a new format called the ".nessus" output. This is an XML file which contains scan results and scan policies in one report.

Saving scan policies and scan results into one format makes analysis of vulnerabilities more straight forward. Being able to understand what was scanned for, which scan options were used, which credentials were invoked makes understanding of discovered vulnerabilities easier.

This format will also become the preferred format used in future releases of the Security Center for uploading remote vulnerability scan results.

The client also has the ability to export vulnerability results in the older and soon to be depreciated .nsr or .nbe formats.

Windows Support for Dynamic Plugin Preferences

The current Nessus client included with Nessus 3.0.0 through Nessus 3.0.6 had support for a static list of plugin preferences. Previously if Tenable added support for a new plugin, such as the Windows File Content Checks, our developers would need to manually add support for those plugins in the Nessus client.

This new NessusClient 3.0 BETA has dynamic plugin preference support just like the previous Linux Nessus 1.0 GUIs, NessusWX and the OS X Nessus GUI. This means that if in the near future, Tenable releases a new plugin that has some scan configuration options, this new client will be able to present those options to the user to create a custom scan policy.

Platform Availability

The NessusClient 3.0 BETA is available for Linux and Windows.

Mac OS X Nessus users will recognize the user interface and features. Tenable's intent is to provide a consistent user experience across each of these operating system platforms.

Platform Compatibility

Tenable has made an effort to ensure this client is compatible with both Nessus 3 and Nessus 2 scanners obtained from Nessus.org. The client is also compatible with the configuration auditing, sensitive content checks and SCADA checks available through the Tenable Direct Feed.

It should also be noted that there is no operating system dependency between the client and server. You can deploy a Nessus Windows 3.0.6 scanner on a host and connect to it with the this Nessus Client from Linux or OS X. This has been the case for previous Nessus clients as well.

Obtaining and Using This BETA

The NessusClient 3.0 BETA for Windows or Linux is available for download from the nessus.org web site. Any issues found during testing of this BETA should be sent to Tenable's Director of Research, Renaud Deraison, or posted to the http://bugs.nessus.org tracking system.

Tenable Network Security's Research staff recently added the ability to use LanMan/NTLM hashes as a form of credentials for Windows audits. If you use Nessus as a penetration testing tool, this allows you to take the hashes you have obtained with pwdump, lsadump, Cain, .etc, and use them to perform Nessus audits.

Leveraging Hashes and Nessus for Penetration Testing

Below is a screen shot of adding a hash to a Nessus scan policy:

Hashes are long strings of ASCII codes. The hash should be placed in the password field of the Windows credentials scan policy.

If the obtained hash has the correct credentials, you will be able to perform an audit of the Windows host and possibly other hosts on the network that would accept the same credentials. Ideally, the hash should be for the local 'Administrator' account, but depending on the security policies of your Windows system and domain,  you may be able to perform audits and obtain various levels of information with a  non-administrator account.  Keep in mind that Tenable's best practice guide for performing remote audits is to use an Administrator account.

Nessus can audit Windows systems for a wide variety of information that can add value to penetration tests. Some items that credentialed Nessus scans can find on Windows systems include:

• Patch Auditing
• Enumeration of USB drives
• List of installed software
• User account security settings
• Anti-virus status
• DEP status

Also, if your Nessus scanner is subscribed to the Direct Feed, you can perform searches of the target disk drive for sensitive data such as Credit Card Numbers, Social Security Numbers or custom searches that you develop based on what is sensitive for the local environment. Similarly, you can also perform audits of the compromised systems to see if they are hardened against CIS, NSA or NIST policies.

This allows you to not only tell your client that you've been able to penetrate one or more systems, but to also show that the systems had a variety of other vulnerability, configuration and content issues that a malicious hacker or insider could have exploited.

Why Support Hashes?

If you are not familiar with how Windows security authentication works, once a user authenticates, the system will store a hash of these credentials and then make use of these to access resources.

If during a penetration test, these hashes can be obtained from the disk (or even memory) then they can be used with Nessus to perform any type of Windows audit that Nessus offers. Using Nessus's automated scanning, the same hash can be used on multiple Windows systems to audit an entire network.

Also Works with "SMB Shell" too!

This authentication mechanism also works with the SMB Shell script. To invoke it, perform a Nessus scan that leverages an available NTLM hash and also saves the results to the knowledge base. There is a blog entry dedicated to using the nasl binary and KB here, as well as the SMB Shell tool. Below is an example invocation of the SMB Shell script using NTLM hashes.

###########################################

  --==[SMB Shell v0.3 (c) 2007 Tenable Network Security]==--

[*] username: administrator
[*] password:
[*] hash: NTLM:78164FD1E988FE5B39E0474EEE475E51
[*] domain (optional):
[*] Connecting to 172.11.12.184...
[*] Authenticating to 172.11.12.184...

smbshell> shell

[*] Opening share ADMIN$...
[*] Connected to ADMIN$ (172.11.12.172:61700 -> 172.11.12.184:445)
[*] Installing remote command service...
[*] Remote command service installed.
[*] Connecting to remote command service...
[*] Connected to remote command service.

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\WINDOWS\system32>

Availability

The underlying changes to the SMB APIs have been updated in both the Nessus Direct and Registered feeds. After your next plugin update, you will see NTLM hashes available as a new form of Windows authentication. This feature is not available in the Nessus 3 Windows client but is supported in all Nessus 3 scanners.

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.

Tenable Network Security has released version 3.0.6 of the Nessus Vulnerability Scanner which fixes a variety of performance issues and bugs.

It also includes a security fix for a cross site scripting vulnerability in the Windows version of Nessus. We'd like to thank the Japanese CERT organization for notifying us about this security issue.

This latest release of Nessus also includes builds for Fedora 7 as well as Red Hat ES 5. 

Nessus 3.0.6 can be obtained from http://www.nessus.org/download. Also, Direct Feed and Security Center customers can obtain these latest Nessus builds directly from the Tenable Support Portal.

Tenable's research group has released a TASL correlation script for the Log Correlation Engine (LCE) that automatically associates learned user accounts with IP addresses. This enables historical tracking of users in organizations that do not have centralized authentication and access control such as university environments or campus-wide networks.

The script is named "New Network User" (new_nw_usr.tasl). It accepts normalized logs from several dozen different authentication log sources, extracts the user name and originating IP address and then creates a log if the user identity is new, or if an existing "user to IP address" relationship has changed.

Current supported log sources include:

• Windows system and active directory logins
• UNIX SSH logins
• RADIUS Authentications
• Application logs for authenticated email (POP, IMAP, .etc)
• Application logs for a variety of FTP servers
• Passively sniffed gmail, MySpace and other web applications
• Passively sniffed chat and IM login processes

Logs from the Passive Vulnerability Scanner (PVS) which generate user name or identity information are unique in that this information is passively determined. Unlike the other applications supported by this script which send logs of authentication users accessing a domain or checking email, the PVS obtains this information through protocol analysis. We've  previously blogged about this capability in the PVS.

Tracking "New User" Identities

From this TASL script's point of view, a new user is any recognized account that hasn't been previously tracked. For example, the first time a network user connects to their Gmail account, the PVS will recognize this and send a syslog message to the LCE. This TASL scipt will extract the user name from the PVS syslog message and then will generate a new log such as this one shown below:

New Network User - user mrrongula957@gmail.com has logged on from IP address 192.168.56.254

The script looks at many different types of "identities" that can be passively obtained or extracted from log files. A given user might likely have different names and identities for their public email, domain and chat accounts. An identity might be a full email address (such as mrrongula957@gmail.com) or if the log or traffic came from an authenticated email it might be just an account name like 'bsmith'.

Tracking When Users Move Around

As these logs occur, the script builds a table of user accounts and the IP address they have originated from. If this pairing ever changes, a new log is generated which looks like this:

Network user IP address change, user mrrongula957@gmail.com IP address has changed from 192.168.56.254 to 192.168.159.71

Users can get new IP addresses for many different reasons including DHCP lease expirations, moving around a campus network or even obtaining a new computer.

In environments where centralized authentication (like RADIUS or LDAP) or network access control (NAC) isn't implemented, the ability to passively associate user names with the PVS to an IP address can be very useful for incident response and compliance monitoring.

Once these logs are stored in the LCE, trying to find out which users had access to certain IP addresses or networks at any given time is something that can be queried for.

If one wanted to find out which network users originated from IP address 192.168.20.67 on April 10, 2007, they would perform a query for the "New_Network_User" and "Network_User_IP_change" events on such a day.

Below is an obscured screen shot of these logs from a university environment. The main source of the user identities has come from the PVS's ability to track unique Gmail accounts.

This information can also be saved as a spread sheet.

Installing the new Script

Log Correlation Engine customers should download the new_nw_usr.tasl script from the TASL homepage to their /usr/thunder/daemons/plugins directory. They should also download an updated lce_tasl.prm and tenable_pvs.prm libraries to the same directory and then restart the thunderd process.

These following UNIX command lines can be used to obtain and restart the LCE and should be run as user 'thunder'.

cd /usr/thunder/daemons/plugins
rm ./lce_tasl.prm
wget http://www.tenablesecurity.com/lce_tasl.prm
rm ./tenable_pvs.prm
wget http://www.tenablesecurity.com/tenable_pvs.prm
wget http://cgi.tenablesecurity.com/tasl/new_nw_usr.tasl
/etc/rc.d/init.d/thunder restart

Other Types of User Tracking with the LCE

If this sort of user tracking is of interest to you, several other LCE TASL scripts should be considered:

• invalid_user_logon.tasl -- Automatically learns a list of invalid or deleted logins and then alerts if those accounts are used again in the future.
• new_user.tasl -- Automatically tracks all SSH, Windows and other application logins to build up a list of unique valid user accounts for each logged server and alerts when a new user account is used.
• user_to_mac.tasl -- Tracks authentication logs along with DHCP logs to build automatic match es between user names to Ethernet addresses. Generates an alert when a user has a new Ethernet address. Previously blogged about here.

For More Information

To learn more about TASL scripting, please consider the TASL documentation as well as the example TASL scripts. Tenable also offers a free webinar about Network Based Anomaly Detection which uses TASL scripting to process netflow and sniffed network sessions to look for leapfrog attacks, network backdoors and other types of host and crowd behaviors.

Tenable was recently awarded certification to perform  Center For Internet Security (CIS) audits of Red Hat systems with the Nessus 3 scanner and Security Center. This blog entry discusses what the audit files look for, how customers should obtain the audit files and how this impacts PCI audits.

CIS Red Hat ES4 Audit Policy

A new .audit file for both Nessus Direct Feed and the Security Center named redhat_es4_cis.audit, is available on the Tenable Support Portal. This .audit file implements configuration checks and settings recommended in version 1.0.5 of the CIS Red Hat Benchmark.

Audit checks include:

• Correct logging levels
• Secure configuration of SSH
• Banners for FTP, logins and SSH
• Disabling of un-needed services
• Configuration of TCP Wrappers
• Configuration of the cups daemon
• Configuration of Sendmail
• User account configuration
• Locking down the boot processes
• Hardening of kernel network parameters
• Configuration of FTP
• System-wide file and directory permission audits
• Secure X server configuration

Obtaining and Using these Checks

This .audit file can be loaded into the Security Center for enterprise scanning or leveraged as part of a Nessus 3 Direct Feed scan. The policy is downloaded from the Tenable Support Portal. Once logged into the portal, click on the 'Downloads' button, then the 'Download CIS Audit and Compliance Files' button.

Security Center uses should download this policy to the /opt/sc3/admin/nasl directory as owner 'tns'. They will then be available as a Compliance Audit policy for any Vulnerability Scan Policy. Multiple .audit polices can be combined to be performed simultaneously during each scan.

Nessus 3 Direct Feed users should download this policy to their laptop or system where their Nessus client is operating. Nessus 3 clients can reference one or more audit policies for their credentialed scans.

Impact to PCI Assessments

PCI requirements include vulnerability auditing, firewall analysis, log analysis and configuration auditing among many other things. The PCI standard specifically points to CIS as a source for configuration auditing.

For More Information

The following list of links and blog entries are available for readers interested in Tenable solutions and compliance auditing.

• CIS Audits for Windows Domain Controllers with Nessus and the Security Center
• Center for Internet Security -- http://www.cisecurity.org
• Realtime compliance Paper -- Current and potential Tenable customers should request a copy of this paper which details how our unified approach to log analysis, configuration auditing and vulnerability management impacts PCI,  FISMA, SOX, NERC and compliance auditing and montioring.   
• Creating "Gold" Build Audit Policies -- This blog entry details how the Windows Nessus Policy Creator can be used to extract a Nessus configuration auditing policy from a properly configured Windows server.
• NIST Auditing -- Tenable products can also perform NIST configuration audits from the Secure Content Automation Program. This blog entry provides details about the polices available to perform these configuration audits.  The NIST SCAP web site is located at http://nvd.nist.gov/scap/scap.cfm.
• Security and IT Controls -- Gene Kim was interviewed by Richard Steinian about the positive impact that IT Controls (such as configuration management) can have on security and availability of IT resources.

The Passive Vulnerability Scanner's plugin rule base was recently updated with new logic to recognize a variety of client-side account information for services such as AIM, MySpace and many others. This blog entry discusses the new rules and how they can be used for auditing a network.

Current User ID Rules

The following decodes are currently available in the live plugin update feeds for the Passive Vulnerability Scanner:

• 1329 return email addr
• 2341 POP3 User
• 2600 MSN Messenger UserID
• 2609 PGP Sender email
• 3018 HTTP Base64 encoded credentials
• 3954 IDA Pro UserID
• 4082 AOL Instant Messenger user enumeration
• 4098 IMAP UserID enumeration
• 9000 Myspace UserID
• 9001 Facebook UserID
• 9003 Xanga UserID
• 9005 gmail userID
• 9006 XM Radio UserID

These plugins identify a variety of specific user names and accounts that are active on any given host in a monitored network. For example, below is a screen shot of a PVS detect of a Tenable email account as
viewed under the Security Center:

Uses of This Information

If using any of these services is against your corporate policy, then obtaining the actual user name of the account and the IP address from which it originates is very useful. If this data is combined with active data from Nessus scans, such as the NetBIOS or DNS name of the source computer, this can also be useful for identifying which network users are associated with which types of external accounts.

When performing incident response and starting out with nothing more than a list of potentially compromised IP addresses, or IP addresses that are behaving oddly, being able to obtain a list of external resources and user names used on those systems is also useful. Knowing that a potentially compromised system may have been used by certain users can help incident responders prepare for what they might encounter or give clues to access vectors that a system was compromised with.

Lastly, another use of this data is to associate users to IP addresses. Being able to associate an account that "lives" on the network with a specific IP address can also track when a user gets a new IP address. In networks where centralized domain and DHCP logs aren't centralized, this can be a very useful audit trail for tracking when certain users have obtained an IP addresses or a new IP address.

Limitations

There are three limitations to this approach.

First, all email and chat user accounts are logged, regardless if they are associated with your network or not. This means you may see personal user IDs like "kungfun1nga", "rjg1969" and so on. You may also see real user names like "rongula". Mapping these accounts back to real users on your network is not a trivial task, but the data is very useful if you are responding to an incident or tracking the same private user moving around your local network.

Second, if the PVS is deployed outside of a NAT or VPN device, it won't differentiate specific IPs behind that device. For example, if you had 100 students deployed behind a NAT firewall, the PVS will only log the first email address it sees and associate it with the IP address of the NAT device.

And lastly, the PVS can detect encrypted client and server sections, but it does not decrypt them. If your users are checking mail with secure POP, secure IMAP or through a VPN, the PVS will likely be able to identify this sort of client-side activity, but won't be able to discern user names.

Using these on Your Network

A majority of these decodes are already available in the PVS updates. If you've manually synchronized your plugins lately or have your PVS managed by the Security Center, you will have these latest decodes.

Plugins 9000 through 9006 are available as a manual download under the Corporate Policy Plugins. These rules are available in the policy.prm library. If you are running the PVS in standalone mode, download the policy.prm file and place it in your /opt/pvs/var/pvs/plugins on RedHat. If your PVS is being managed by the Security Center, place the policy.prm file in the /opt/sc3/proxy/outbound directory and it will be pushed out automatically.

Disabling This Type of Collection

If gathering these user IDs is against your corporate policy, they can be disabled. On the Unix versions of the PVS, inside the /opt/pvs/etc/pvs.conf configuration file, there is a line (disabled by default) which identifies the file containing a list of plugin IDs to be disabled. The section of the pvs.conf file looks like this:

    #disabled-plugins "/opt/pvs/var/pvs/disabled-plugins.txt";
    plugins-directory "/opt/pvs/var/pvs/plugins";
    fingerprints "/opt/pvs/var/pvs/osfingerprints.txt";

Uncomment the line, create the /opt/pvs/var/pvs/disabled-plugins.txt file and place the IDs you don't want the PVS to use one to each line like this:

1329
2341
2600
2609
3018

The PVS process must be manually restarted for these settings to take effect.

For More Information

If you'd like more information about the Passive Vulnerability Scanner, please consider the following demonstration video and previous blog entries:

• (video) PVS and the Security Center are used to monitor a network of more than 10,000 nodes
• (blog) Proxy and Firewall Detection with the PVS
• (blog) Using the PVS to detect Corporate Policy Violations and Data Leakage
• (blog) Finding Interactive and Encrypted Sessions on your network

Wouldn't it be interesting to know which places you go to on the Internet or in your corporate network that have major vulnerabilities in real-time? How many of those customer portals, web sign-up forms or even the corporate blog web servers are vulnerable to recent or even not-so-recent security issues? You might think about scanning them with Nessus, but performing scans all the time or trying to obtain permission to scan isn't practical. However, there is plenty of information contained in raw network traffic that can be used to discover many different types of vulnerabilities.

This is the basis for the Passive Vulnerability Scanner (PVS) product from Tenable. In this blog entry, we will discuss how the PVS can be turned "outside" to gain knowledge of vulnerabilties throughout the Internet just by interacting them with everyday protocols.

Looking for Vulnerable Web Sites

Normally, when the PVS is deployed on an enterprise network it is told to focus "inwards" on vulnerabilities for specific addresses such as 10.10.0.0/16 or 192.168.10.0/24. However, one of the of the ways we test the PVS here at Tenable is to simply surf the web, send email, chat, use P2P CLIENTS and so on and let the PVS watch our traffic.

What we found interesting is that many common Internet sites had vulnerabilities that could be discovered just through traffic analysis. We're not talking about web application vulnerabilities, we're talking about older web servers, older versions of PHP and even unpatched 3rd party applications.

I call this "Vulnerability Tourism" because it can really show which sites are locked down and which sites have issues. It can even identify the underlying technology used at almost any site and show which sites are more "complex" than others.

What is the Passive Vulnerability Scanner?

Several years ago, Tenable released a product named "NeVO" that stood for the "Network Vulnerability Observer". It was renamed to the Passive Vulnerability Scanner (PVS) in early 2006. The PVS sniffs network traffic and produces vulnerability reports that rival what you can obtain from a credentialed Nessus scan. Nessus has advantages over the PVS when it comes to performing detailed and interactive tests as well as configuration audits, but the PVS has an advantage of silently watching your network 24x7.

Turning the PVS Inside Out

A very interesting exercise with the PVS is to set it wide open, and then start surfing the Internet or Intranet, sending mail to your contacts, chatting with folks on IM and so on. PVS has the ability to stream "new" pieces of vulnerability or network information via SYSLOG

So as you visit places like common news, search, and e-commerce web sites, send mail to your contacts, FTP product updates from your vendor or interact with anyone on just about any Internet protocol, you can see in real-time what the PVS has discovered in the network traffic.

Typical Results

By no means did we do an audit of the entire Internet; however, after surfing to many different news, search, merchandise, entertainment and other types of sites and using the PVS to analyze the traffic, several trends can easily be seen. We also visited a variety of "security" and "technology" company web sites and viewed their customer support login screens as well as various forms to request white papers and product demos. We didn't post specific results here because often the content on these web sites was copy-written, and we also didn't read each of these site's acceptable use policies.

The following general trends were very easy to observe:

• Many of the advertising servers that render marketing campaigns, click through images and other types of commercials seem to run with older versions of Apache and PHP. For example, visiting major newspaper and TV stations web sites "looked" like they were very vulnerable, but in fact it was the web servers hosting dynamic marketing content that seemed to be insecure.
• Doing Google searches for e-commerce sites claiming to be PCI certified showed basic vulnerabilities in many of the web portals, especially to newer vulnerabilities. It could be argued that this makes sense because PCI audits are only required quarterly and a site might not scan that often. I'd like to think that sites which accept credit card information would patch things like PHP quicker than what we saw.
• There is usually a disparity in security levels or technology between a hosted web site and something interactive such as a support portal, ticketing system or white-paper request form. Very often we'd visit a web site and the PVS would discover the web server of the site, but when submitting a web form, a different server would be used that was missing security patches.

Identifying Underlying Technology and Complexity

Even when no vulnerabilties are found, the PVS is looking at the network traffic to the visited sites and attempting to enumerate web servers, mail servers, the open ports and even guess the operating system. This may also yield some surprising results such as a few IIS web servers in a sea of Apache systems, or some Linux devices at a place you'd expect to be 100% Microsoft.

Another thing we ran into was that some sites are very, very complex. Visiting a simple news site could cause content to be loaded from more than 10 unique web servers. This is likely a form of load balancing, but when evaluating these unique web server types, they usually were not all of the same application. We also saw this occasionally at some smaller technology vendor sites where the blog, the main web server, the white paper request form and the e-commerce site were all different systems and different technologies. In today's environment where different functions can be outsourced, this may be understandable. However, when these systems all have similar IP addresses and are on the same network, it may be overly complex.

Enterprise Monitoring

If finding Internet vulnerabilities simply through watching "normal" network traffic seems interesting to you, then consider what can be discovered when all traffic within an enterprise network can be analyzed. The Security Center can manage multiple Passive Vulnerability Scanners the same way it manages multiple Nessus scanners.

All information from the PVS is available for reporting, consumption via spread sheets, alerting, etc. by any Security Center users. Information from the PVS can also be used to identify new assets, sort them into various asset groups and even schedule active or credentialed scans of newly found hosts with Nessus.

The PVS can also search your network traffic for evidence of documents and data in motion that contain sensitive data such as credit card numbers. It can also point out which servers host "office" files such as PDFs, Spread Sheets and Word documents.

For More Information

Qualified customers who wish to evaluate the Passive Vulnerability Scanner or wish to evaluate Nessus or the Security Center should contact our sales staff.

Multiple demonstration videos are available online.

To learn more about Tenable's strategy to use active scanning, credentialed scanning and passive network monitoring, please consider reading the Blended Security Assessments white paper. The paper outlines both the advantages and disadvantages of active and passive scanning and how using both in a blended manner is more accurate than just using one technique.

Today, Tenable released Nessus 3.1.4 beta. Here are the main changes compared to Nessus 3.1.3 :

• 64 bit OS builds for Debian 4 and Red Hat ES 5
• Fedora Core 7 build
• Improved support for IPv6. In particular, the functions get_local_mac_addr() and get_gw_mac_addr() work when dealing with an IPv6 host
• Fixed a bug related to the maximum number of TCP sessions set in parallel, which would cause nessusd to use more CPU than what is necessary
• Added several fixes in the NASL interpreter. In some cases, a copy-on-write operation would not be detected properly thus leading to incorrect modifications of some variables
• Fixed a bug in nessuscmd which would not be able to use the local nessusd daemon
• The nessus command-line utility can now produce the same report type (.nessus) as the Mac OS X client
• Several other smaller bug fixes as well as further optimizations to reduce memory usage.

The Nessus 3.1.x series is considered as being in beta. When it reaches production quality, it will be labeled Nessus 3.2.x. The main list of changes between Nessus 3.2 and Nessus 3.0 is available in these previous posts:

• Nessus 3.2 BETA - IPv6 Scanning
• Nessus 3.2 BETA - Example WMI Usage
• Nessus 3.2 BETA - Available for testing

Nessus 3.1.4 can be obtained from the nessus.org web site.