A challenge for many penetration testers is to find a vulnerable system they can use to test their penetration testing skills and tools before they use them against paying clients. I recently found a distribution called "Hackerdemia", a Slax-based Linux distribution containing several vulnerabilities, including un-patched software, mis-configured services, default passwords and a few other surprises. My goal was to bring up the distribution in a virtual machine, assign it an IP address using host-only mode and scan it using Nessus.

(Note: This Blog was originally released in 2007 and was updated in March of 2009 to reflect an additional form of OS detection based on HTTP banners.)

Tenable's Research group recently introduced a highly accurate form of operating system identification. This new method combines input from various other plugins that perform separate techniques to guess or identify a remote operating system. This blog entry describes this new process and shows some example results .

Why a new process?

Two reasons.

First, although we feel that TCP/IP fingerprinting to guess a remote network stack is useful, there are too many variables and limitations involved to be considered 100% reliable. TCP/IP fingerprinting techniques send specially crafted packets which trigger a different reaction from one OS to another. These different reactions are used to identify if the host is Windows, Linux, Cisco IOS and so on. Many variables on the network and on the host can influence how a stack behaves and cause unmatched or inaccurate guesses as to what exactly the remote OS actually is. And even when TCP/IP stack fingerprinting works 100%, it often can only guess the remote kernel, but not the specific Linux, Windows or other types of distributions. 

Second, many Nessus users perform full credentialed scans and in-depth analysis of various applications.  While logged into a UNIX or Windows system, or performing certain types of application queries, it is trivial to accurately determine the remote operating system. This information was previously reported, but contained in the results of many separate plugins. This type of information is extremely accurate compared to TCP/IP fingerprinting techniques. For example, Mac OS X systems can be accurately identified through their network time protocol (ntp) daemon without credentials. Running commands like "uname" on UNIX or looking up certain registry settings for Windows can yield highly accurate results.

This new process elegantly combines the best of each of these approaches, plus adds many new techniques which contribute to Nessus's guess of what a remote operating system really is.

How the new process works

Plugin #11936 (OS Identification) is still the main ID Nessus users should use to perform OS enumeration of their scanned systems. Prior to the recent change, this NASL script performed TCP/IP fingerprinting of OS stacks and also targeted a few Windows and Mac OS X protocols to increase the accuracy of the reported OS. The new process now takes input from the following other NASL scripts, which each reports their own OS guessing:

• os_fingerprint_ftp.nasl Uses the remote FTP banner to attempt to identify the underlying operating system. (Note, this functionality was added in Feb 2009)
• os_fingerprint_html.nasl Uses the HTML content returned by certain HTTP requests to fingerprint the remote OS. (note, this functionality was add in Feb 2009)
• os_fingerprint_http.nasl Uses the remote web server signature to infer the version of Windows or the Linux distribution running on the remote host.
• os_fingerprint_mdns.nasl If an mDNS server is present, will perform a highly accurate identification of Apple OS X systems.
• os_fingerprint_msrprc.nasl Identifies the remote version and service pack of Windows by making certain MSRPC requests against the remote Windows box.
• os_fingerprint_ntp.nasl Queries the Network Time Protocol daemon to perform a highly accurate OS guess.
• os_fingerprint_sinfp.nasl Implements the SinFP TCP/IP fingerprinting algorithm. Only requires one open port to fingerprint an OS.  (Note this script does not work on Nessus 2.)
• os_fingerprint_smb.nasl Identifies the remote Windows OS based on a query to SMB.
• os_fingerprint_snmp.nasl If credentials are available to perform an SNMP query, data from the 'sysDesc' parameter is reported.
• os_fingerprint_ssh.nasl Attempts to identify the remote OS by the SSH banner.
• os_fingerprint_telnet.nasl Attempts to identify the remote OS by the Telnet banner.
• os_fingerprint_uname.nasl If SSH credentials of the remote UNIX hosts is provided, the results of 'uname -a' are obtained.
• os_fingerprint_linux_distro.nasl If SSH credentials of the remote Linux host is provided, the  specific release will be obtained.
• os_fingerprint_xprobe.nasl This script attempts to identify the OS type and version by sending more or less incorrect ICMP requests using the techniques outlined in Ofir Arkin's paper 'ICMP Usage In Scanning'.

More OS fingerprinting modules will  be added in the future.

Each of these plugins will report a confidence level for their scan results. For example, "real" OS detects through direct interaction with the operating system such as SNMP probes, running the 'uname' command or performing certain types of Windows registry queries all have a 100% confidence level. Other types of queries such as performing TCP or ICMP fingerprints, or trying to fingerprint an application, have been labeled with a value less than 100%.  The result with the highest confidence level is used to guess the remote operating system.

Nessus users should either enable dependencies while scanning (which is the default value) or manually select which of these new plugins (available in the "General" plugin family)  they wish to be launched. 

New Fingerprints

Several of the plugins will report 'unknown' fingerprints for devices that do not have an existing match. Please email these signatures to os-signatures@nessus.org to be incorporated into future plugin updates.

All Nessus users benefit from these plugin submissions. The more fingerprints that are submitted, the more accurate future Nessus scans will be.

Evasion

No discussion of accurate remote OS identification is complete without understanding how this process can be evaded.

Several years ago, it was considered that TCP/IP stack fingerprinting was the most reliable method of OS identification because application banners could be easily modified. It is fairly trivial to make an Apache web server look like it is an IIS web server or place an Exchange email banner on your Postfix mail server.

Today though, with the presence of technologies like /proc on Linux, sysctl on FreeBSD or the registry on Windows, modifying how your network stack behaves is also very easy.

The bottom line is that if someone wants to be fingerprinted like a different type of operating system, they can configure their system like this. By using many different application and fingerprint methods, and then weighting the results, Nessus will always be able to report something that can be used for auditing.

Example Scan Output

Here is some example text OS IDs from a Nessus 3 scan that included credentials for some systems:

The remote host is running Linux Kernel 2.4
Confidence Level : 70
Method : SinFP

The remote host is running Linux Kernel 2.6.9-5.EL
Confidence Level : 100
Method : uname

The remote host is running Microsoft Windows Server 2003, Enterprise Edition (English)
Confidence Level : 100
Method : SMB

The remote host is running Microsoft Windows XP Service Pack 2
Confidence Level : 99
Method : MSRPC

The remote host is running Linux Kernel 2.6
Confidence Level : 60
Method : ICMP

The remote host is running Mac OS X 10.4.9 (intel)
Confidence Level : 100
Method : NTP

Notice that many of these "confidence levels are 100%. This is because the UNIX check used the 'uname' command and the Windows host had port 445 open. Both of these checks are 100% accurate and there is no room for interpretation.

Plugin Availability and Updates

This new type of detection is available to all Nessus users who have updated their plugins recently with either the Professional or Home Feeds. Security Center users also benefit from the accuracy of these updated methods. The ability to accurately classify an OS is vital for automatic asset discovery and classification.

Tenable Network Security has released a virtual appliance for the Nessus 3 vulnerability scanner. The VMWare appliance is available to ProfessionalFeed and Security Center customers.

The appliance image allows for rapid deployments and effortless management of Nessus 3 scanners in virtual environments. Users do not need to concern themselves with managing an operating system and can focus on managing their scanner configurations, operation and performance.

When installing the image for the first time, a console based user interface displays the IP addresses obtained by a DHCP lease as shown below:

A web based user interface can then be used to configure your Nessus scanner, provision users for use with the Nessus Client or Security Center, subscribe it to the ProfessionalFeed, view appliance logs, save/restore appliance configurations and much more. Below is a screen shot of the main configuration interface:

Downloads for this appliance image, along with documentation, are available on the Tenable Support Portal to existing ProfessionalFeed and Security Center customers. An unlimited number of virtual Nessus appliances can be provisioned for use with the Security Center. Stand-alone images require a ProfessionalFeed subscription to receive the latest Nessus plugins.

Earlier this year, Michel Arboi wrote a blog post explaining how to use Nessus to call Nikto and incorporate the results into Nessus output. Most newcomers to Nessus have enabled the nikto.nasl wrapper only to find it produced no output. Some Nessus users have found various ways to ensure Nikto was called correctly and the output displayed. Others chose to run Nikto separately for various reasons. The following guide will explain how to easily configure Nessus to properly call Nikto. This will allow you to save considerable time, especially on scans against a large amount of systems.

Background

Nikto is a small and fast Open Source (GPL) web scanner written by Sullo, based on RFP's LibWhisker. The scanner performs comprehensive tests against web servers for multiple items, including over 3500 potentially dangerous files/CGIs, versions on over 900 servers and version specific problems on over 250 servers.

Configuration

The nikto.nasl plugin can call Nikto directly from Nessus to help automate assessment work. Nessus 3 has been updated to support the release of Nikto 2.03, the current version as of September, 2008. A default installation of Nessus will not automatically call and execute Nikto. During the installation of Nessus, you must make a few configuration changes to the environment so that Nikto is run automatically:

* First, the Nessus daemon must be run on Unix. The nikto.nasl script will not run on Nessus for Windows.
* Download the current version of Nikto. Uncompress and untar the distribution, and move the entire directory to /opt (or another directory of your choice, but subsequent configuration options must be consistent in the use of this directory).
* Note: Nessus does not look for any command name other than "nikto.pl" (as distributed). If Nikto is installed by any distribution-tuned packages that renames this file or uses a wrapper, nikto.nasl will not find it.
* When nessusd is run (i.e. when the plugins are compiled and the daemon started), nikto.pl must be found in the $PATH of the shell that executes nessus (i.e. adding it to root's $PATH may be insufficient). This can be done by editing /etc/profile (or whatever system profile is invoked by shells) and adding /opt/nikto-2.03 to the path.
* The NASL script that calles Nikto is nikto.nasl (Plugin ID 14260, titled "Nikto (NASL wrapper)", in the "CGI Abuses" family) and can be found under /opt/nessus/lib/nessus/plugins.
* From a command shell, run "nikto.pl" from any directory other than /opt/nikto-2.03 to ensure it is in the $PATH and runs correctly.
* Rerun nessusd -R to re-process the plugins, and restart the nessusd daemon gracefully using the init script and "restart" option. (if this does not work, kill the nessusd process and run "nessusd -D")
* If you or your OS distribution create a symlink in a directory such as /usr/local/bin, ensure that /opt/nikto-2.03 is in the $PATH declaration before the directory with the symlink. If not, nessusd will see the first occurrence of nikto.pl and attempt to execute it. In doing so, Nikto will not find the configuration or data files required to properly run. If your Nessus scans attempt to execute Nikto but produce no output, this may be one cause. Either remove the symlink or adjust the $PATH setting.
* Finally, nikto.nasl is disabled by default in the scan policy. To change this under NessusClient3 for example, edit the policy and click on the 'Advanced' tab. In the drop down menu, select "Nikto (NASL wrapper)" and change "Enable Nikto" from 'no' to 'yes'.

Your next Nessus scan should successfully execute Nikto and provide the results in the report.

Common Problems

* If the Nikto wrapper is not seen in the plugin list, it is likely that nikto.pl was not found when the plugins were compiled. Make sure /opt/nikto-2.03 is in $PATH, run "nessusd -R" to recompile the plugins and restart nessusd.
* If the Nikto wrapper is seen, but Nikto does not run (i.e. no output is displayed in the report), it is possible that nessusd did not find nikto.pl when the plugin was launched. If nessusd is started automatically by an init shell script, this script should be edited to add /opt/nikto-2.03 to the $PATH.

Command Summary

To summarize the installation, your configuration sequence should look similar to the following. Lines beginning with # are comments.

# configuration start
cd /opt
# get the Nikto package
wget http://cirt.net/nikto/nikto-current.tar.gz
# uncompress and untar, creating the nikto-2.03 directory
tar xvz nikto-current.tar.gz
# make sure that /opt/nikto-2.03/nikto.pl exists and is executable by running it and verifying it displays usage information
/opt/nikto-2.03/nikto.pl
# ensure the $PATH knows where to find Nikto. to help ensure this works, also edit your system profile to add this path
PATH=/opt/nikto-2.03:$PATH
export PATH
# ensure nikto.nasl is present
ls -l /opt/nessus/lib/nessus/plugins/nikto.nasl
# re-process the plugins
/opt/nessus/sbin/nessusd -R
# restart nessusd gracefully. if this doesn't work, try "killall nessusd; nessusd -D"
/etc/init.d/nessusd restart

The Nikto NASL plugin automatically selects some options such as using SSL support or virtual host name (supported by HTTP/1.1 only). The plugin will not execute Nikto against web servers that do not return a 404 error code on non-existent pages to avoid Nikto output showing thousands of false positives.

Nessus plugin #33523 "Network Camera Detection" will alert if it encounters a web page that belongs to a WebCam.

Typically, these web pages are not password protected and on ports other than port 80. If it is not password protected and not behind a firewall, it may be allowing unauthorized users from your organization, or even users from the Internet to view and/or listen to activity and conversations in the viewing area of the cameras.

Below is an example screen shot of this plugin being active during a Nessus scan.

The plugin does not require credentials, but is dependent on having its scan target the web server port if it is running on something non-standard, such as 8000.

The plugin is currently available to Direct Feed users.

Tenable recently announced two programs to provide access to the ProfessionalFeed for charitable organizations and classrooms that offer information security training. Full details of the programs are listed below:

• Tenable Information Security Training Organization Subscription Programs
• Tenable Charitable Organization ProfessionalFeed Program

Charities in the United States must be a 501(c)(3) organization to qualify. Charity organizations not based in the United States must provide equivalent documentation to substantiate their standing as a charitable organization.

Academic and commercial classrooms should also be aware that the HomeFeed license for Nessus will include language to permit distribution of Nessus within a classroom environment. If you are looking to teach the basics of port scanning, vulnerability scanning and patch auditing, the HomeFeed for Nessus will allow you to accomplish this.

If you want to instruct in more advanced Nessus concepts such as auditing system configurations, searching for sensitive content and other features specific to the ProfessionalFeed, training organizations can apply to receive one subscription for their class. The plugins and activation codes can not be distributed to the students, and they should instead perform any labs, testing or exercises by interacting with the Nessus scanner directly.

If you have interest in these programs, please consider the above links which have more detailed information. Further questions should be directed to either infosectrainingPF@tenablesecurity.com for Nessus use in classrooms or charitablePF@tenablesecurity.com for charitable organizations. 

Tenable Network Security has released version 3.2.1 of the Nessus vulnerability scanner. This point release includes a variety of small bug fixes as well as a new report filtering interface for the Nessus client. This blog entry will discuss the new Nessus features, bug fixes and reporting filters for the Nessus Client.

Nessus Release Notes

New features

• New multi-criteria report filter in NessusClient. There is more on this later in the blog.
• On Mac OS X, it is now possible to authenticate with NessusClient to a remote Nessus server via a SSL certificate
• New NASL functions - bn_dec2raw(), bn_raw2dec(), bn_hex2raw(), bn_raw2hex(), rsa_public_encrypt(), rsa_private_encrypt() and rsa_private_decrypt()
• New options in nessusd.conf : 'enable_listen_ipv4' and 'enable_listen_ipv6' let the user disable IPv4 and IPv6 bindings
• Builds for Ubuntu Linux 8.04 and Fedora 9
• Support for Windows 2000

Bug fixes in this release

'nessus' command-line client :

• report entries longer than 16Kb would be truncated
• When exporting a report to the .nessus format, some report entries could sometimes be truncated
• When exporting a report to the .nessus format, backslashes would not be properly escaped

Nessus server :

• Fixed a concurrency issue when too many threads write to the plugin database
• On Solaris, SIGCHLD signals would not always be properly handled, thus leaving zombie processes
• Fixed a segmentation fault in nasl occurring on 64 bits systems

Nessus client :

• When searching for plugins, the filtering interface now works as expected

Plugins :

• ssl_ciphers.nes has been removed in favor of the new ssl_ciphers.nasl
• Fixed a segmentation fault in nessus_tcp_scanner.nes

Packaging :

• The %uninstall section of the RPMs contained a bug which would force users doing an upgrade to call 'chkconfig nessusd on' manually. Due to the nature of this bug, be sure to call 'chkconfig nessusd on' when upgrading from 3.x.y to 3.2.1
• The Debian 4 i386 build was incorrectly registering itself as x86-64, thus breaking 'nessus-update' on Debian 4 i386

Report Filtering

In the below screen shot, under version 3.2.1 of the Nessus Client on OS X, when viewing a report a new "Filter..." option is now available.

Clicking on the "Filter..." button will present the user with a dialog box that can be used to create a simple or complex filter statement. This box is shown below:

This box allows the Nessus user to create a set of rules where any or all of the following conditions are met:

• Plugin ID
• Plugin Name
• Port Name
• Host Name Starts With
• Host Name Contains
• Report Contains
• Plugin Severity

All fields use a text box to enter desired strings or numbers except for the severity level which lets the user choose a list of low, medium or high.

By default, all options set with "any" so you could choose port names of http, https and smtp to give all web and email server vulnerabilities. If the "all" option is chosen, then only vulnerabilities matching the entire criteria will be listed. Keep in mind that if you choose two filters that create exclusive sets such as a port rule to match "http" and a second rule to match a port name of "smtp" you will most likely not have any matching results.

Once a desired filter statement is set, only the matching systems with the matching vulnerabilities are displayed. Also, only the matching vulnerabilities on those systems are displayed as well.

Filters that are in effect also control what type of data is sent to the .html, .nsr or .nbe file formats. This allows you to select what type of data goes into your .html web reports or that gets exported.

To reset the filter, simply choose the "Filter..." button again and reset the filter.

Nessus has several new features for auditing systems via Secure Shell and coincidentally, there was a major vulnerability announced this week regarding OpenSSH servers whose public keys are trivially guessable. This blog entry discusses these new features and SSH audits.

Full "su" and "sudo" Support

All Nessus users now have the ability to perform their credentialed patch and vulnerability auditing with the support of "su" or "sudo". Previously, Nessus users were limited to simply specifying a username for the Unix audit to occur with that had limited support for sudo.

Available as a new scan preference option, Nessus users can now specify credentials to log into a remote system, and then additionally invoke "su" or "sudo" with a separate password.

In addition, if an ssh known_hosts file is available and provided as part of the scan policy, Nessus will only attempt to log into hosts in this file. This can ensure that the same username and password you are using to audit your known SSH servers isn't used to attempt a login to a system that may not be under your control.

Below is a screenshot of the Nessus Client SSH credentials page.

When auditing UNIX systems via su or sudo, please keep the following items in mind:

• If your UNIX system has been tightened down to limit what sort of commands can be executed or files accessed by remote users, this may affect your audit. You should compare non-root audits with a root audit if you suspect the audit is being limited due to excessive security.
• When scanning with known_hosts, the Nessus scan still needs to specify a host to be scanned as well. For example, if you scanned a class C but uploaded a known_hosts file that only contained 20 individual hosts within that class C, Nessus would just scan those hosts in the file.
• Currently, su and sudo support is not available to perform UNIX configuration audits, but this will be available shortly.

Testing for Weak SSH Keys in Linux Distributions

For Debian and Ubuntu Linux distributions, any SSH, SSL or other cryptographic keys generated through OpenSSL since 2006 were not sufficiently randomized. This resulted in all Debian and Ubuntu systems using one of 32768 unique keys. This means that any type of SSH or SSL security which relied on encryption keys is now easily guessable by a remote attacker.

Although most of the coverage of this issue has been dedicated to SSH servers which have been secured with public/private keys, this issue also impacts SSL encrypted web servers, users of the the OpenVPN client and all applications using encryption that generated keys with OpenSSL. Links to the original vendor vulnerabilties are below:

• http://lists.debian.org/debian-security-announce/2008/msg00152.html
• https://lists.ubuntu.com/archives/ubuntu-security-announce/2008-May/000705.html

Nessus plugin #32314 "Debian OpenSSH/OpenSSL Package Random Number Generator Weakness", audits Debian and Ubuntu systems without credentials (you can scan without a password) to find systems that have an easily guessable key.

Although the focus of this vulnerability has been on SSH, all cryptographic material on these systems maybe suspect including SSL. This implies secure web servers running on Debian or Ubuntu may also be at risk. Nessus plugin #32321, "Debian OpenSSH/OpenSSL Package Random Number Generator Weakness (SSL check)", performs this check on SSL web servers without requiring credentials.

These two previous new plugins are server focused. To test for client side weak encryption with this same bug, Nessus plugin #32320, "Remote host has weak Debian OpenSSH Keys in ~/.ssh/authorized_keys" is now available as well. This plugin requires credentials (and you can use su/sudo as well now), and analyzes every user's authorized_keys file to ensure that it does not contain any weak SSH key.

Each of these new SSH audits are available to Nessus Direct Feed subscribers and Security Center customers. 

Tenable Network Security Inc. today announced an update to its Nessus subscription model that will benefit home users and qualifying charities around the world. We've posted a letter and a FAQ about the changes at nessus.org.

I was also recently interviewed about the license change for the Network Security Podcast by Rich Mogull and Martin Mckeay. The direct url for the interview is:

• http://netsecpodcast.com/?p=41

Very often, Nessus is used by MSPs, consultants and IT security staff to test the security of an Internet facing server. Occasionally, we see the default settings of Nessus, which are optimized for a credentialed internal LAN audit, used to audit an external server. Although this usually results in a majority of the vulnerabilties being identified, Nessus can be configured to work a bit harder for these types of scans. This blog entry details some different strategies and scan settings that can be used to perform a more complete audit of an Internet facing server.

Nessus Scanner Settings

When scanning a few external hosts, we do not envision the scanning process to impact your system's performance. However, if you do encounter issues, consider the following. The scan settings we will be enabling will cause Nessus to work much harder than it does during a typical LAN or default scan. If the system running Nessus is not a dedicated system (such as a consultant's laptop), you should consider configuring it to have less impact on the underlying operating system. Otherwise, the system may become unresponsive during the audit. On UNIX, the "be_nice" setting should be set to "yes" in the nessusd.conf file and then the nessusd process restarted. On Windows, the nessusd.exe process can have its priority lowered. For this blog entry, I had several heavier scans running at the same time from my local Nessus scanner and had no noticeable impact to my operating system.

If the audit is taking place over a slow Internet connection or a connection which is being served by a device that may be impacted by many simultaneous connections, considering reducing the "max_hosts" setting from the default of 40 to 10. This will generate less overall traffic during any given moment of an audit and also reduce the number of simultaneous checks (and connections). On the Nessus Client, this setting is available under the "Options" tab and is named "Number of Checks in Parallel".

Scan Policy Settings

Global Variable Settings

Many plugins implement more thorough audits when the "Thorough Tests (slow)" setting is enabled. These tests often implement the same logic, but try more combinations of potential security issues. This causes security audits to run longer than they normally do. For example, when looking for FTP, SMB or HTTP servers hosting potentially copy written content, this setting increases the level of  recursion used to look for files. There is a slight chance of impacting a server's performance during this audit, as the server will also have to respond to more probes than during a normal scan.

Also in this section, the "Network Type" should be set to "Public WAN (Internet)". This effects some plugins which are required to choose relevant IP addresses.

Below is a screen shot of the Nessus Client implementing these settings:

Service Detection

By default, SSL detection is normally performed on services that are expected to support encryption such as port 443. However, for any discovered port facing the Internet, SSL service detection should be enabled. This is accomplished by changing the "Service Detection" set of options under the "Advanced" tab from the default setting of "Known SSL Ports" to "All".

If the audit is being performed remotely, this section also has a separate setting for the number of service fingerprints to be performed in parallel. This setting effects the few plugins which perform service fingerprinting and can generate many sessions at the same time. The default value for this is 10 and for the policy used in our example policy, I reduced this by half to 5.

Below is a screen shot of the Nessus Client implementing these settings:

Auditing CGIs

Nessus includes a plugin that can "torture" any discovered CGI or other type of interactive web document. This can uncover a wide variety of security, stability and other issues with poorly written login pages, feedback forms and other types of dynamic pages that process user content.

To enable this, under the "Advanced" tab, select the "Unknown CGIs arguments torture" and enable the "Send POSTs requests" check box.

During the audit, if a complex web site is being tested, you should discuss this type of test with the site owners ahead of time. Nessus will try a wide variety of common form exploits which can result in unexpected behavior or unanticipated system loads. Even if a web site is secure, these tests may show issues with logging failure messages (or lack thereof) and could also highlight issues with custom logging in general.

I've spoken with one customer that tried this sort of auditing and they did not have any security issues, but the error logging process involved writing to a SQL database. This surge in errors resulted in an unacceptable denial of service for the web site.

Port Scanning

Since this is an Internet facing system, no port should be left untested. A full port scan from 1 through 65535 is suggested. If you are omitting port scans for some reason, it should be noted in the final audit.

Web Mirroring

The default Nessus settings to look for web pages that may have vulnerabilities can be made more aggressive. These settings take longer to execute than a default scan, but are more likely to find a vulnerable server. The "Web Mirroring" set of scan options is available under the "Advanced" tab of the Nessus Client. The following settings are recommended:

• The default number of web pages to mirror is 200. This should be raised to something that matches the destination site being audited.
• If Nessus learns of a dynamic web page, it normally won't add this to the mirror list, unless the "Follow Dynamic Pages" option is set. Web sites that link to login screens, include feedback forms and have other types of dynamic content are often dynamically generated.

If an audited CGI or other type of dynamically generated web page is poorly written, the Nessus audit may cause a spike in the performance level of the audited server. For example, a web site may have a slow method to read content from a SQL database before rendering a login page or some type of default screen. A rapid set of web queries performed by Nessus could impact the system.

Below is a screen shot implementing  these settings with the Nessus Client:

Performing the Scan

Nessus 3.2 does include the ability to pause a scan. If your audit causes some unanticipated effect on the target servers, you should stop it or pause it immediately.

Tenable receives many reports from customers scanning their remote systems and having ports that were available during the start of a scan, not be available at the end of a scan. This shows up in a Nessus report like this:

System: 192.168.20.200 unknown (0/tcp)
Vulnerability: [10919] Check open ports
Severity: Informational

The following ports were open at the beginning of the scan but are now closed:

Port 80 was detected as being open but is now closed

This might be an availability problem related which might be due to the following reasons :

- The remote host is now down, either because a user turned it off during the scan
- A network outage has been experienced during the scan, and the remote 
network cannot be reached from the Vulnerability Scanner any more
- This Vulnerability Scanner has been blacklisted by the system administrator
or by automatic intrusion detection/prevention systems which have detected the 
vulnerability assessment.

In any case, the audit of the remote host might be incomplete and may need to
be done again

If an Intrusion Prevention System (IPS) or Unified Threat Manager (UTM) devices is configured between you and the target host, it may detect some of your activity after the scan has started and then block further testing. This can cause an incomplete audit. In these situations, it's important not to speculate. Finding out how the IPS is detecting the scan is important because it is also part of the system being audited. For example, if it is only configured to block hosts that perform a port scan, it may not stop a host or worm trying one SQL injection attack. The point is to provide an accurate assessment so the customer or management does not put their faith in something that might not be reflective of other threats.

For More Information

We have blogged several times in the past about configuring Nessus for optimum scanning:

• Auditing Anti-Virus Products with Nessus
• Improper network Segment Testing with Nessus
• Limiting the ports Probed by Nessus scans
• Understanding the Nessus "Safe Checks" Options
• Using Nessus to scan a Host Behind a firewall

Ten years ago today, I announced the initial public release of Nessus on the bugtraq mailing list. The initial version would run only on Linux and was bundled with 50 plugins (vulnerability checks) written in C. At that time I was 18 and I had no idea I would still work on it years later (or that anyone would actually use it). A lot of great things happened during these years, and  I would like to comment on the ten things which really shaped Nessus into what it is today.

1999 : The existing plugins were all switched from C to NASL.

In early 1999, I had done some work on a small engine called pkt_forge, which was meant to be a packet forgery tool (Net::RawIP did not exist at that time, so forging packets meant a lot of C/compiling/debugging/recompiling cycles). It quickly turned into a small language engine which was working well enough to do packet forgery, sockets operations and string matching, so I decided to use that to write new plugins, instead of sticking to C.

Even though in hindsight the initial NASL engine was fairly buggy, leaked memory and sometimes had issues parsing very valid constructs, this helped the plugin writing effort a lot. At that time, the code of each plugin was at most 10 lines long, so performance did not matter (or so I thought), and plugin development advanced at a really good pace -- with that generation of the engine, we wrote up to one thousand plugins. One of the cool thing with using a scripting language is that you know that a lot of common bugs (overflows, format strings, etc...) can not occur, thus leading to a more secure and more reliable environment.

I was very often asked why I did not choose perl, tcl or any other existing engine as a language. My answer is that, as a developer, I believe that it's very important to keep control of the underlying environment. If the core of your product is relying on a third party engine, then that part is going to get in your way sooner or later -- you will inevitably treat it as a black box. I wanted to have the language and its behavior evolve with my needs, and the NASL code base was very simple initially, so it was easy to port, easy to compile and low on memory requirements. 

1999: Service recognition was added in the engine

Service recognition was added so that if you had a FTP server running on port 2121, or two web servers, they would be recognized properly and tested accordingly. As far as I recall, no other scanner was doing this at the time. I wrote a plugin called find_service.nes, which would send a HTTP GET request to every open port and based on the banner or the error message would differentiate the different services. Due to architectural reasons, this plugin was the last one to get written in C and was very recently deprecated with the release of Nessus 3.2.

This plugin quickly grew complex, and was very later completed by many others, either doing generic probes (find_service2.nasl sends 'HELP' on every open port), or doing very specific services recognition (all the plugins finishing with *_detect.nasl, mostly).

A few years later, a user contacted us telling us that one of his network printer printed several pages with only the word "HELP" on each, thus causing some concerns in his office. In order to save trees and the sanity of everyone, we now recognize printers and do not scan them by default ;

2000: Windows Auditing was added.

However, instead of fully implementing the SMB protocol (and DCERPC), I coded things very gradually, as needed -- initially, I just wanted a plugin to determine if the administrator account had a password set, and that's it. Once it was done, I wanted another plugin to see if we could access C$. Then another one which would connect to IPC$. Then see if we can access the registry as guest (pre-SP3 Windows NT). Etc, etc....

While Samba and Wireshark (Ethereal at the time) had done a lot of good work on the SMB side, very little DCERPC calls had been implemented, so my reverse engineering process was to have three windows systems talk to each other (one client talking two servers with different hostnames), and see what has changed in the packets sent. That helped me to produce Windows plugins very quickly, but it involved sending a lot of blobs with a few variables in them, and ended up creating smb_nt.inc which served its purpose well for a time, but became impossible to maintain. More on that later when I talk about smb_func.inc ;

2001: Support for SSL and Network Computing Award

Once OpenSSL stabilized its API, we added support for SSL in Nessus, which once again not every scanner was able to do at the time. That was Michel Arboi's first contribution to Nessus engine.

The beauty of the implementation is that it required nearly zero change on the plugin side -- basically, Nessus "knows" when a port is speaking SSL, and a plugin opening a connection to that port will automatically use SSL. That's one of the benefits of controlling the underlying language -- you can redefine how function calls work.

That year, we were also blessed to "win" a vulnerability scanners shoot out done by Network Computing (and later on won the Well Connected Award for that category). That was the first time a major publication would compare Nessus to other commercial offerings, and this article gave us great exposure whose effects were immediately noticeable.

2002 - 2003: NASL2

When we hit the mark of one thousand plugins, the plugins started to become complex, and the NASL1 engine was showing a lot of its limits and the code had gone so complex that fixing one bug meant adding another one, so the NASL2 project was started and Michel took the lead on it.

The goal there was not to get it to be faster, but to be more reliable, easier to maintain, and to have a "real" parser which would process the plugins. One of the biggest challenges there was to make it behave the same as NASL1, so we would not have to rewrite all these plugins. We were pretty successful at doing that, but due to fundamental differences between the NASL1 and NASL2 parsers, we had to maintain two plugin sets for a while -- one for Nessus 1.x and one for the upcoming Nessus 2.x. The fear was not so much that a 2.x plugin would not work with Nessus 1.x (what's a plugin out of a thousand?), but rather than a 2.x plugin would break 1.x entirely (which, unfortunately, was easy to do). Since the 2.x dev cycle was fairly long, we maintained the two trees for several months, and quickly dropped support for 1.x when we released 2.0.x. After that, we decided that we would never maintain two plugin trees again, and would find ways to mark a plugin to be incompatible with older versions of Nessus ;

2003 : Tenable Network Security, Inc.

In 2003, Tenable Network Security Inc, was founded and I moved from Paris, France to Columbia, MD. Ron Gula, Jack Huffard and myself created Tenable Network Security, Inc. This allowed me to work on Nessus full time without having to worry about mundane problems such as the ability to pay for my rent. Having a full commercial structure not only let us hire good people, but also allowed us to get better feedback from corporate customers and better understand their needs.

2004 : SSH Support

SSH support was added thanks to a contribution from Nicolas Pouvesle, who then joined Tenable as a research engineer. This let us log into remote hosts and perform local patches checks. This quickly increased the number of plugins since one flaw can now have up to ten plugins written for it (one local check for each distribution and a remote check). We never really bragged about the number of plugins in Nessus, but if we did this would have been a nice artificial way to make sure nobody came close :)

Every now and then, some users complain about these plugins because if you take, say, a Red Hat 4 system with a hand-compiled version of bind, then Nessus will not check it and won't warn you if it's not up-to-date. Leaving the technical details aside, what I would eventually want to do is to have a plugin which makes sure that every daemon listening on a given port is actually provided by the OS vendor. The reason is that if you start to manually compile each critical service, then you are putting yourself in a position where upgrading your operating system is going to be very difficult, you're dropping the support provided by the OS vendor, and in the long run, your system will be impossible to maintain (especially by a third party). Our approach is that you should always use the packages provided by your OS vendor, who is making sure that each new version is still working as it should (in theory at least :) and which will be automatically upgraded to their newest version once you upgrade the OS. The less custom modification you do on a system, the easier to is to maintain over time ;

2004 : Commercial Plugin Feed.

In late 2004 we decided to sell subscriptions which would give faster access to the plugins updates, as well as access to additional plugins and commercial support.  The response has been great, and it also helped us to improve the overall quality of our work -- on the backend, this meant a much stricter QA cycle for each new plugin.

2005 : New SMB API.

As I said earlier, we used to rely on smb_nt.inc to communicate with Windows. While it worked great, it was hard to maintain and it was lacking some functionality, such as support for SMB signing. So we re-did the entire SMB API, this time with the intent to have a full, clean SMB and DCE/RPC stack which would be easier to maintain and to modify in the future. This was a complete rewrite, which was a long process involving a lot of testing, and we worked very hard on this. This new API is really clean, and really easy to maintain. Case in point: we could very easily modify it to add SMBv2 support to it (this is still in QA, but we'll make it public soon). However, the best thing about this API is that when we published it in the plugin feed, and modified every plugin using smb_nt.inc, nobody noticed the change, which meant that it did not break anything.

In engineering, sometimes the most rewarding feedback from your users is a total lack of it :)

2006 : Nessus 3.0 (and close-sourcing Nessus).

In January 2006, we released Nessus 3, which I'm really thrilled with. We redid the NASL engine again -- we kept the NASL2 parser, but implemented a "real" VM with its own bytecode, which really improved things. We also changed the way process management is done. In Nessus 2, each plugin was running in its own process (so if you tested 10 hosts in parallel, with 4 plugins per host, you would have 10 x 4 + 10 = 50 processes running). In Nessus 3, we implement plugin-threading ourselves, while just keeping one process per host (so if you scan 10 hosts, you now have 10 processes running). The benefits of Nessus 3 vs Nessus 2 have already been covered many times, so I won't reiterate them here. My only regret is that we advertised Nessus 3 as "twice as fast" as Nessus 2, whereas in a lot of cases it's more like 5 or even 10 times as fast, especially now with the number of plugins we have. Nessus 3 also gave us the opportunity to not only support Linux, but also Microsoft Windows and later on Mac OS X. I actually did the Mac OS X GUI myself, which gave me the opportunity to learn a new language (Objective-C) and reconciled me with object oriented programming.

From a purely technical perspective, one of the surprising benefits of close-sourcing has been the increase of the code quality. My initial fear was that we would not be able to get useful bug reports from end-users due to their inability to use gdb or to load core dumps. So we spent a lot of cycles to write better diagnostic tools which would make our life much easier when users report a problem. This, combined with the fact that there is a limited set of Nessus binaries really helped to improve the code quality. Case in point : we quickly found a bug present since Nessus 2.2.0 that we had been chasing for a long time (an off by one memory overwrite which odds of occurring were 1 in 65535). I believe it was fix during the Nessus 3.0.0 or 3.0.1 cycle (and the fix was backported to the 2.x branch, obviously).

This kind of diagnostic/debugging is obviously not specific to being closed-source, but the point is that by considering that as developers we won't be able to rely on the users to provide us with meaningful information about a crash, we had to write code which makes it easier to understand the worst cases.

Today

We recently released Nessus 3.2.0, which is by far one of the most stable .0 release we've ever done.  I am still very involved with the development but I code fewer plugins than I used to -- every now  and then I will write a new plugin, as I believe that it's very important that the persons involved with the engine keep in touch with what the engine is for, but my great research team now does most of the work and is brilliant at doing that.

Over these ten years, I have been blessed to work and interact with many brilliant people -- ranging from great contributors such as Michel Arboi, Nicolas Pouvesle or George Theall, to nice, patient, and constructive end-users and product testing editors who gave us various awards over the years. Working on Nessus has been fun every day for the last 10 years and I would like to thank everyone who contributed directly or indirectly to its success. As always, I enjoy interacting with every user, so never hesitate to contact me at deraison@nessus.org.

Renaud Deraison.

Historically, active vulnerability scanning of network printers and older Novell NetWare servers could be problematic. Sometimes a simple port scan with any type of auditing tool would cause a network printer to print paper, crash or interrupt real print jobs. Similarly, older Novell NetWare installs were also subject to crashing when having their servers fingerprinted.

Based on the feedback from the Nessus user community, Tenable implemented two scan options for Nessus that can limit how network audits interact with these technologies. These scan options are labeled:

• Scan Network Printers
• Scan Novell NetWare hosts

A screen shot of these scan options as found under the Nessus Client  is shown below:

By default, Nessus won't scan these devices if they are found. When a printer is found, the fact that it won't be scanned is reported. This can cause some confusion for new Nessus users that are running a scan of just a few plugins on a large network. Even though they haven't specifically enabled the plugins to avoid printers and NetWare servers, if one is found it will be reported.

This occurred with one Nessus user I was working with. He was scanning a class B network for just one Nessus plugin, but kept getting plugin #12241 showing up in his results, even though he was not scanning for it and there were no plugin dependency issues. When the user enabled these settings, he no longer got the report that he may have been scanning a printer.

The trade-off of not scanning these types of devices and perhaps limiting the scope of a scan can be a difficult call to make for a new Nessus user of the first time a target network is audited. My recommendation is to first scan with these options enabled so that you can identify potential targets that could be impacted with a full scan. Later on if you are scanning for services or plugins that are likely to not interact with NetWare or network printers, you can make a more educated decision of when to turn these options on or off.

For completely passive and real time network monitoring, the Passive Vulnerabiltiy Scanner has the ability to identify a wide range of vulnerabilities purely from montioring traffic in real time. This solution can solve a variety of political problems, such as end of year IT freezes, where different business users or organizations do not want to submit themselves to active scans.

We've also blogged before about how to limit the scope of Nessus scans:

• Limiting the ports probed by Nessus
• Understanding the Nessus "safe checks" option
• Using Nessus to scan hosts behind a firewall

Nessus plugin #31422 named "Reverse NAT/Intercepting Proxy Detection" enables Nessus users to scan remote IP addresses and determine if they are forwarding multiple ports to different internal systems. This is sometimes also known as an Intercepting Proxy Server.

For example, if a user has configured a firewall or router to send SSH traffic to a hardened FreeBSD server, while sending RDP traffic to a Windows 2003 server, a remote Nessus scanner would be able to identify this.

The plugin can accomplish this sort of audit by comparing the OS fingerprinting results for each targeted port. If they are different enough, the plugin concludes that there is a reverse NAT involved. When using this plugin, use a port scan range which will hit ports that are being forwarded. Also keep in mind if there are multiple reverse NAT rules all going to the same host (i.e., a firewall that has forwarded both port 22 and port 443 to a Linux server), there won't be enough difference in the fingerprints of the ports to detect the reverse NAT.

Below are screen shots of performing this sort of audit with the Nessus scanner and Security Center:

The plugin is currently available to both the registered and Direct Feeds and is a member of the Firewalls Nessus plugin family.

Why is this sort of Audit Important

If offering services such as this is against your corporate policy, then being able to find a reverse NAT with this technique can help you enforce such a policy. This could mean that a user has bought and installed a cheap firewall or wireless access point.

When auditing a smaller company that may not have a DMZ, being able to identify ports being forwarded this way might be identifying target machines in the middle of he office LAN. Smaller organizations that have not invested in a layered infrastructure could be using reverse NATing to offer services such as RDP, HTTPS, and Windows file sharing directly to a server on the local network.

Knowing which services are offered behind a firewall or router allows for better understanding of the network and the impact of the discovered vulnerabilities.

For More Information

A key part to making this sort of technology work is how Nessus performs its operating system fingerprinting. Specifically, the os_fingerprint_sinfp.nasl script implements the SinFP operating system finger printing  on a per-port basis. Tenable and the SinFP project share operating system fingerprints.

If you are passively monitoring your network, Tenable's Passive Vulnerability Scanner also uses a different technique to find NAT devices in general.

And lastly, we've blogged before in general about using Nessus to perform audits of hosts located behind a firewall.

Tenable Network Security is proud to announce the availability of Nessus 3.2.0, as well as NessusClient 3.2.0. Nessus 3.2.0 is a major release, containing several changes from Nessus 3.0.x :

New Features

• Support for IPv6 targets (for the Linux, FreeBSD, Solaris and Mac OS X flavors)
• Support for limiting the number of active TCP sessions in parallel  (per host, per scan, per scanner)
• A new nessuscmd tool that lets one run quick scans from the command-line
• A new nessus-update tool that lets one update the Nessus engine from the command-line (on select platforms)
• The Nessus daemon can now detect hosts which are being turned off during the scan and stop scanning them
• The Nessus daemon can now detect when the network is congested and change the TCP settings appropriately
• Nessus user account access control rules are now more granular and can be used to prevent the scanner from connecting to certain ports or to use certain plugins
• The nessus command-line tool can read and write to and from a .nessus file
• Improved WMI support (see http://cgi.tenablesecurity.com/tenable/WMI.html)

Improvements

• New nasl functions can dynamically alter the plugin selection
• Improved memory management by NASL scripts
• Support for more SSH ciphers (AES-128/AES-192/AES-256/3DES)
• Improved service detection -- a new service detection plugin (find_service.nasl) replaces the old find_service.nes
• On Unix systems, the initial plugin processing now takes advantage of multi-core CPUs
• nessusd.rules now let you tune which plugins are forbidden for a scan, and which ports can or can't be connected to

Improvements to the Nessus TCP Scanner

• Simplified preferences -- a new cursor option (firewall detection) lets the user better tune the scanner when running against a firewall or a slow link
• Improved RTT estimation and congestion detection by regularly probing unfiltered ports

Windows Specific changes

• NessusGUI.exe has been removed in favor of NessusClient.exe which is now bundled with the installer
• It is now possible to authenticate the clients via SSL certificates
• KB saving and other options common to the UNIX version of Nessus are supported on the Windows platform
• Installer now lets the user decide which components to install (server, client or both)
• When the scanner is registered with either a Direct or Registered feed, it will automatically fetch and process the new updates from nessus.org every 24 hours

Mac OS X Specific changes

• Nessus Client 3.2 includes a fixed a memory leak that occurred in the 3.0 version
• Nessus 3.2.0 now is a real universal binary

Linux platforms

Nessus 3.2 is now  available for the following Linux platforms :

• Debian 4 (i386 and amd64)
• Fedora 7 (i386)
• Fedora 8 (i386)
• Red Hat Enterprise Linux 3, 4 and 5 (i386)
• Red Hat Enterprise Linux 5 (x86_64)
• SuSE Linux 9.3 and 10.0 (i386)

NessusClient 3.2.0 specific changes

• A new 'network' tab when editing a policy, lets the user control some Nessus 3.2 specific options  such as maximum TCP sessions.
• Fixed several bugs which might cause the client to crash in the middle of a scan.
• Opening a large .nessus file in the client now takes less time.

For more Information

Nessus 3.2.0 can be obtained at http://www.nessus.org/

Feedback and bug reports can be sent to http://bugs.nessus.org/

Demo videos of Nessus 3.2, including an 12 minute introduction video for new users, are available online.

Nessus documentation is available here:  http://www.tenablesecurity.com/documentation/

This blog entry marks the 200th post for this blog. I've been very pleased with the content we've created for our Nessus users and customers. The feedback I've received is that the content here is useful to information security practitioners from all walks of life.

Tenable recently released Nessus plugin #30000. This means that there are roughly 20,000 plugins (although some have been retired) in the current archive. Raw counts of vulnerability tests are very deceiving, however we feel very strongly that crossing this plugin ID count is a milestone worth noting.

We try to be very open about which checks are available by providing a public RSS feed of new plugins, dynamically listing the unique count of CVE and Bugtraq IDs addressed and by allowing the public to search our plugins database. We've also provided detailed advanced notice of changes to the plugins database such as when we moved our severity scoring algorithms from CVSSv1 to CVSSv2. We have also provided an in-depth statistical analysis of the types of plugins available.

The Nessus Client 3.0 introduced a new format for Nessus scan policies, targets and results. This is known as the ".nessus" format. This blog entry discusses the advantages of this new file type and includes links to recently published technical documentation about the format and layout of the file.

Unified Scan Targets, Policy and Results

Historically, Nessus daemons and clients supported various file formats for scan configurations as well as scan results. When Tenable designed the new file format, we wanted to unify these into one file. This allows for rapid and accurate reproduction of a previous scan as well as understanding what a scan was looking for to begin with.

For example, if you only enabled FTP checks and performed a scan, you should expect to get information about FTP security issues and not SSH or Internet Explorer issues. You also shouldn't conclude that there aren't any SSH or Internet Explorer issues because your FTP scan didn't find any, but this is exactly what a variety of NAC and SIM vendors do. We're hoping that the unified .nessus format will make working with the scan results easier.

Multiple Scan Policies

Multiple scan policies can be specified within one .nessus file. This can help identify different scan settings for different portions of a network. It can also make it very easy to publish "standard" scan settings for your consultants, auditors and IT administrators.

For example, Tenable recently released a SANS Top 20 2007 policy which included individual policies for each unique area of concern identified by SANS. I've spoken with several Tenable customers and Nessus users that are using  .nessus policy files to standardize on remote scans of external networks and to scan servers and applications before they go into production.

Credential Management

The Nessus Client also won't save credentials for a scan policy unless a user specifically checks the 'Save credentials in clear text' option. This is a feature which was added in version 3.0.1 of the Nessus Client.  If you wish to share polices among multiple users which include credentials to audit systems, you must enable this option. Otherwise, the Nessus client won't store the credentials in the .nessus file.

Integration with the Security Center

Customers who use the new Nessus Client 3.0 along with the Security Center can upload their results centrally. Security Center 3.4 (scheduled for release early this quarter) has the ability for any user to upload their Nessus scan results. This allows for remediation tracking, secure sharing of scan results, automatic asset discovery, report creation, vulnerability/IDS event correlation and many other features. It also makes it convenient for corporations to centralize scan results from networks which may be physically separated.

Technical Reference

Tenable has produced a technical reference for programmers who wish to develop tools to parse and analyze Nessus results. This document describes each section of the .nessus document format.

Publishing Scan Policies

If you wish to author and publish your own Nessus scan polices, consider following these guidelines :

• Do not publish credentials in your policies unless you specifically need them.
• Name each sub-policy something informational and that can be grasped by a new user easily.
• Include a description for each policy.
• Minimize your policy such that it is purposeful. For example, if you don't need a certain family, disable it.
• When placing your policies online for other Nessus users, consider compressing them with both ZIP and GZIP so that Nessus users on different platforms can easily obtain them.

Tenable's research group has released several hundred new plugins for Nessus in the last few days. One of them in particular is very useful for Solaris environments.

Plugin #29217 enumerates all installed software packages on Solaris operating systems. It leverages SSH credentialed scanning to obtain these results.

This plugin joins similar plugins for Windows and Unix that leverage a variety of credential types, even including software enumeration via SNMP for Windows if you have such a network.

Previously we have blogged about how enterprise software discovery can be performed with Nessus network scans, credentials scans and continuous passive network analysis with the Passive Vulnerability Scanner.

A key point of these blogs is to be able to use products like the Security Center to automatically classify your systems into unique asset groups based on the software installed on them. For example, the Security Center can use the output from this Solaris plugin to classify Solaris systems that do or don't have a certain Tivoli agent installed on them. This allows complex enterprise networks to be simplified so the process of patch auditing, configuration auditing and event/log analysis can be performed much easier.

Plugin #29217 is currently available to Nessus Direct Feed and Security Center users.

As part of the more than 17,000 plugins available in the Nessus Direct and Registered plugin feeds, many of these look for common user name and password combinations. They will attempt to find administrator accounts without passwords, simple passwords and vendor defaults. Although these checks aren't performing an exhaustive brute force password audit, they may cause enough login failures to "lock out" operational accounts.

Tenable's research group recently introduced logic into the body of the Nessus plugin checks to prevent guessing of accounts. If auditors are running Nessus in a sensitive environment, they can now easily disable the types of plugins which could result in login failures on Windows and Unix systems.

This blog entry discusses account "lock outs", how the new plugin changes work, and what sort of security vulnerabilities might not be checked with this setting enabled.

Understanding Account Lock Outs

As part of hardening a system, users should choose strong passwords that are complex enough to avoid brute force guess attempts. In some cases though, an organization may feel the need to further secure a system by limiting the number of times an account can be accessed unsuccessfully. This can limit the ability for a hacker or insider to try many combinations of user names and passwords to gain access to a system.

A problem that can occur with this type of security is that scanning for a common list of default backdoors, vendor accounts or simple passwords can render the account locked. A locked account could require a certain amount of time before it can be accessed again or it could require some other types of administrator action to "unlock" it.

In an operational environment, we'd like to avoid any type of impact to the availability of the systems that are being scanned. For example, having a Windows 2003 server with its administrator account locked out could prevent a help desk from performing their job. In sensitive environments, some organizations require every login failure to be investigated.

Auditing Password Policy With the Direct Feed and Security Center

Nessus Direct Feed and Security Center users can audit remote UNIX and Windows systems for poor password policies in seconds. Rather than testing 100s, 1000s or even more different username and password combinations, a remote operating system can be audited to see if its password policy is complex enough.

For example, password policies can specify a minimum password length and how often it should be changed. These variables are obtained performing direct queries against the operating system and have no side effects. Testing against a policy is more efficient than testing against a list of 1000s or more of known potential passwords. These audit policy tests require remote credentials to audit the systems.

These types of checks are included in many of the audit policies Tenable has produced to meet NIST SCAP, PCI and Center for Internet Security standards.

Performing Tests With This Setting

Under the current set of plugins being distributed as of November 1st, 2007, there is a new plugin preference variable. Its name is 'Do not log in with user accounts not specified in the policy'.

To access this under the Nessus Client, create a new policy and view the option under the 'Global variable settings' drop down option under the 'Advanced' tab as shown below:

If this setting is checked, then Nessus will not attempt to log into a remote host with anything other than the accounts specified in the Credentials section of the scan policy.

If you have not updated your plugins since November 1st, this setting will not be available. These checks have been made available to both the Direct Feed and Registered Feed customers. Also, if you are using the new Nessus Client, you must create a new policy for this item to be available in the user interface.

Knowing When to Use This Setting

The focus of this plugin change is to prevent unintentional use of plugins that attempt a login vis SMB for Windows systems or SSH for UNIX systems.

There are several "vulnerability" plugins which look for common user name and password combinations. For example, attempting to see if a Windows 2003 server has a blank administrator password is a great security check, but the act of measuring it may cause a login failure.

If you have manually installed Hydra on your Nessus scanner and you also select those plugins for execution, Hydra will run unaffected by this setting. 

For More Information

Information about the Direct Feed is available here. We've blogged in the past about how password auditing is accomplished much more efficiently buy auditing a policy than trying to brute force a password. Combining this new feature of not testing for user accounts specified with the scan policy along with the configuration auditing features of the Direct Feed is an excellent way to efficiently test your system configurations without impact.

If you are a Nessus 3.0.6 Windows user, the client distributed with along with the Nessus scanner does not support this new scan option. Instead, users should upgrade to the new Nessus Client 3.0.

If you are a Nessus user, you are no doubt familiar with the process to subscribe your Nessus scanner to the Direct Feed or Registered Feed to automatically receive new vulnerability plugins produced by Tenable's research group.

With Nessus 3.2 (currently in beta and available for download as Nessus 3.1.5) a similar process is available to upgrade the Nessus scanner itself. This blog entry will show how users who have installed one of the Nessus 3.1.x beta releases of Nessus 3.2 can automatically upgrade.

Automatic Upgrades

To update the release of Nessus, the scanner must be subscribed to either the Direct to Registered plugin feeds. If your Nessus scanner is automatically receiving plugins then you will be able to upgrade when new releases are available.

The update process is run from the command line with the new command 'nessus-update' which is located in the ~/sbin installation directory. While in the ~/sbin directory, you can check your version of Nessus by invoking the Nessus daemon with the -v command:

[root@cosmic sbin]# ./nessusd -v
nessusd (Nessus) 3.1.3. [build A567] for Linux
(C) 1998 - 2007 Tenable Network Security, Inc.

To check for a new build of Nessus, and to install it, simply run the 'nessus-update' command:

[root@cosmic sbin]# ./nessus-update
Nessus 3.1.5 is available. Do you want to upgrade to this version ? [y]

The program checks to make sure that Nessus is subscribed to either a Direct or Registered feed and that a new build is indeed available. If both of these conditions are met, the package will be downloaded and installed.

The update download is signed and the signature of the update is checked against the nessus.org public key that is in place.

If your Nessus scanner is set to also update its plugins, a plugin update will be invoked right after an upgrade is completed.

Current Nessus 3.2 Beta Status

The latest release of the Nessus 3.2 beta is version 3.1.5 and is available for download from the Nessus web site. Nessus 3.2 beta downloads are available for Linux, FreeBSD and Solaris. Windows and OS X versions are currently in development. The Nessus 3.2 beta supports IPv6 scanning, a library to write custom WMI queries and also a command line program to initiate a complete vulnerability scan.

If you have also started to use the NessusClient 3.0 to manage your scans, if you connect to a Nessus 3.2 beta scanner, you will notice two new things. First, the login process is much faster. And second, during a scan, you now have an option to pause an on-going scan, as shown below:

Tenable Network Security's research group has released a new Nessus plugin which can make use of the Remote Desktop Protocol (RDP) to accurately detect Windows Vista, 2000 Server, 2003 Server and XP Professional. The Remote Desktop Protocol is also sometimes referred to as Terminal Services. This protocol allows remote users and administrators to view the desktop of a Windows system offering this service to control the mouse, keyboard, run applications and otherwise run the system remotely.

Being able to communicate with RDP (which runs on port 3389) to determine the Windows operating system is very useful. Windows systems that are not part of a domain are often managed through RDP. If they have been hardened with a firewall to only offer the RDP service, this technique is an efficient way to identify the operating system.

As a form of detection, this type is perhaps the easiest for a human to perform, yet requires a high degree of skill and sophistication to perform this with a computer. You and I can usually simply look at a login screen and recognize the "Windows XP Pro", "Windows 2003" or other types of visual queues to identify an operating system. However, performing this type of analysis with a computer is non-trivial.

Consider the following login screen below:

You could probably tell this was some sort of Windows system before even trying to enlarge the above image.

Can you tell which version of Microsoft it is?

Can you tell which language this OS has been provisioned for?

Attempting to do this via RDP was an interesting challenge. The RDP protocol offers a variety of information including bitmaps and streams of text (which are really more bitmaps). One could imagine performing optical character recognition on the login screen bitmap logos or even creating a table of checksums for known bitmap images. Both of these techniques aren't reliable as many organizations and third part vendors (like Novell) can change the login bitmaps. Tenable was able to develop a technique to reliably fingerprint the information used to render text during the login process. This text can be used to identify and discriminate Windows XP Pro, Windows 2000, Windows 2003 and Vista operating systems.

Output from this plugin has also been integrated into the os_fingerprint.nasl script, which combines a wide variety of credentialed and non-credentialed operating system guessing techniques to accurately determine a remote operating system.

The plugin is currently available to Direct Feed and Security Center customers and works with the Nessus 3 vulnerability scanner on all available versions. Updating your plugins will automatically make this check available to your Nessus scanner.

Tenable Network Security has officially released the GA version of the NessusClient 3.0.0. This new client can be used to manage scans and results from UNIX and Windows Nessus daemons. The major new features of the NessusClient include:

• Real-time results. No need to wait until the end of a scan to start analyzing the findings of Nessus. As your scans occur, the results are displayed and updated in real-time.
• Document based. Save your policies, scan results and scan targets into a single file.
• New XML based report format. The new '.nessus' file format saves into a single XML file for your scan policies, scan targets and scan results.
• Multiple connections. The NessusClient can connect to several Nessus scanners at the same time.
• Consistent interface. The same interface exists on Mac OS X, Windows and Linux. This makes working with other users who have a different operating system much easier.

The NessusClient is available for Windows, Ubuntu Linux, Debian Linux, Red Hat Enterprise Linux 4 and 5, Fedora Core 6 and 7, and OpenSUSE 10.2. It can be downloaded from nessus.org.

We've blogged about the Nessus Client (and provided many screen shots) in the past here.

The NessusClient can be used on Nessus 3 and Nessus 2 scanners, is compatible with the Direct Feed subscription for performing configuration and content audits and can also be used on Nessus scanners being managed by the Security Center.

Tenable provides a wide variety of information on our vulnerability plugins to the public. This includes RSS feeds, a plugin writer mailing list and an on-line search portal. By visiting the plugins summary page, Tenable publicly displays our latest signature count and how many unique CVE and Bugtraq IDs are currently covered. What I'd like to do in this blog entry is to move beyond the raw "counts" of vulnerability checks and provide some insight into what these numbers mean. The statistics and figures in this blog entry occurred through an analysis of a snapshot of Direct Feed plugins from September 21, 2007.

Multiple Plugins May Test for the Same Vulnerability

I've spoken with several customers who ask "Do you have a check for ...?". My answer is usually one of:

• Yes
• Yes, but you need credentials
• Yes, but a specific port needs to be open

The easiest type of vulnerability audit to perform is a patch audit. The Nessus scanner simply logs into a target host and performs an operating system specific query to determine if a given patch is installed or not. This works for servers, clients and usually for third party software.

When speaking with a Nessus user that doesn't have access to log into a remote host, having a patch audit doesn't help them very much. If a remote check is possible (this is not always the case, especially if the target application doesn't have any ports open) Tenable's research group will write a plugin to detect this as well.

Since Tenable expects Nessus to be run in many different types of secured and unsecured network environments, we may even develop multiple checks for the same vulnerability, but employing many different techniques. This includes writing checks for the same vulnerability that can occur on different ports.

Identifying Network Services, Applications and Operating Systems

Nessus includes many different types of logic to fingerprint remote network devices and applications. The following list shows how many unique items are checked for.

• Plugins 11153 and 17975 detect more than 210 different types of network services and devices. This is done through port-independent banner analysis as well as specific network probe/response combinations. 
• Plugin 25244 (os_fingerprint_ntp.nasl) detects 11 different UNIX operating systems based on the network time protocol.
• Plugin 25250 (os_fingerprint_sinfp.nasl) includes 351 TCP/IP fingerprints for a wide variety of OSes and network devices.
• Plugin 25247 (os_fingerprint_http.nasl) detects 52 different operating system varieties through analysis of web service.
• Plugin 25246 (os_fingerprint_snmp.nasl) detects more than 40 different types of devices and operating systems running an SNMP service.
• The os_fingerprint_smb.nasl or os_fingerprint_msrpc.nasl NASL plugins identify remote Windows versions with accuracy approaching 100%.

Most Plugins Will result in a Single Severity Level

Tenable's research team usually write plugins that perform a single test and then log the results with a specific severity level. On rare occasions, Tenable will produce a plugin that may report multiple severity levels depending on what sort of logic was encountered by the plugin, if credentials were needed to perform the scan and so on. Of the current plugins analyzed for this blog entry, there were 29 different Nessus plugins which can report multiple severity levels for the same scan depending on the results.

Not All Plugins test for Critical Issues, but Most Do

Tenable keeps Nessus up to date with the latest techniques to identify a wide variety of information used to audit your network. Some of the plugins check for very critical items while others simply detect
applications or certain devices.

All Nessus plugins have a severity rating of low, medium or high. Historically, Tenable has scored  severity ratings as Informational, Medium or Hole, but for this blog post, we will refer to them as low, medium and high. Tenable uses the CVSSv2 scoring system to score plugins and then use that score to select severity levels. For patch audits, Tenable makes use of severity scores in vendor patch information. If patch severity information is not provided, (such as in the Solaris patch feed) Tenable scores the patch as a High severity.

Of the current 15,385 plugins, here is the following break down of plugins that can score by severity level:

Severity          Count
-----------------------
Low                1009
Medium             1875
High              12501

Perhaps more interestingly is to also analyze this breakdown by Nessus plugin family:

Family                           Low   Med.    High
---------------------------------------------------
AIX Local Security Checks          0      0     116
Backdoors                          1      5      65
Brute Force Attacks                0      0      25
CentOS Local Security Checks       0      0     353
CGI Abuses                       192    510     784
CGI Abuses: XSS                  121    130      22
CISCO                              2     14      63
Databases                         12     27      44
Debian Local Security Checks       0      0    1363
Default UNIX Accounts              0      0      47
Denial of Service                 22     90     189
Fedora Local Security Checks       0      0     829
Finger Abuses                      2      5       4
Firewalls                         14     10      13
FreeBSD Local Security Checks      1      5     991
FTP                               22     27      84
Gain a shell remotely              8     22     109
Gain root remotely                 2     17     267
General                           67     17      42
Gentoo Local Security Checks      61    576     370 
HP-UX Local Security Checks        0      0    1009
MacOS X Local Security Checks      4     14      56
Mandrake Local Security Checks     0      0    1109
Misc.                             63     39      83
Netware                            0      5       3
NIS                                2      0       2
Peer-To-Peer File Sharing         26      6       4
Port scanners                      6      0       0
Red Hat Local Security Checks      0      2     863
Remote file Access                 4     20      51
RPC                               27      4      16
Service Detection                157      3       5
Settings                          16      0       0
Slackware Local Security Checks    0      0     235
SMTP Problems                     10      3      57
SNMP                               2      7       3
Solaris Local Security Checks      0      0    2106
SuSE Local Security Checks         0     99     174
Ubuntu Local Security Checks       0      0     321
Useless Services                  13      8       0
Web Servers                       33     36      46
Windows                           89     84     355
Windows: Microsoft Bulletins      19     76     218
Windows: User Management          16      9       0

This means that the majority of what Nessus looks for is "bad news". Very often, I will hear a customer or a consultant say that the network is not doing well because a system had 1-2 major holes. This is indeed serious, but consider if someone had said that out of 10,000 potential high severity ratings, a system "only" had two.

It's also worth noting that several (most notably the Solaris patches) do not have severity ratings provided by the source vendor. Tenable automatically scores these as "high" severity levels because there is no corresponding CVSS score or severity rating.  We are investigating re-using CVSS scores for similar vulnerabilities as referenced by CVE or Bugtraq IDs.

Linking Plugins with Third Party Information Sources

Of the roughly 15,000 Nessus plugins, these comprised checks for 7418 unique CVE entries and 5769 unique Bugtraq IDs. As was discussed earlier, there may be multiple plugins for a single vulnerability, but also a single plugin might also cover multiple CVE entries. The same is true for Bugtraq IDs. For example, Nessus ID 10970 checks for six CVE entries from 2001.

The Nessus plugins also consider cross references with the Open Source Vulnerability Database. In the analyzed data set, there were 1581 entires which had OSVDB links.

All of this can be used to search Nessus plugins under Tenable's plugin search engine.

Also, Tenable automatically synchronizes all CVE and Bugtraq IDs with both the Mitre CVE project as well as the OSVDB database.

Correlating Vulnerabilities with Network IDS Events

Tenable has several relationships with different NIDS vendors. A common practice among SIM vendors is to look for an IDS event which has occurred on a system with a relevant vulnerability. We've blogged about this before and have an online webinar which discusses the topic.

As part of Tenable's update service to our Security Center product, we produce a table of pre-correlated IDS event to vulnerabilities. This allows for realtime VA/IDS correlation.

While I don't want to abuse any of the relationships we have with other companies, I would like to simply list how well various network IDS solutions correlate with Nessus. This following list represents which NIDS correlate "the most" with detected Nessus vulnerabilities.

1. Juniper
2. Tipping Point
3. IBM (ISS)
4. Snort (Sourcefire VRT Rules)
5. Enterasys (Dragon)
6. Cisco
7. Snort (Bleeding Threat Rules)

We counted one correlation for every unique IDS event and Nessus plugin combination. Some NIDS rules correlated with multiple Nessus plugins and other NIDS had multiple different IDS rules which all correlated with the same Nessus plugin. When we normalized this set towards "supported" CVE entries, the list did not change much.

For More Information

Many Tenable customers and Nessus users make use of the RSS feed of Nessus plugin updates. This feed includes all available updates for the Direct Feed.

Previously, we've also blogged about Tenable's usage of CVSSv2 NIST scores to rates vulnerabilities.

Nessus 3 UNIX scanners have the ability to save all of their generated packets as a convenient libpcap compatible file. This means you can save your scans and view them under applications such as TCPDUMP or Wireshark. Please note that this feature is not available on Nessus 4.

Why is this Useful?

There are many reasons to do this.

Having a network trace can greatly assist in diagnosing your environment as well what Nessus is attempting. Tenable's support group often encounters customers who are scanning hosts that are firewalled or are being screened with an intrusion prevention system which is spoofing responses. Having exact packet logs of what is occurring can help diagnose the results.

When new devices are encountered, having a packet dump of what has occurred is very useful for sending information to Tenable's research group. This helps our team write better plugins with the exact bytes and responses being seen in the wild.

Saving a packet dump is also a good way to "prove" that a system was scanned. Text reports can easily be manipulated. Manipulating the 1000s of network connections, three way handshakes and specific protocols can be faked but requires much more effort.

If you have a product like the Passive Vulnerability Scanner which can accept libpcap network traces, these packet traces can be replayed at a later date. If your PVS is updated with newer rules than when the scan occurred, you may be able to conclude new information about vulnerabilities on a network scanned some time ago.

And lastly, having a pure network log of a full vulnerability scan can be very useful for stress testing your network intrusion detection or prevention system. Replaying network scans at a high rate of speed can test how well your network monitoring systems are working.

How is this accomplished?

Within your scan policy settings, there is a setting named 'Save a packet capture of the scan'. In the Nessus 3 client beta, this option is found under the 'Options' tab as shown below:

When a scan is completed, the results will be found in the 'tmp' directory. On RedHat systems, this is /opt/nessus/var/nessus/tmp. Files will be named for the target system IP addresses as well as the process ID of the nessusd instance which performed the scan. Below is a screen shot which shows some example traces:

The trace files can be readily read by TCPDUMP and Wireshark. To view this data under TCPDUMP, use the -r option to specify the source trace file as shown below:

A screen shot of a Nessus scan as viewed under Wireshark is shown below:

Keep your Traces as Secure as your Scan Results

If you do record network traces of your scan results, please treat them as sensitive information. These traces may contain passwords, vulnerabilities and sensitive data that should not be given to unauthorized people.

There are many consultants that use Nessus to scan a customer network for vulnerabilities and report a laundry list of security issues which need to be fixed. Another valuable service that can be performed by a consultant is to audit where sensitive data resides in an organization and what sort of access can be gained to it. This blog entry discusses what can be accomplished with the Nessus scanner and what additional types of data analysis can be performed with the sensitive content checks available with the Nessus Direct Feed.

What is "Sensitive Data"?

In the government and military, there are in-depth standards for classifying the sensitivity of data such as "SECRET", "TOP SECRET" and so on. This classification details who can have access to the data and what level of security assurance should be invoked to protect inadvertent disclosure.

For the rest of the world, classifying data may not be as simple. An organization may draw data classification requirements from the compliance regulations it is under. A public and private company both governed by PCI will likely treat their customer credit card data the same way. However, the public company may consider emails about projected revenues, mergers and such, much more seriously than a private company due to SOX requirements. Other companies may have unique requirements to protect the secret beverage drink recipe, plans for the new stealth bomber or conceal the latest marketing campaign.

As a consultant, asking the customer what their data controls and concerns are is a very good place to start. There is always a very strong possibility that an executive's or manager's view of data classification and access controls may be different than what is actually occurring in the organization. As an "outsider" to the organization, the consultant may also have different views as to how data is classified which is based on common sense, prior experience and general industry practice.

With an understanding of what may be sensitive or damaging to an organization if it were lost, Nessus can be used to scan a network from many vantage points and discover where this information is located at.

Finding the Data with Nessus

Information stored on the network is accessed over the network. The following Nessus plugins and families will identify a wide variety of services which enable information sharing on a network:

• Office Files List - scans web servers for the presence of "office" files.
• SMB Shares Enumeration - lists the directories and folder names available for file sharing.
• SMB Share hosting Office Files - scans for servers with a network SMB file share that host .doc, .xls, .ppt and other types of "office" files.
• SMB Share hosting Copyrighted Material -  scans for SMB shares hosting MP3s, AVIs and other types of media.
• Web Server hosting Copyrighted Material -  scans for web servers which are hosting MP3s, AVIs and other types of media.
• FTP Server hosting Copyrighted Material -  scans for FTP servers which are hosting MP3s, AVIs and other types of media.
• USB Drives Enumeration - lists all USB disk drives present on a Windows server.
• NFS Exports - lists all NFS directories that are available.
• Peer to  Peer  file sharing - this set of plugins not only identifies vulnerabilties in common P2P applications, it also identifies the mere presence of them.
• Databases - this set of plugins not only identifies vulnerabilities in common SQL database applications, it also identifies where they are located.
• And last but not least, there are 100s of Nessus plugins which identify basic data hosting services such as HTTP, FTP, NFS and so on.   

Of course, data can be obtained many other ways including the "sneaker network", screen captures through RDP/VNC sessions, sniffing network traffic, copying snapshots of VMWare systems and so on. The point of this exercise with Nessus is to analyze the local network for the "easy" things an average employee may come across without the use of any special tools. I also chose to include the search for potentially illegal music and movie content as part of the sensitive data search because it can highlight certain types of data that management or executives may not know about.

Analyzing the Results

When providing an analysis of the discovered types of data with Nessus, I recommend the following strategies:

• Does the discovered data "look" interesting? When Nessus finds a file share, it will generally list as many of the file names or directory titles found in the scan report. Analyzing this data is a manual process, however, as a consultant you may find enough interesting file or directory names that you can raise a concern. If the share or access is "open" you may even be able to pull back the documents and analyze them yourself. In the next section, we will consider how the Direct Feed can be used to look for specific types of sensitive data by actually looking at the content of the files themselves.
• Who can access this data? Depending on where you performed your Nessus scan, you may have been able to identify data that was obtainable from "outside" of an organization. Keep in mind that "outside" could be mean someone on the Internet, or perhaps could simply mean someone from the accounting group being able to access private human resources data. Performing multiple scans from vantage points across a network could reveal different levels of access or trust that various groups have with each other.
  
• Does the underlying server have vulnerabilities? When you find a server hosting office files, if it has major vulnerabilities it may be exploitable. This may be irrelevant information or it may not. A vulnerable web server with 1000 sensitive PDF documents on it may be just as damaging to an organization if the web server was fully patched but had the documents available to everyone. On the other hand, a vulnerability on an office automation system such as Lotus Notes, Share Point or a Wiki could allow circumvention of the security controls in those applications.  A consultant should be able to differentiate these to situations and recommend where vulnerabilities need to be fixed or more fine-tuned access be added to information sharing resources.
• Does a network of trust have vulnerabilities? If access to data is found through a certain location in the network, such as being able to see sales or customer data from the accounting group, then the vulnerabilities of that location should be considered.  The idea is to look for organizations that are "trusted" to access the sensitive data, but are also vulnerable to attack.
• Does the network service serve a purpose? Lastly, Nessus will highlight any type of network service it can find. This includes temporary shares, file services and other types of daemons. As a consultant, if you can ask (and get answers) about where servers are supposed to be, what types of servers are supposed to be there and what types of servers should not be running. As a consultant performing an audit, you may find discrepancies in what should be happening and what actually is happening.

Scanning for Known Sensitive Data Types

The Nessus Direct Feed includes a set of content auditing plugins which open up Word, Excel, PDF, text and other types of files to look for patterns that indicate the presence of credit cards, social security numbers and many other types of content.

The Tenable Support Portal offers several dozen polices that can be used with Nessus to look for sensitive file names, to look for various key words and watermarks and to also identify intellectual property at rest. These audit polices are writen in a simple XML type language which specifies what file extensions to look at, how much of a file should be analyzed, and which keywords and pattern matches should be searched for. These policies can be modified and customized as well as written from scratch.

The example below looks at the first 5000 bytes of each PDF,  Word and Excel file for phone numbers. One of the words such as "FAX", "Phone", "Cell" or "Mobile" must be present and if so a regular expression which matches a phone number such as 123-456-7890 as well as 123.456.7890 will be performed.

<item>
     type: FILE_CONTENT_CHECK
     description: "Determine if server is hosting phone contact info"
     file_extension: "pdf" | "doc" | "xls"
     regex: "[0-9]{3}[ \.\-][0-9]{3}[ \.\-][0-9]{4}"
     expect: "FAX" | "Fax" | "Phone" | "PHONE" | "CELL" | "Cell" | "Mobile" | "MOBILE"
     max_size : "5k"
</item>

When Nessus performs these scans it not only lists the servers which did have matching content, it also lists the servers which "passed" and did not have any types of content on them.

There are many obvious uses for this technology such as:

• Scanning for credit card information on systems that should not have that type of data.
• Finding employee information,  customer information and other types of data useful for identity theft.
• Looking for source code, text, manuals, .etc which are proprietary in nature and should not be available throughout or outside of a company.
• Leveraging an organization's existing copyright, data classification guides or watermarks to find data on servers or systems that should not exist.
• Finding data stores for employees which have nothing to do with the organization. For example, finding an employee's personal tax, credit card, health, insurance and other types of  information stored in a "public" place.
• Finding lists of customers, their contact information and existing or projected revenues

Conclusion

As a consultant, the ability to look for sensitive data where it should not be is a valuable service that can be provided to your customers in addition to security auditing. For more information, please consider these other blog entries and demonstration videos:

• Searching for Classified Content in documents
• Scanning your network for Copyrighted material
• Configuration and Content audit video

Several weeks ago, a good friend of my family who is a lawyer for an application hosting company and I were speaking about network security and I brought up Nessus. "Can you scan one of our hosted sites?" he asked. A short while later, especially after asking the right sort of legal questions, we were looking at the results of a non-credentialed Nessus scan for a high traffic web site.

His web site didn't have any "application" content and hosted static HTML web pages. The only odd thing to note was an SSH server found on a very high port.

"Is that bad?" asked my friend.

"Well, it doesn't have any publicly known vulnerabilities." I said.

"So that's good, right?".

I told him I had two thoughts.

First, if the administrator thought to actually put the SSH server on a port other than 22, they might also want to take some extra steps and perhaps lock down SSH a bit tighter, or even mask it from generic access to the Internet. They may have been able to disabled some unneeded functionality of SSH, avoid using passwords or potentially use some sort of firewall or VPN so I couldn't connect to their SSH daemon.

Second, my friend should ask the administrator of that site if they noticed any unauthorized login attempts through SSH or from the other services. Nessus tries all sorts of things to the various services it probes and this activity generates logs in the form of failed login attempts and error messages. If there is any type of monitoring activity ongoing, it should alert on some part of the Nessus scan.

"I had heard them say that SSH was secure." he commented.

I then pulled up all the SSH vulnerabilties and patch audits that Nessus can check for and showed him. He was initially concerned that SSH wasn't secure, period. I had to spend a short bit of time explaining vulnerability life-cycles and how an undiscovered vulnerability can be latent in operating systems and applications right now.

These statements didn't provide much comfort.

On a lark, I showed him some Nessus scans of web sites that had many different types of vulnerabilities. This had the opposite effect I was intending in that he was somewhat comforted by the fact his web site was better off than others.

What I felt was really interesting about our conversation was that we never once mentioned things like CVSS or NSA Best Practice hardening guides. What he really wanted to know was if they were secure or not. Is there something someone on their staff was doing wrong or something else they could do better? Although not an IT or network security practitioner, as a lawyer, he was putting everything in terms of risk to the business which is a good thing.

The BETA of Nessus 3.2 includes support for a new command line method to invoke quick Nessus scans. This blog entry details some interesting examples for port scanning, operating system identification, testing of a certain bug and testing Windows and UNIX credentials using the nessuscmd tool.

'nessuscmd' Usage

Simply running the command (located in your ~/bin Nessus install directory) will show you the usage. New features and settings may be added before this product is officially out of BETA.

Command line options exist for:

• Port Scan options
• Selecting Vulnerabilities
• Providing UNIX and Windows Credentials
• Scan settings (such as 'max-hosts' or using a remote Nessus daemon)

Port Scans and Operating System Identification

Here is an example port scan with operating system identification invocation:

atragon# ./nessuscmd -sS -v -O -p 1-1024 192.168.20.24
Starting nessuscmd 3.1.4
Scanning '192.168.20.24'...

Host 192.168.20.24 is up
Discovered open port netbios-ssn (139/tcp) on 192.168.20.24
Discovered open port microsoft-ds (445/tcp) on 192.168.20.24
[i] Plugin 11936 reported a result on port general/tcp of 192.168.20.24
+ Results found on 192.168.20.24 :
   - Host information :
     [i] Plugin ID 11936
      | The remote host is running Microsoft Windows XP

   - Port netbios-ssn (139/tcp) is open
   - Port microsoft-ds (445/tcp) is open

Running the nessuscmd utility with a few targeted ports is a great way to quickly obtain very accurate OS ID scans from the command line.

Testing For VNC

Using the Nessus.org plugins search tool, I found 5 plugins that enumerate or identify VNC and test for vulnerabilities associated with it. These were plugins 10342, 10758, 19288, 19289 and 21564. Running the nessuscmd tool can show specific results for these vulnerabilities as shown below: 

atragon# ./nessuscmd  192.168.20.0/24 -i 10342,10758,19288,19289,21564
Starting nessuscmd 3.1.4
Scanning '192.168.20.0/24'...

+ Results found on 192.168.20.9 :
   - Port vnc (5900/tcp)
     [i] Plugin ID 19288
      | The remote VNC server supports those security types:
      | + 2 (VNC authentication)
      |
+ Host 192.168.20.11 is up
+ Results found on 192.168.20.16 :
   - Port vnc (5900/tcp)
     [i] Plugin ID 19288
      | The remote VNC server supports those security types:
      | + 2 (VNC authentication)
      |
+ Host 192.168.20.24 is up
+ Host 192.168.20.28 is up
+ Host 192.168.20.29 is up
+ Host 192.168.20.199 is up
+ Host 192.168.20.201 is up
+ Host 192.168.20.203 is up
+ Host 192.168.20.205 is up

Notice that this scan was performed against the class-C subnet of 192.168.20.0/24. Also notice that the results of these scans were 'informational' as indicated as such by the [i] next to the particular plugin ID output.

Testing for UNIX and Windows Credentials

The nessuscmd tool can also invoke plugins and pass them credentials to log into remote UNIX systems. The --ssh-login and --ssh-password arguments can be used to specify remote access. Here is an example of such a scan which enumerates installed software:

#atragon ./nessuscmd -v 192.168.20.11 -i 22869 --ssh-login root --ssh-password password

(long list of enumerated software deleted)

      | fonts-xorg-100dpi-6.8.1-1|(none)
      | libgnomeprint22-2.8.0-3|(none)
      | eel2-2.8.1-2|(none)
      | linuxwacom-0.6.4-6|0
      | gtk+-1.2.10-33|1
      | imlib-1.9.13-23|1
      | libpng10-1.0.16-1|(none)
      | pyparted-1.6.8-2|(none)
      | gtk-engines-0.12-5|1
      | gnome-kerberos-0.3.3-1|(none)
      | xscreensaver-4.18-5.rhel4.2|1
      | gnome-media-2.8.0-3|(none)
      | gnome-terminal-2.7.3-1|(none)
      | gnopernicus-0.9.12-1|(none)
      | vino-2.8.1-1|(none)
      | eog-2.8.1-2|(none)
      | gnome-volume-manager-1.1.0-5|(none)
      | desktop-printing-0.17-3.EL.1|(none)

Similarly, Windows systems can also be tested with the --smb-login and --smb-password arguments. We will use plugin #17651 which obtains the password policy.

atragon# ./nessuscmd -v 192.168.20.16 -i 17651 --smb-login Administrator --smb-password password
Starting nessuscmd 3.1.4
Scanning '192.168.20.16'...

Host 192.168.20.16 is up
[i] Plugin 17651 reported a result on port microsoft-ds (445/tcp) of 192.168.20.16
+ Results found on 192.168.20.16 :
   - Port microsoft-ds (445/tcp)
     [i] Plugin ID 17651
      | The following password policy is defined on the remote host:
      |
      |
      | Minimum password len: 0
      | Password history len: 0
      | Maximum password age (d): 42
      | Password must meet complexity requirements: Enabled
      | Minimum password age (d): 0
      | Forced logoff time (s): Not set
      | Locked account time (s): 1800
      | Time between failed logon (s): 1800
      | Number of invalid logon before locked out (s): 0

For More Information

Please send any feedback for the Nessus 3.2 BETA to Tenable's Director of Research, Renaud Deraison. Previously, we've blogged about Nessus 3.2's ability to perform IPv6 scanning as well as make use of pre-compiled NASL libraries, in particular to leverage Nessus's ability to query Windows WMI information.

The Nessus 3.2 BETA is currently available as Nessus 3.1.4 and is available for download at nessus.org under the downloads section.

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.

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.

Tenable's research group recently released a WMI based plugin for Nessus 3 that can determine the active wireless SSID for remote Windows devices. This allows an organization to obtain a list of active wireless domains for all Windows devices on their network. This blog entry discusses the security and auditing ramifications of this plugin.

Example Report

Below is an example report generated by this Nessus plugin. The SSID of the laptop scanned was "mytestssid".

Synopsis :

It is possible to obtain the active associated wireless SSID of the remote
computer.

Description :

This script uses WMI to obtain the wireless network card and associated SSID
of the remote computer. The remote system must have an active wireless
connection for this detection to occur.

Solution :

Make sure any SSIDs that are discovered comply with corporate policy.

Risk factor :

None

Plugin output :

Network Card Type : Intel(R) PRO/Wireless 3945ABG Network Connection
Network SSID: mytestssid

Why is this useful?

There are two questions answered with this plugin:

• Do we have any "wired" devices that have also associated with a wireless domain?
• Which wireless domains are active on our network?

If wireless networks are authorized in your network, then they can be audited with this plugin. Collecting the active wireless domains on each host is very easy when scanning with a credentialed Nessus scan.

The most serious issue is to find a host on your network that has both associated with an external wireless access point and also has an internal "wired" connection. If your offices are near public wireless access points, access points from nearby businesses or even available access points inside your organization, you may have laptops that have a wired link and also be associated with an unauthorized access point. This could bypass your firewall or access control, provide direct access to a system that might not be patched or even expose files and network shares to attackers outside of your network.

If a Windows system is found with an active wireless device, it should also be questioned if this is authorized. Organizations that have an issue with management of mobile devices and networks would find it interesting to get an accurate list of all "SSIDs" in use. This plugin may find new or unauthorized SSIDs in use that your IT organization was unaware of.

Analyzing the Data with the Security Center

Once scans have been completed, the Security Center can easily be used to analyze the data. There are two basic techniques that can be applied - ad hoc analysis and creation of dynamic asset lists based on the detected SSIDs.

For ad hoc analysis, the Security Center can be used to navigate and browse the collected information. The "text" field can be used to highlight any matching systems with known SSIDs. For example, to obtain a list of all systems with an SSID that matched "SSIDTEXT", this would be typed into the text search box and plugin ID #25197 would be searched for as shown below:

All matching hosts can then be sorted by IP address, their MAC address, DNS name or Windows name and then have the entire set of matched data exported in a spread sheet or PDF report.

The Security Center can also use the content from Nessus and Passive Vulnerability Scanner discoveries and audits to create lists of computers based on certain parameters such as open ports, the output of a check and so on. These are known as "dynamic asset lists".

For analysis and reporting of discovered network SSIDs, there are two approaches that can be used:

• Create a dynamic asset list for each "known" SSID
• Create a dynamic asset list of "unknown" SSIDs

If you had an SSID of "CORPORATE", you could create a dynamic asset list that looked for the presence of plugin ID #25197 and the content "CORPORATE". If your set of corporate approved SSIDs all had the same sort of root text such as "CORP1", "CORP2", "CORP3" and so on, you may want to consider only testing for the pattern "CORP" or a regular expression of "CORP[0-9]{1,3}".

Once the scans have been completed and asset lists have been created, there are several types of analytics that can be performed such as asking:

• Are any IP addresses being used on SSIDs which are incorrect? This may provide insight to issues with poorly configured VLANS or DHCP servers. If incorrect IP addresses are being given out, this may also identify an access control issue.
• Are there any vulnerabilities or open services (such as FTP or P2P) in use on wireless nodes with WEP disabled? For public access, not using the "Wired Equivalence Protocol" is convenient for your guests, but if permanent services reside on those networks, they may be attacked.
• For critical asset groups such as your financial, human resources, demilitarized zones and so on, do any of their systems make use of wireless nodes? If so, are they authorized and properly secured.

For More Information

This Nessus plugin is currently available to Direct Feed and Security Center customers. Organizations interested in performing active and passive wireless assessments with Tenable technology should consider the following links and resources:

• Using Nessus to Detect Wireless Access Points - This paper details how Nessus can be used to scan for a variety of web, ftp and SNMP management interfaces for a variety of wireless access point devices.
• Passive Vulnerability Scanner - the PVS can also be used to sniff management active to/from a wireless access point. In addition, if the access point also has multiple users behind it with NATed IP addresses, the PVS will identify this device.
• Access Point Detection - Nessus plugin 11026.
• Asking Vista for its list of Interfaces - This blog entry details plugin #24904 which uses the LLTD protocol to ask Vista OSes for their list of network interfaces and wireless SSIDs.
• Network Interface Enumeration - Through WMI, Nessus can enumerate the list of active network devices, their assigned IP addresses and available routes on Windows computers.

Tenable's research group recently released plugin ID #24904 which speaks with the Link Layer Topology Discovery protocol. This is an Ethernet "layer 2" scan, so it is something you need to perform against a server within the collision domain of a Nessus scanner. LLTD allows you to enumerate a wide variety of information about the remote host. The current NASL script supports discovery of:

• host ID
• Physical Medium
• IPv4 and IPv6 addresses
• Link Bandwidth type
• Machine Name

Below is an obscured screen shot of a scan of a test Vista system.

Security Center customers can make use of this data to write dynamic asset lists for automatically classifying their Vista systems based on any of the discovered parameters such as name, IPv6 address, the presence of IPv6 and so on.

A useful "non-security" query would be to use the wireless signal strength to find Vista systems that aren't covered with enough wireless signal.

Also, since you can't send these sorts of queries over IP packets, you need to have your Nessus scanner in the same collision domain. Organizations that have deployed multiple Nessus scanners in each of their VLANs can use this check immediately.

Nessus 3.2 will support scanning of IPv6 addresses. The current BETA (released as Nessus 3.1.3) can be used to perform scans of IPv6 addresses. This blog entry shows how to use the current Nessus 3.2 BETA to perform such a scan from the UNIX command line.

Why Scan for IPv6 Addresses?

More and more operating systems are shipping with IPv6 enabled by default. Both Vista and OS X ship with IPv6 stacks. The presence of IPv6  on your network may dramatically alter how computers communicate with each other and connect to the Internet. Communication that occurs over IPv6 may not be blocked by local or network firewalls, observed by network IDS or even correctly logged by your SIM.

For compliance and corporate governance reasons, if you are not detecting IPv6 enabled devices, then you may have unauthorized or mis-configured devices and not know it.

And lastly, one of the more interesting abuses of IPv6 is that in some default situations, an unauthorized or compromised IPv6 host can "declare" itself the router, and then make your entire internal network globally available through the use of a tunnel.

Scanning IPv6 Enabled Systems

If you are used to scanning IPv4 enabled systems, IPv6 can add some new twists. For example, having an active IPv6 address might not allow you to connect to the TCP and UDP services as you can under IPv4. Simply installing an IPv6 address and then scanning the system might not allow connectivity to the various UDP or TCP services.

If you do add an IPv6 address to a host, you may need to restart the application(s) for them to actually "bind" to the IPv6 TCP or UDP 6 sockets. In some cases, depending on the OS and the application, a system reboot may be required or even new application software.

Obtaining Nessus 3.1.3

The current BETA of Nessus 3.2 is available as Nessus 3.1.3 for many different Linux packages and also FreeBSD. If you have an operational Nessus 3.0.x install (such as the currently available 3.0.5 release) you should consider running the 3.2 BETA on a separate host and not upgrade an operational server.

Target Selection

Before running any IPv6 scans, your Linux or FreeBSD scanner needs an IPv6 address on one or more of its interfaces.

IPv6 addresses can be specified directly in the list of targets. In addition, to "ping" the local network for any listening IPv6 addresses the "link6" target can be used.

When specifying a local IPv6 address (starting with fe80::) for Nessus scans, the local network interface of the scanning device must be appended with a "%" sign. For example, the following IPv6 target addresses are correct:

• link6%eth0
• fe80:0000:0000:0000:0216:cbff:fe92:88d0%eth0
• fe80::212:17ff:fe57:333b%dc0

If you were scanning a non-local address, the interface name would not be required. Both full and compressed IPv6 notation is supported.

Running a Scan from the Command Line

When running a Nessus scan from the command line, the nessus client tool is used to connect to a remote Nessus scanner with the following format:

nessus -c <policy> <IP> <port> <user> <pass> <target file> <output file>

For scanning IPv6 networks, nothing is really that different from the command line except that the target file contains IPv6 names. During testing for this blog entry, I used two different text files that had content as shown below:

[root@smog bin]# cat ipv6.txt
fe80:0000:0000:0000:0216:cbff:fe92:88d0%eth0
[root@smog bin]# cat link.txt
link6%eth0

The file ipv6.txt contained the IPv6 address of an OS X system as shown here:

Running a scan from the command line looked like this (with passwords obscured):

nessus -c policy.txt 127.0.0.1 1241 user password ./ipv6.txt ./output.txt

The policy.txt file is any type of .nessusrc file you would normally use to scan an IPv4 host.

Below is the raw results from scanning two different IPv6 addresses. Notice that one host has nothing reported for it, while the second host was able to connect to the SSH daemon on port 22:

Nessus Scan Report
------------------

SUMMARY

- Number of hosts which were alive during the test : 2
- Number of security holes found : 1
- Number of security warnings found : 0
- Number of security notes found : 7

TESTED HOSTS

fe80:0000:0000:0000:0216:cbff:fe92:88d0%eth0 (Security holes found)
fe80::212:17ff:fe57:333b%eth0 (Security notes found)

DETAILS

+ fe80:0000:0000:0000:0216:cbff:fe92:88d0%eth0 :
. List of open ports :
   o general/tcp (Security notes found)
   o ssh (22/tcp) (Security hole found)

. Information found on port general/tcp

    fe80::216:cbff:fe92:88d0 resolves as
     fe80:0000:0000:0000:0216:cbff:fe92:88d0%eth0.

. Information found on port general/tcp

    Information about this scan :

    Nessus version : 3.1.3
    Plugin feed version : 200703200708
    Type of plugin feed : Release
    Scanner IP : fe80::20c:29ff:fed1:8965
    Port range : default
    Thorough tests : no
    Experimental tests : no
    Paranoia level : 0
    Report Verbosity : 1
    Safe checks : yes
    Max hosts : 40
    Max checks : 5
    Scan Start Date : 2007/4/15 11:47
    Scan duration : 592 sec

. Vulnerability found on port ssh (22/tcp) :

    The account 'root' has the password 'root'.  An attacker may use it to
    gain further privileges on this system

    Risk factor : High
    Solution : Set a password for this account or disable it
    CVE : CVE-1999-0502

. Information found on port ssh (22/tcp)

    Remote SSH version : SSH-1.99-OpenSSH_4.5

    Remote SSH supported authentication :
     publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive

. Information found on port ssh (22/tcp)

    Synopsis :

    The remote service offers an insecure cryptographic protocol

    Description :

    The remote SSH daemon supports connections made
    using the version 1.33 and/or 1.5 of the SSH protocol.

    These protocols are not completely cryptographically
    safe so they should not be used.

    Solution :

    Disable compatibility with version 1 of the protocol.

    Risk factor :

    Low / CVSS Base Score : 3
    (AV:R/AC:H/Au:NR/C:P/A:N/I:N/B:C)
    CVE : CVE-2001-0361
    BID : 2344
    Other references : OSVDB:2116

. Information found on port ssh (22/tcp)

    The remote SSH daemon supports the following versions of the
    SSH protocol :

      . 1.33
      . 1.5
      . 1.99
      . 2.0

    SSHv1 host key fingerprint : 57:9a:2e:56:72:62:b6:57:8c:7b:0d:32:b1:aa:15:bf

+ fe80::212:17ff:fe57:333b%eth0 :
. List of open ports :
   o general/tcp (Security notes found)

. Information found on port general/tcp

    fe80::212:17ff:fe57:333b resolves as fe80::212:17ff:fe57:333b%eth0.

. Information found on port general/tcp

    Information about this scan :

    Nessus version : 3.1.3
    Plugin feed version : 200703200708
    Type of plugin feed : Release
    Scanner IP : fe80::20c:29ff:fed1:8965
    Port range : default
    Thorough tests : no
    Experimental tests : no
    Paranoia level : 0
    Report Verbosity : 1
    Safe checks : yes
    Max hosts : 40
    Max checks : 5
    Scan Start Date : 2007/4/15 11:47
    Scan duration : 631 sec

------------------------------------------------------
This file was generated by the Nessus Security Scanner

Notice that one host had "nothing" to report, but could be pinged via IPv6. The second host (a new lab Fedora Core 6 server) had IPv6 enabled and also a major vulnerability ("root" password of "root").

Working with Nessus Clients

Any Nessus client that supports scanning of a "hostname" supports a scan of IPv6 addresses. Nessus clients currently do not have any support for scanning IPv6 ranges.

In addition, when scanning an IPv6 host, don't forget to place the trailing network interface (i.e. "%eth0", "%dc0", .etc) of the Nessus scanner to tell it which NIC to use to perform the scan.

Perhaps the most useful type of quick scan is to do one against "link6%eth0" to ping the local subnet for any listening IPv6 systems. Here is an example screen shot from such as scan performed with a pre-BETA copy of the new Nessus 3.2 Windows client:

For More Information

Please send any feedback to Tenable regarding issues found with IPv6 support in the Nessus 3.2 BETA.

We are also interested in learning more about any plans organizations may have for large scale IPv6 technology deployments and how this may effect your network monitoring, logging and auditing requirements.

If you are interested in testing more aspects of the Nessus 3.2 BETA, we've previously blogged about new features in it at these links:

• Nessus 3.2 BETA -- Example WMI Library Usage
• Nessus 3.2 BETA Available for testing

Tenable's research group today released a check for Nessus which discovers systems not-running NTFS file systems. For example, a system running on top of FAT32 would be detected by this plugin. The plugin is named "Insecure Logic Drive FileSystem" and has a Nessus ID of 24871.

If you have a Windows Server system not utilizing NTFS, then there is very little security offered at the file level. NTFS offers the ability to set permissions on user files and folders and also makes it more difficult to gain access to system files.

The check considers every file system on the remote Windows server, not just those being shared over SMB.

This check is accomplished through Nessus 3 Windows WMI queries and is currently available to Nessus Direct Feed and Security Center subscribers. Tenable releases many Nessus plugins each day and offers this RSS feed for users and customers to remain informed.

The Nessus 3.2 BETA includes many new features, including a library that allows users to program their own WMI queries to Windows systems. This blog entry discuses some example WMI NASL scripts that make use of the new library and identify interesting asset and configuration information about Windows Hosts.

Tenable has already released several Windows security audits based on Nessus 3's WMI implementation. These checks are only available as Nessus 3 .nbin files. The ideas discussed in this blog may be released as future Nessus 3 .nbin files. However, if readers want to experiment with WMI today, they can try the BETA.

Installing Nessus 3.1 and the WMI .nlib library

The BETA of Nessus 3.2 has a designation version of "3.1". At the time of this blog draft, Tenable had released version 3.1.2. It can be obtained at nessus.org. The BETA can be installed over an existing Nessus 3 installation, but you should keep in mind that it still has the BETA designation and shouldn't be placed into production.

The WMI library can be downloaded from here. The file wmi_func.nlib should be installed into the plugins directory such as /opt/nessus/lib/nessus/plugins on Red Hat Linux.

Running A First Query -- Getting the System Name

Remote WMI queries can get a wide variety of asset information about a Windows server. Consider the following Visual Basic code which enumerates a system name:

'ENumerates System Name
On Error Resume Next
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_Processor",,48)
WScript.Echo "SystemName: " & wbemObject.SystemName

The same set of code in NASL with the WMI library looks like this:

import("wmi_func.nlib");
wmiObject = WMI_ConnectServer("root\CIMV2");
if ( isnull(wmiObject) ) exit(0);
res = WMI_ExecQuery(wmiObject, "SELECT * FROM Win32_Processor");
info = WMI_GetNextElement (res);
display(info["SystemName"], "\n");
WMI_ReleaseObject(res);
WMI_ReleaseObject(wmiObject);

Here is an example running from the command line using the nasl binary:

[root@demo3 plugins]# /opt/nessus/bin/nasl -t 192.168.20.16 wmi_test1_name.nasl
Login : Administrator
Password : *******
Domain :
TENABLED-9U86TO

The name "TENABLED-9U86TO" was obtained through a WMI query. Also note for readers not that familiar with running the nasl binary from the command line, it will ask you for credentials as well as other items and preferences at run time.

Second Query - Get the OS and Patch Level

Using WMI to obtain the specific operating system release and patch level is a simple query.

import("wmi_func.nlib");

wmiObject = WMI_ConnectServer("root\CIMV2");
if ( isnull(wmiObject) ) exit(0);

res = WMI_ExecQuery(wmiObject, "SELECT * FROM Win32_OperatingSystem");
repeat {
info = WMI_GetNextElement (res);
display(info["Caption"], " ", info["ServicePackMajorVersion"], "\n");
} until (isnull(info));

WMI_ReleaseObject(res);
WMI_ReleaseObject(wmiObject);

And here is the output:

[root@demo3 plugins]# /opt/nessus/bin/nasl -t 192.168.20.16 wmi_test2_os_patch.nasl
Login : Administrator
Password : *******
Domain :
Microsoft(R) Windows(R) Server 2003, Standard Edition 1

Third Example - Listing Recent Windows Events

WMI can also be used to remotely obtain Windows events. The following code shows how to obtain the last 10 events out of the Windows "Application" log file:

import("wmi_func.nlib");

wmiObject = WMI_ConnectServer("root\CIMV2");
if ( isnull(wmiObject) ) exit(0);

res = WMI_ExecQuery(wmiObject, "Select * from Win32_NTEventLogFile Where LogFileName = 'Application'");
info = WMI_GetNextElement (res);

records = int(info["NumberOfRecords"]);
display("Number of Records : ", records , "\n");

last10 = 0;
if (records > 10) {last10 = records - 10;}
for (i=last10; i<records; i++)
        {
        querry_string = "Select * from Win32_NTLogEvent Where LogFile = 'Application' AND RecordNumber =" + i;
        res = WMI_ExecQuery(wmiObject, querry_string);
        info = WMI_GetNextElement (res);
        display("ComputerName:", info["ComputerName"], "\n");
        display("EventCode:", info["EventCode"], "\n");
        display("Message:", info["Message"], "\n");
        }

WMI_ReleaseObject(res);
WMI_ReleaseObject(wmiObject);

and here is an example run of the code:

[root@demo3 plugins]# /opt/nessus/bin/nasl -t 192.168.20.16 wmi_test4_events.nasl
Login : Administrator
Password : ********
Domain :
Number of Records : 2307
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: accepted: 192.168.20.199::3139
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: closed: 192.168.20.199::3139 (Clean disconnection)
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: accepted: 192.168.20.199::3520
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: closed: 192.168.20.199::3520 (reading version failed: not an RFB client?)
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: blacklisted: 192.168.20.199
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: blacklisted: 192.168.20.199
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: blacklisted: 192.168.20.199
ComputerName:TENABLED-9U86TO
EventCode:1
Message:HTTPServer: untrapped: End of stream
ComputerName:TENABLED-9U86TO
EventCode:1
Message:Connections: accepted: 192.168.20.199::1549
ComputerName:TENABLED-9U86TO
EventCode:1
Message:DeviceFrameBuffer: BitBlt failed:5

There are many possibilities for performing security audits based on Windows event logs.

Enterprise Security and Compliance Relevance

The WMI technology on Nessus allows for very close inspection of many 1000s of Windows servers without an agent. Tests to look for specific configurations can shed light on any organization's IT management practices as well as to look for unauthorized configurations.

For More Information

Microsoft has an MSDN site with many very useful examples of Visual Basic scripts to query just about anything on the remote computer through WMI.

Tenable is actively developing .nbin plugins to perform a variety of audits using WMI. With the Nessus 3.2 BETA and the WMI .nlib library, anyone can quickly prototype queries and test them out. Please feel free to discuss these on the Nessus mailing list, or to send your ideas to Tenable.

Nessus 3.1.2, the first public BETA of what will become Nessus 3.2, has been released for the Linux, FreeBSD and Solaris operating systems. 

Download Nessus 3.1.2

There are many new features available including:

• Experimental IPv6 support
• Improved bandwidth throttling
• Extended nessusd.rules functionality to add support for ports and plugins
• New command 'nessuscmd' which lets you do a quick command-line scan
• Improved NASL engine including an API to write custom WMI checks
• Easy-update : Nessus can now update its own engine by doing /opt/nessus/sbin/nessus-update

This blog entry discusses these new features and how BETA testers should provide feedback. Over the next few weeks, we will discuss these topics (such as IPv6 and the new WMI library) in much more detail.

Experimental IPv6 support

Nessus 3.2 supports IPv6 natively. It allows you to scan any IPv6 host provided that the host it runs on has an IPv6 stack enabled. To scan an IPv6 host, simply type its IP address. If the host is on the local network (fe80::XXXX) you can also specify the interface to use when doing the scan. For example,  enter "fe80::20d:93ff:abcd:efab%eth0" to scan the host fe80:20d:83ff:abcd:efab on the local network connected to eth0.

Note that it is not possible to specify a range of addresses, as scanning each of them would not make sense. For example, scanning fe80::1/64 is an astronomical number and would take a very long time to enumerate each IPv6 address.

Nessus 3.2 has the ability to send a multicast ping query to determine the IPv6 hosts of your local network. Simply enter "link6%eth0" and nessusd will discover all the IPv6 enabled hosts.

Finally, if you scan the same host with both IPv4 and IPv6 addresses (ie: you enter a target of 192.168.1.1 and fe80::4242) then in the final report the same host will appear twice : once as an IPv6 system, and once as an IPv4 host. This is actually not much different than scanning the same physical system that has a "real" IPv4 address and perhaps a second network interface with another IPv4 address.

Improved Bandwidth Throttling

max_simult_tcp_sessions

In order to avoid flooding a network, Nessus now has the ability to define a maximum number of TCP connections in parallel, on a per-nessusd or per-scan basis. In nessusd.conf, setting the following option :

global.max_simult_tcp_sessions = 50

will guarantee that the system running your nessus scan will never establish more than 50 tcp sessions in parallel (wether there is one, ten or one hundred scans going on at the same time).

In your .nessusrc, adding the option :

max_simult_tcp_sessions = 20

will guarantee that your scan will not establish more than 20 sessions in parallel. If you have two scans running with this setting, then your system might end up doing 40 tcp sessions in parallel.

The "max_simult_tcp_sessions" setting is scan based whereas the "global.max_simult_tcp_sessions "is scanner based.

global.max_hosts

It is also possible to configure nessusd on a per-nessusd basis so that a maximum number of hosts are being scanned in parallel. It works like the current "max_hosts" settings, but on a per scanner basis, meaning that if you set "global.max_host" to 20 in nessusd.conf and have 10 scans running, eventually each scan will only scan 2 hosts in parallel.

Extended nessusd.rules

The grammar of the nessusd rules has been extended to let you forbid/allow nessusd to connect to some ports. In nessusd.rules, you can now prevent the connections to some ports. For instance, adding :

    reject 0.0.0.0/0:9100

will prevent the connection to any HP printer on port 9100. The ports can be entered as ranges as well, such as:

    reject 192.168.0.0/24:1-1024

This would prevent scans from connecting to ports 1 to 1024 on the subnet 192.168.0.0/24.

Please note that these rules only apply to TCP ports, not UDP and also that these rules do not work with IPv6 host addresses yet.

Plugin usage can also be limited such as:

    plugin-reject 10335
    plugin-accept 10000-40000

These rules can be set in the nessusd.rules file, on a per user basis or supplied by the end-user (as this is currently the case in Nessus 3.0).

New command 'nessuscmd'

The nessuscmd program (whose name might change -- suggestions are welcome) is a simple utility designed to perform a quick scan of a host or network for a small set of plugin IDs. For instance, if you want to scan your local subnet to determine which hosts have a default SNMP community set, do:

/opt/nessus/bin/nessuscmd -i 10264 192.168.0.0/24

More info can be obtained by doing :

/opt/nessus/bin/nessuscmd -h

Astute readers should find some similarity between some of the switches of nessuscmd and nmap.

Improved NASL engine

New functions

A few new functions have been added, in particular a plugin may now reduce the selected set of plugins while the scan is running. For instance, one may want to make sure that if the remote host is considered as being sensitive (ie: it's the payroll db server, a SCADA device, etc...) then one wants to programatically disable all plugins except one family or two which are known not to have any side effect. The functions to manage the plugin selection are :

• disable_all_plugins()
• enable_plugin_family(<name>)
• disable_plugin_family(<name>)
• enable_plugin_id(<id>)
• disable_plugin_id(<id>)

Note that a script can only reduce the set of selected plugins. If you do a scan with only the plugin #12345 being enabled, you can't have it enable plugins which were selected by the end user. However, you could do a plugin like :

if ( remote_host_is_the_payroll_server() )
{
  # Only audit the MSFT bulletins against the remote host

  disable_all_plugins(); # First : disable every other plugin
  enable_plugin_family("Windows : Microsoft Bulletins");
}

Support for pre-compiled libraries

NASL 3.2 supports the inclusion of pre-compiled libraries (we call this .nlib files). From within a NASL script, one can import a .nlib file by doing :

import("libName.nlib");

The only .nlib file available at this time is our WMI library. More information about performing WMI audits of Windows hosts with this library is available at http://cgi.tenablesecurity.com/tenable/WMI.html Tenable has also previously blogged about utilizing WMI audits for vulnerability scans here.

Nessus Program Easy-update

It's now very easy to upgrade your Nessus installation to the newest version of the engine. Simply make sure you are registered and type : /opt/nessus/sbin/nessus-update and Nessus will update itself. This feature is currently supported in Linux and FreeBSD, but not Solaris yet.

Miscellaneous Features

Scan pausing is now supported (with the command-line client, put the client in background by doing ctrl-Z to pause the scan and type 'fg' to resume it. GUI support will follow soon). Note that if you disconnect from nessusd while a scan is paused, the scan will be lost.

If a tested host is disconnected in the middle of a scan, nessusd should detect it and stop scanning that particular system (and tell you about it in the nessusd.messages logs).

Feedback

Please send your feedback, crash dumps, suggestions and complaints directly to Tenable's Director of Research, Renaud Deraison.

Tenable Network Security has recently added the ability to query remote Windows systems via the Windows Management Instrumentation (WMI) protocol. This allows a credentialed Nessus 3 scan to perform some very advanced configuration audits of Windows systems. This blog entry discusses WMI, the initial checks developed by Tenable and how this can impact consultants and enterprise users of Nessus and the Security Center.

What is WMI?

WMI is a kernel level instrumentation technology for Windows. It allows  remote applications to query Windows systems for performance and configuration information. It also allows remote applications to set configuration data. The types of data that can be remotely queried and modified include:

• Publishing kernel instrumentation
• Configuring device settings
• Providing kernel-side event notification
• Publishing custom data
• Allowing administrators to set data security
• Accessing instrumentation by way of WMI

For more information about WMI, please visit Microsoft's web site on the technology.

Initial Set of Nessus Plugins

Tenable's Research team has published seven new plugins which make use of WMI queries. These plugins are listed here:

• #24269 WMI Available - Checks that a WMI query can be performed to the scanned Windows system.
• #24270 Computer Manufacturer Information - Obtains the specific make and model of the scanned device such as "Manufacturer : Dell Computer Corporation" and "Computer Model : Dimension 8300".
• #24271 SMB share files enumerated (via WMI) - This lists all remote files on the scanned server and is much faster than performing a similar query through SMB.
• #24272 Network Interface Enumeration - This plugin lists all network interfaces on the system and their IP addresses associated with them.
• #24273 Remote Copy of Windows Not Activated - Detects installed versions of Microsoft that have not been activated and will become disabled.
• #24272 USB Drives Enumeration - Lists all USB storage drives and their names.
• #24282 DEP is Disabled - The Data Execution Prevention technology that helps mitigate buffer overflows and system crashes is disabled.

Below is an example screen shot of a USB Drive audit from an OS X version of Nessus:

Availability

Tenable plans on developing many more checks of these types in the near future. These checks have been currently made available to Direct Feed customers and Registered Feed users will obtain them in seven days.

Nessus 3 is required to run these checks. It does not work with Nessus 2. If your organization is using a Managed Security Provider or Network Access Control product which makes use of Nessus 2, please ensure that they have licensed Nessus 3 from Tenable Network Security for their solution.

To the best of our knowledge, Tenable is the first company to ship a platform independent WMI implementation which does not require anything to be installed on the remote Windows system.

Couldn't Nessus do this before?

The remote patch auditing and configuration ability of Nessus 3 (for both patch auditing and configuration compliance checks) was performed over SMB. This allowed Tenable researchers to query patch information, open files, open registry settings and check the security settings of these devices. Through SMB alone though, there were many types of Windows information relevant to security that could not be queried. Tenable's implementation of WMI for Nessus 3 opens up many new types of checks.

Why is this important for consultants and enterprise users of Nessus?

The seven plugins released today should be very useful to both Security Center enterprise customers as well as consultants who scan large Windows networks. For Security Center users, considering the following possibilities:

• The data obtained by the make and manufacturer can be used to create dynamic asset lists. This can allow you to create asset lists based on specific manufacturer models, laptop vendors and so on.
  
• Network interface enumeration can be used to find Windows computers that have IP addresses not on your local network. This could allow you to also find a node that has both a wired connection with a valid IP and a wireless connection which has an unauthorized IP.
• Listing where all USB drives are located within an organization can also be of great use, especially in the hunt for sensitive data located in the wrong places or wrong organizations.

If you are a consultant or service provider and offer remote scans for Windows devices, these new checks can add great value to the gathered results. If your customers are asking for this sort of technology, you should also consider adding Nessus compliance checks to the offering, which is available through the Nessus Direct Feed.

This point release provides fixes for multiple minor issues with Nessus 3.0.4. The fixes include:

• Faster startup time, especially on laptops
• Improved the performance of the SYN port scanner
• Fixed a memory leak in the Mac OS X client
• Vista compatibility improved
• Various minor bugs fixed in the NASL engine
• Better chasing of zombie processes

Platform specific changes include:

• Windows : Improved Vista compatibility
• Mac OS X : fixed a memory leak in the client
• Mac OS X : fixed the way plugin preferences are processed (some prefs would not be displayed)
• Red Hat/Fedora : The priority of the nessusd startup script is now at 98 instead of 90, so that it starts later in the boot process
• On Debian, the dependencies of the Nessus package have been fixed to reflect the need of libssl0.9.7

Other changes of interest :

• nessusd.conf now accepts the option "listen_address" which can be used to bind the nessusd daemon to a specific port (just like 'nessusd -a' does). Adding 'listen_address 127.0.0.1" in nessusd.conf will force nessusd to only listen on the loopback interface (thanks to Martin Mačok for suggesting this)
• If you write your own plugins you'll notice that the changes you make are not reflected in the scan itself until the next plugin update. To speed up the startup time of nessusd, we now compare the timestamp of the plugins db with the time of the last update. This avoids inspecting thousands of files at startup. To force nessusd to inspect the timestamp of every plugin at startup, simply start it with the '-t' switch (as in 'nessusd -t -D').

Other minor fixes :

• nessus-update-plugins now displays a proper error message when plugins.nessus.org is unreachable
• 'nessus -i report.nbe -o report.html' would sometime crash when converting a malformed .nbe file to another format
• In NASL, shared_socket_acquire() now returns 0 on error, not -1

Nessus users should upgrade to Nessus 3.0.5 and obtain it directly from http://www.nessus.org. Tenable recommends that all Nessus 3 users perform the upgrade.

Many organizations have IT configuration polices that require CDs and USB drives to be disabled. This blog entry discusses a simple way to use a Nessus 3 .audit file to test a Windows 2003 server for the correct registry settings that disable "AutoRun" of programs on CDs as well as disables USB drives.

Windows 2003 Registry Settings

On Windows 2003 servers, the following registry setting controls "AutoRun" for CD drives:

HKLM\SYSTEM\CurrentControlSet\Services\Cdrom

If the item "AutoRun" is set to zero, then the system won't run CDs when they are inserted into the server. Below is a screen shot, with the "AutoRun" item circled, of a Windows 2003 server's registry settings using the regedit.exe tool:

To disable USB drives, the following registry setting should be set to a value of "4":

HKLM\SYSTEM\CurrentControlSet\Services\UsbStor\start=4

According to Microsoft Knowledge Base #823732, systems that have this setting in place will have their USB drives completely disabled. Please note that this registry setting only applies to USB storage devices that are being installed and have no effect on devices already attached to a server.

Example .audit File

The following is a self-contained .audit file which tests the registry settings to have CD-ROM "AutoRun" and USB drives disabled:

<check_type: "Windows">
<group_policy: "Audits Windows 2003 Systems for AutoRun and USB storage devices being disabled">

<custom_item>
        type: REGISTRY_SETTING
        description: "CD AutoRun Disabled"
        value_type: POLICY_DWORD
        value_data: 0
        reg_key: "HKLM\SYSTEM\CurrentControlSet\Services\Cdrom"
        reg_item: "AutoRun"
        reg_type: REG_DWORD
</item>

<custom_item>
       type: REGISTRY_SETTING
       description: "USB Storage Devices Are disabled"
       value_type: POLICY_DWORD 
       value_data: 4
       reg_key: "HKLM\SYSTEM\CurrentControlSet\Services\UsbStor"
       reg_item: "start"
       reg_type: REG_DWORD
</item>

</group_policy>
</check_type>

Click below to download the example .audit file:

Download autorun-disabled.audit

Using this .audit file with Nessus 3 For Windows

Nessus 3 Direct Feed subscribers can save the above .audit file to their local computer. They should then create a scan policy which makes use of this .audit file and has the appropriate credentials to read the registry of the audited systems.

If an existing scan policy with the right credentials is available, consider adding this .audit file as a second or third policy. Each scan policy can have up to 5 separate UNIX and Windows .audit files.

Below is a screen shot of an example report generated by the above .audit file from a test Windows 2003 server.

Vulnerability ID #21157 is the value assigned to all Windows compliance audit results. In the results, it can be seen that CD-ROM "AutoRun" has indeed been disabled, but USB storage devices are enabled with a value of "3".

Using this .audit file with the Security Center

Security Center users should have their administrator save the .audit file to the /opt/sc3/admin/nasl directory, and then restart the Security Center to ensure it gets pushed out to all of the managed Nessus scanners.

To make use of the new .audit file, either a new scanning policy should be created with the proper Windows credentials that makes use of the new .audit file, or this new .audit file should be added to an existing scanning policy. Like Nessus 3, scanning policies in the Security Center can also use multiple .audit files.

Below is a screen shot of the results of a scan against the same Windows 2003 server we tested above with Nessus 3.

Since these compliance results have been imported into the Security Center, they have been given unique IDs of #60186 and #60187. The Security Center interprets Nessus plugin IDs #21156 (UNIX) and #21157 (Windows)  as "compliance" IDs and re-maps these to IDs greater than 65000. This allows for unique reporting, ticketing, dynamic asset list creation and tracking for unique compliance issues. 

For More Information

Tenable has placed several dozen .audit files online which can perform comprehensive audits of UNIX and Windows systems. These polices are derived from the United States CERT, NIST and NSA organization's guides for locking down UNIX and Windows servers. Documentation and tools are also located at that site which can be used to create your own policies. Compliance audits with Nessus 3 are available to all Direct Feed subscribers and Security Center users.

On January 3rd, 2007, Tenable's research group released a NASL script (plugin #23971, currently available to Direct Feed and Security Center customers) to test if a scanned host is on a different logical network, but also on the same physical network. If this is the case, your network may have a potential security issue, as IP based access control filtering may not be effective. This blog entry discusses what the plugin does, why this is important and comments on general firewall and access control auditing with Tenable solutions. 

What the Script Does

The NASL script attempts a layer two "ping" of target IP addresses that are not part of the local IP network (i.e., outside of the local netmask). If a response is received, then both devices share the same switching fabric and the potential security issue is reported as an informational vulnerability.

Why this is Important

If you are using some sort of routing, firewalling or proxy filtering to segment IP based networks, then an attacker may be able to create a virtual network interface and then connect directly to the target network.

For example, perhaps your organization has a DMZ with some "important" servers in them such as mail, web, .etc. and you also have a public network. There may be IP access control rules separating  the two networks. If these devices connect to a common switch though, a user in the public network may be able to configure a virtual interface with an IP address inside of the DMZ and directly access those servers. This could bypass security completely.

Consider a simpler example such as a web application that has a simple "IP based" form of access control, and requires remote users to originate from the 192.168.20.0/24 subnet. If there was one large collision domain and a remote host could perform an Ethernet "ping" of this application, they may also be able to create a virtual  interface with an IP such as 192.168.20.3 and connect to the application.

The solution is to use separate VLANs to segment layer 2 (Ethernet) traffic, or even multiple physical switches separated by routers or firewalls.

Analyzing the Results of the Plugin

Keep in mind several things when analyzing these results:

• The test is occurring from the Nessus scanner. If you've provisioned your scanner with multiple interfaces and/or on multiple VLANs, then there might not be such an issue. However, if you've put the Nessus scanner in the HR network, and it can ARP ping hosts in the DMZ, you likely have a layer 2 security issue.
• If you have MAC filtering in place on your switches, this is better than no filtering at all, but a user may be able to create a virtual interface with a MAC address that is either valid or not explicitly filtered.
• Even if you have a firewall or some sort of IP filtering in place, if packets can be sent at layer two, you may be able to completely bypass the firewall.
• The script basically says, the target is on a different IP network than I am, but I can also do an Ethernet ping to him. Keep in mind that some types of firewalls, proxies, NAC devices, security routers/switches and even honeypots may "respond" on behalf of their target.

Auditing Firewalls and ACL Polices In General

Tenable recommends a few different strategies for monitoring the security of IP based access control schemes.

• Use distributed Nessus scanners that both scan "from the outside" as well as between political groups and organizations. If you conduct this sort of monitoring routinely, you can find changes in firewall policies when new ports become open, and you can also identify trust relationships between organizations within your network.
• Continuous passive network monitoring, such as with the Passive Vulnerability Scanner, can identify all active hosts, hosts with open ports, hosts browsing on the Internet and internal trust relationships. By analyzing this data, a good understanding of the "real" set of access control policies can be determined.
• Conducting log analysis of the actual firewall logs can be used to look for changes in the actual firewall configurations and lack of logs for expected and authorized traffic. Tenable's Log Correlation Engine supports this sort of analysis.      

Obtaining This Plugin

This plugin will be available to Registered Feed users January 10. It is currently available to Direct Feed and Security Center users.

Tenable recently increased the flexibility of performing configuration assessments of Windows  access control lists (ACLs) with the Nessus compliance checks.

Previously, an ACL policy could only be built with exact understanding if it were "inherited" or "not inherited". For large numbers of checks, it might not make any difference if an ACL were inherited from someplace else or not, just that the actual ACL was correct.

For example, to perform a file ACL test without regard if it is "inherited" or "not inherited", use the phrase "not used" with the "acl_inheritance" keyword. Below is an example .audit file which performs a file ACL test without regard if the policy were inherited or not:

<file_acl: "ASU1">

<user: "Administrators">
  acl_inheritance: "not used"
  acl_apply: "This folder, subfolders and files"
  acl_allow: "Full Control"
</user>
<user: "System">
  acl_inheritance: "not used"
  acl_apply: "This folder, subfolders and files"
  acl_allow: "Full Control"
</user>

<user: "Users">
  acl_inheritance: "not used"
  acl_apply: "this folder only"
  acl_allow: "list folder / read data" | "read attributes" | 
             "read extended attributes" | "create files / write data" |  
             "create folders / append data" | "write attributes" |  
             "write extended attributes" | "read permissions" 
</user>
</acl>

These changes effect the acl_inheritance  keyword for auditing ACLs of files, registry entries and services.   

Obtaining These Checks

Tenable customers who manage their Nessus scanners with a Direct Feed subscription or the Security Center have already received this update. If your organization is not connected to the Internet or performing regular updates, the change was made available on December 29th.

Tenable recently added a credentialed Windows check (Nessus ID #23910) to find systems that have been infected by certain viruses. The check considers the contents of the file:

SYSTEM32\Drivers\etc\HOSTS

and sees if it has been manipulated to prevent virus updates. A common virus technique (such as in MyDoom, Bagel and their variants) is to disable a computer's ability to update its anti-virus signatures once it has been compromised. Typical anti-virus software performs a DNS lookup to find the update server where new signatures are available.

By adding alternate IP addresses (usually 0.0.0.0) for common update sources such as Symantec, Sophos, Microsoft, Kaspersky and so on, a virus can prevent anti-virus software from updating itself. Tenable has also seen viruses place destinations for anti-spyware solutions as well.

If Anti-Virus Software is there in the first place, why does it fail?

The answer is pretty simple: zero-day (or recent vulnerability announcements) exploits and the desire to maintain control over a compromised system. Worm writers who use a new exploit can compromise many systems before the anti-virus vendors develop signatures for the files in motion or network attack vectors.

A savvy worm writer will "know" that if their Trojan or worm is popular or successful enough, it will get the attention of the anti-virus community and signatures will be developed and deployed to target it. With this in mind, a worm writer who disables or neuters an anti-virus solution can keep control of the infected host well after the anti-virus rules have been updated.

Other Nessus Anti-Virus Checks

There are several other anti-virus and Trojan/backdoor detection plugins available for Nessus. Here is a quick overview:

• For most commercial anti-virus solutions, a Nessus local check can be used to determine if the system is running with the latest available updates, or if the solution is installed but disabled or not running.
• For popular viruses, Tenable maintains a set of "quick check" local tests in plugin #11329. This is not a comprehensive list of the 1000s of various virus and Trojan variants, but does check for several dozen very popular viruses.
• For many popular worms that have well known network backdoors, Tenable does write plugins to scan for and discover these. For example, the Sasser Virus Detection plugin (Nessus ID #12219) connects to various ports to look for an FTP service.

Being Proactive and Vigilant

Tenable offers a variety of solutions to extend a typical Nessus deployment to monitor enterprise networks for worms, virus outbreaks and  even network anomalies:

Besides discovering most of your server and client vulnerabilities simply by watching network traffic, Tenable's Passive Vulnerability Scanner discovers when new ports become open, can identify the presence (or lack thereof) of several anti-virus solutions and can also alert when an internal host begins port scanning.

When fed netflow logs, firewall logs or using the Tenable "TNM" agent for direct network traffic analysis, the Log Correlation Engine can identify hosts infected with spyware, malware, botnets and trojans. This is done primarily through cross referencing several popular black lists, as well as considering anomalies such as "Crowd Surges" of samples of the network population to suspicious locations.

Tenable's Nessus 3 scanner can also perform agent-less host-based configuration audits. These tests can consider the configuration a specific asset class (server, desktop, web server, .etc) should have and look for discrepancies. For example, Nessus can test that the content of the "HOSTS" file contains a "corporate" standard, that certain base configurations are met and that specific processes are indeed running.

Obtaining These Checks and Thanks

Tenable would like to thank both the folks at Sensepost as well as Michel Arboi for suggesting this sort of check. The check is currently available in the Direct Feed. All Security Center and Direct Feed users have access to this plugin at this time.

Tenable has released 32 plugins for Nessus 3 which specifically test SCADA devices. These plugins were the result of a four month research contract between Tenable Network Security and Digital Bond. This blog entry details how to obtain the plugins, strategies for using them with Nessus and strategies for using them in concert with Tenable products such as the Security Center and Passive Vulnerability Scanner.

Availability and Compatibility

All Direct Feed and Security Center users will receive these plugins through a plugin update. The SCADA plugins are only available to Tenable Direct Feed or Security Center customers. Other compatibility notes to consider:

• The plugins are designed to work only with Nessus 3
• Some of the plugins require local checks, but many are network probes
• Nessus 3 Windows users will see the new "SCADA" family after they update their plugins.
• If you use the Nessus 3 OS X client, the UNIX GTK client or NessusWX, you will see the SCADA plugins and family after you connect to a Nessus 3 scanner subscribed to the Direct Feed or being managed by the Security Center.

Tenable customers should contact our support group at Tenable if they require assistance obtaining these plugins. Below are screen shots of how the plugins look under the Nessus 3 for Windows GUI, the Nessus 3 OS X GUI and NessusWX:

SCADA Plugin Functionality

The plugins reside in their own family named "SCADA". Each plugin is listed below with a short description:

• Areva/Alstom Energy Management System - Identifies if the remote host is running an Areva/Alstom EMS Server.
• DNP3 Binary Inputs Access - Read binary inputs using DNP3 from RTU/IED.
• DNP3 Link Layer Addressing - Determines link layer address of DNP3 station by iterating through likely values.
• DNP3 Unsolicited Messaging - Determines whether the DNP3 outstation supports unsolicited responses.
• ICCP/COTP Protocol - COTP (ISO 7073) is running on the host and may be part of an ICCP server, MMS application, or substation automation device that uses IEC61850/UCA.
• ICCP/COTP TSAP Addressing - Determines a Connection Oriented Transport Protocol (COTP) Transport Service Access Points (TSAP) value on an ICCP server by trying possible values.
• LiveData ICCP Server - Identifies hosts running a LiveData ICCP server.
• Matrikon OPC Explorer - Identifies hosts running Matrikon's OPC Explorer tool. These hosts may also have additional diagnostic tools and trust relationships.
• Matrikon OPC Server for ControlLogix - Identifies hosts running a Matrikon OPC Server for Allen-Bradley ControlLogix PLC.
• Matrikon OPC Server for Modbus - Identifies hosts running a Matrikon OPC Server for Modbus devices and used to access data from PLCs, RTUs, and IEDs. OPC servers are commonly used in SCADA and DCS systems to exchange data between different vendor systems and disparate applications.
• Modbus/TCP Coil Access - Modbus uses a function code of 1 to read "coils " in a Modbus slave. Coils represent binary output settings and are typically mapped to actuators. The ability to read coils may help an attacker profile a system and identify ranges of registers to alter via a "write coil" message.
• Modbus/TCP Discrete Input Access - The Modbus protocol function code of 2 reads discrete inputs from Modbus slaves. The ability to read discrete inputs may help an attacker profile a system.
• Modicon Modbus/TCP Programming Function Code Access - Finds hosts with the proprietary Modbus/TCP function code 126 active. An attacker that is able to gain network access to devices like this may be able to reprogram PLC logic or otherwise impact the integrity of physical processes.
• Modicon PLC CPU Type - Uses an SNMP Get Request to obtain the Model Information of a Modicon PLC.
• Modicon PLC Default FTP Password - Checks for the default FTP username and passwords on a Modicon PLC.
• Modicon PLC Embedded HTTP Server - Finds Modicon PLCs running an embedded HTTP server used for configuration or monitoring.
• Modicon PLC HTTP Server Default Username/Password - Tests HTTP servers on Modicon PLCs for the default user name and password.
• Modicon PLC IO Scan Status - Uses an SNMP Get Request to obtain the scan status of a Modicon PLC.
• Modicon PLC Modbus Slave Mode - Uses an SNMP Get Request to obtain the Modbus mode. The Modbus mode is either direct, gateway, unit or some combination of these three types. The Modbus mode could help an attacker determine the type of attack necessary against the PLC.
• Modicon PLC Telnet Server - Tests Modicon PLC Telnet servers for the default user name and password.
• Modicon PLC Web Password Status - Uses an SNMP Get Request to obtain the Web Password Status of a Modicon PLC.
• National Instruments Lookout - Identifies hosts running the National Instruments Lookout Application.
• OPC DA Server - Identifies hosts running the OPC Data Access Server.
• OPC Detection - Finds hosts with OPC application components installed.
• OPC HDA Server - Identifies hosts running an OPC Historical Data Access Server.
• Siemens S7-SCL - Identifies hosts that contain Siemens S7-SCL Development Tool(s).
• Siemens SIMATIC PDM - Identifies hosts running the Siemens SIMATIC PCS 7 PDM Application.
• Siemens-Telegyr ICCP Gateway - Identifies hosts running a Siemens Telegyr ICCP Gateway server.
• Sisco OSI/ICCP Stack - Identifies hosts running a Sisco OSI/ICCP stack, and most likely acting as an ICCP server.
• Sisco OSI Stack Malformed Packet Vulnerability - Identifies hosts running a version of the Sisco OSI stack that can be crashed by a malformed packet.
• Tamarack IEC 61850 Server - Identifies hosts that may be running an IEC 61850 server developed by Tamarack Consulting, Inc.
• Telvent OASyS System - Identifies hosts running a Telvent OASyS Server.

Complementary to the current Passive Vulnerability Scanner SCADA plugins

Tenable customers who have also implemented the Passive Vulnerability Scanner (PVS) can now perform both active and passive SCADA network monitoring. Similar SCADA plugins for the PVS have been available since mid-2006. These offer no impact to the monitored network and effectively identify all devices which speak Modbus, ICCP and DNP3.

Organizations can tailor their vulnerability monitoring programs by using a combination of active SCADA scanning with these new Nessus plugins and passive monitoring with the PVS. Many organizations are required to perform annual vulnerability scans, which must be scheduled to avoid
impacting the production network. Using the PVS throughout the year meets the requirement for scanning, without impacting the network.

SCADA Device Active Scanning Strategies

As with all vulnerability scanning of devices which control physical equipment, consider the following strategies:

• If you have a SCADA test lab, start scanning those devices to identify any potential impact.
• When scanning operational SCADA devices, ensure that a second device is available for "fail over" and also ensure that the device operators are informed of the scheduled scanning.
• If you have access to data from a Passive Vulnerability Scanner, consider tailoring your scan to more robust device such as operating systems which were produced in the last five years.
• For configuring Nessus scans to be "safe", make sure scan polices have "safe checks" enabled and "thorough tests" disabled. Tenable has previously blogged about "safe checks" usage for Nessus.
  

For more strategies to consider for scanning SCADA networks with Nessus and these new SCADA plugins, Tenable recommends reading a white paper from Digital Bond entitled "Scanning Control Systems".

Working with the Security Center

Tenable customers who use the Security Center to manage one or more Nessus scanners in a SCADA environment should consider the following strategies:

• The new SCADA plugins will readily produce data that can be leveraged into dynamic asset lists. This can help create various lists of devices by active protocol (ICCP, DNP3, .etc) as well as function or even "Area of Responsibility".
• For each asset list, a separate vulnerability analysis can be conducted. Separate asset types will likely have different "top 10" vulnerabilities or configuration issues.
• Once separate asset lists are created, the components for each group can be displayed in three dimensions with the Tenable 3D Tool (demo video).
• Perhaps one of the most interesting types of analysis on "older" networks is to discover SCADA devices that are no longer needed, were failed to be decommissioned or deployed in locations that are not protected. 
• For NERC compliance, this process can help make sure the list of "Critical Cyber-Security Assets" is accurate and does not include too many hosts or ignores others.
• If intrusion detection events or the Log Correlation Engine is also in use, an event analysis for security, compliance and even network management issues can be conducted.

For More Information

Tenable recommends the following resources for learning more about SCADA security monitoring:

• Digital Bond blog
• Tenable White Paper: Protecting Critical Infrastructure (free download)
• Tenable White Paper: Real-Time Compliance Monitoring (covers NERC regulations. Contact sales to request a copy)

I'd also like to recommend the S4 conference (PDF brochure) coming up in January of 2007 in Miami. This is a technical conference and covers a wide variety of SCADA security topics.

If you are performing credentialed patch audits with Nessus, you can also create an inventory of installed software on each of your UNIX and Windows hosts. This blog post will review how Nessus can perform these tasks and what you can do with the results.

Finding Software on UNIX and Windows Systems

For Windows servers, Nessus plugin #20811 will enumerate all of the installed software by considering the "Uninstall" values set in the registry. This technique won't detect a simple executable present on a system, but it will find just about any piece of software that uses an installer. This particular check uses registry calls because it is intended to be generic. Other checks that Nessus performs to look for a variety of patch audits, questionable applications or specific versions of software consider both registry settings and analysis of local files such as DLLs. 

For auditing UNIX software, the default "command line" technique to enumerate managed applications is considered. Nessus plugin #22869 performs this task. For example, on Red Hat based systems, a list of RPMs is obtained through the use of the rpm command. This technique is quite fast and is intended to report just the applications that the OS is tracking. It won't enumerate software that was placed just as a binary or which was compiled natively on the system. Also, unlike Windows software enumeration many "applications" which were installed with the base OS will also be enumerated, creating very verbose lists of software.

Configuring a Nessus scan

Nessus scans should be configured for remote credentials for the target UNIX or Windows machines. For UNIX, this means an SSH account which can run commands such as "rpm". On Windows, this means an account that has access to the registry (although for full and reliable patch audits, Tenable recommends a domain account which can read files).

On Windows, plugin #20811 can be selected individually, or by enabling the entire "Windows" Nessus plugin group. For UNIX, plugin #22869 can also be run individually, but if you want to complement an existing patch audit, this plugin is part of the "Generic" plugin family.

Dynamic Asset Lists and Ad hoc Searches

If you are using the Security Center to manage multiple Nessus scanners or for sharing the scan results with different auditors and departments securely, the list of installed software can be very useful.

Below is a screen shot of a list of installed applications on a fairly bare Windows 2003 server:

A quick analysis of this will see that VNC 4.1.1 is installed and that it is the free version. Data like this can be very useful for a variety of tasks such as:

• verifying compliance with software licenses
• verifying compliance with corporate policy
• identifying potential vulnerable applications which aren't running
• identifying lack of required software

The Security Center can be used to quickly display or report all hosts that have certain types of software installed on them. If the software is Windows, type plugin ID #20811 into the plugin ID field of the Cumulative Database or Scan Results filter, and then in the "Search Vuln Text" field type a string which represents the software you are looking for. You might not know the exact string to search for unless you see it in a listing from a scan.

The Security Center can also be used to take this content and create a dynamic asset list of all systems that have (or don't have) specific installed software. In the image below is an example rule which combines plugin ID #20811 and a simple pattern search for "VNC Free Version 4.1.1".

This rule gets applied each time a scan is accomplished and creates a dynamic list based on the results. This means that every IP address that matched this criteria would be added to the list as shown below:

This is a list of vulnerability severities by asset group and the second to last group is our system with VNC 4.1.1 installed.

It might be more interesting to find servers that didn't have this installed. Since we have a regular expression engine available for pattern matching, a dynamic asset rule could be created with the following string:

20811:(?s)^((?!VNC Free Edition 4.1.1).)*$

In the Security Center dynamic asset rules interface, this would be entered as a "regex" type of match. This code matches strings which don't have the string "VNC Free Edition 4.1.1" in them. Under the Security Center's dynamic asset rules engine, we couple this with the specific Nessus ID of #20811. Writing the pattern with a preceding "20811:" string tells the engine to only apply the match to vulnerability data a host may have for just that particular ID. Also adding a generic match for plugin ID #20811 is an easy way of only listing Windows hosts for which we have software enumeration data. Otherwise, we'd have many matches for our Cisco routers, Linux servers and so on which didn't have this code in plugin #20811.

Conclusion

These software enumeration plugins can provide a great deal of information which is extremely useful for auditing remote hosts. Audits can help find illegal software, misconfigured hosts and can help identify classes of servers by technology or function.

For over a year now, Tenable has been including CVSS base scores in the plugins we write for Nessus as well as Passive Vulnerability Scanner (PVS) to give our customers an objective way to assess the risk of flaws those plugins test for. We've been calculating these scores in-house during the course of investigating vulnerabilities and how to test for them. Until recently, our efforts have been largely independent of NIST's own work in this area.

Since early November, though, Tenable has been using the CVSS scores that NIST calculates and includes in its National Vulnerability Database. We still calculate our own scores initially, as our plugins are often released at the same time -- or even slightly before -- CVE ids are issued. But a daily synchronization process reports differences and updates the plugins as necessary.

Nessus 3 users who have subscribed to the Direct Feed service can audit the configurations of many OSes, including OS X. This blog entry will show the basic configuration of an OS X device to allow auditing by Nessus 3.

Configuring Remote Auditing for OS X

The first step to auditing an OS X system with Nessus is to allow remote SSH access. To do this, as an administrator of the OS X system, under sharing, enable "Remote Login" as is shown below:

By default, your firewall settings should allow inbound SSH to the OS X system. If you've modified your firewall configuration to stop SSH or block certain IP addresses, this may effect your Nessus scanning.

Next you must create a user and configure it for use with Nessus certificates.

Note: Actually, Nessus supports usernames and passwords for SSH authentication, but this means you need the same username and password combination on your systems, so we recommend creation of shared SSH keys.

Add an "audit" account as shown below:

At the command line, copy the SSH public key you've created for your Nessus scanner into the audit account's home .ssh folder.

You will likely need to create the hidden .ssh directory as well as set the permissions of the directory as indicated in the "Nessus Credentials Checks for UNIX and Windows" paper.

Since we are on OS X, these commands need to be accomplished with administrator privileges which requires the sudo command.

Configuring Nessus 3 for Windows to Audit OS X

To then scan the OS X system, create a scan policy which takes advantage of the existing credentials, as well as specifies a UNIX compliance .audit file. Each Nessus client is slightly different, and below is a screen shot of how Nessus 3.0.4 can be configured to audit an OS X system:

Note that the SSH username (the username of "nesssus") for the OS X server has been specified as well as both the public and private SSH keys (which become blocked out once loaded). To configure a .audit file, obtain one from the "Nessus 3 Agent-less Compliance Checks" web site and download it to the system where your Nessus client is running.

Configuring the Security Center to audit OS X Systems

Under the Security Center, auditing an OS X system is no different than auditing another other UNIX system.

First, you need to create a vulnerability policy which specifies credentials for the target OS X system(s). Second, that same vulnerability policy should be configured with the desired .audit tests to be performed.

Note: The Security Center can also maintain separate credentials per asset group which overrides the credentials in the vulnerability policy.

After running a scan, OS X compliance results will look similar to the screenshots below:

Results Summary	Compliant Results	Non-compliant Results

Moving Forward

The National Security Agency has published a guide for hardening OS X systems. Tenable will be releasing a .audit file for Nessus 3 to perform configuration analysis specific to OS X servers. Since OS X is based on UNIX though, many of the current .audit files generate very good results.

If this sort of auditing is interesting to you, please feel free to contact Tenable's sales staff to inquire about the Direct Feed or the Security Center. Also, Tenable has also made a video demonstration of Nessus 3 performing configuration audits available to the public.

Tenable Network Security is pleased to announce the immediate availability of Nessus 3.0.4 which includes changes to the nessusd daemon, specific changes for Nessus 3 running on Windows, specific changes for Nessus 3 running on OS X and changes to the Nessus command line client.

Tenable has also released Nessus 2.2.9 and Nessus Client 1.0.0.

These releases can be obtained by visiting http://www.nessus.org/download/ for downloading.

This new release contains the following enhancements and fixes :

Nessus 3.0.4 daemon

• Processing the plugins after an update is faster
• Better detection and handling of corrupt db files
• It is now possible to use 'default' in a port range just like any other port (ie: '1,default,443,8080')
• Avoid a deadlock in the main process when waiting for a sub process to die
• nessus_tcp_scanner works much better when used over a slow network link
• nessus_tcp_scanner now offers some options accessible thru the GUI
• If 'log_whole_attack' is set to 'no' , do not print messages about shared sockets in the logs
• Fixed the 'on_exit()' nasl function
• Fixed 'nasl -k' which would sometimes not work properly
• Avoid doing some un-necessary system calls, thus resulting in a lower load during a scan (esp. on Mac OS X)
• Fixed a bug in ssh_func.inc which would prevent it from working against HP/UX
• Binaries for Fedora Core 6

Nessus 3.0.4 Command line client

• Logs much faster into a remote nessusd scanner
• Fixed a possible memory corruption issue when creating a list of plugins to launch
• Fixed a corruption of the .nessusrc files when receiving some plugin prefs ending by a space

Nessus 3.0.4 Mac OS X specific changes

• Opening and closing a session window would stop all on-going scans
• Creating a policy and defining it as 'shared' immediately saves the policies on disk

Nessus 3.0.4 Windows specific changes

• Not a beta any more
• Fixed file lock issues

Nessus 2.2.9 Daemon

• Fixed a bug in the PCAP handler which in turn fixes synscan.nes (thanks to Marcel <mkalracuesl (at) gmail.com>)
• Fixed a banner encoding problem in nessus_tcp_scanner and find_service
• Fixed a possible deadlock in synscan.nes
• Avoid a deadlock in the main process when waiting for a sub process to die
• nessus_tcp_scanner works much better when used over a slow network link
• nessus_tcp_scanner now offers some options accessible thru the GUI
• Fixed a bug in ssh_func.inc which would prevent it from working against HP/UX

Nessus 2.2.9 Client

• Fixed a possible memory corruption issue when creating a list of plugins to launch
• Fixed a corruption of the .nessusrc files when receiving some plugin prefs ending by a space

NessusClient 1.0.0 released

• Much faster to load
• Fixed various minor bug fixes
• Binaries for Fedora Core 6

A common question our support group receives from Direct Feed customers is how to limit Nessus probes to specific ports. This post will discuss the reasons Nessus sends packets to various ports and how scans can be configured to limit access to specific ports or ranges of ports.

Limiting The Port Scan

The first item someone should decide in an effort to minimize the ports touched by a Nessus scan is to enter in specific ports for scanning. Most Nessus clients have a default scan policy setting of "default". This causes the Nessus port scanner used to scan all TCP ports in the /etc/services file. Users can enter in more specific ranges and ports such as "21-80", "21,22,25,80" or "21-143,1000-2000,60000-60005". This will cause the port scanner to target just those ports during the port scan.

During the port scan, the Nessus TCP scanner will also use the ports involved to determine the round trip time for packets to the target host. If a small number of ports is used, the scanner may choose other ports to determine the RTT.

Choosing Host Enumeration

If an ICMP probe (a ping) is enabled to discover active hosts, then no specific ports are probed. However, if a "TCP Ping" is used to discover a host, then ports will be probed. Both options can be enabled and are not exclusive. It should also be noted that there is another host enumeration for "ARP pinging" which will find hosts on the local LAN.

Considering Un-scanned Ports Closed

After a host is discovered and the desired ports are scanned, Nessus will attempt to run the enabled plugins against the target. If a plugin runs which attempts to connect to a specific port and the "Consider Unscanned Ports Closed" setting is enabled, Nessus won't even run the plugin. However, if this setting isn't enabled, Nessus may start to probe ports that were not specified by the port scan.

Understanding UDP Port Probes

For port scanning, the UDP protocol is very unreliable. Nessus does not have a UDP port scan option and instead runs UDP plugins directly if they are enabled in a scan.

UDP is unreliable because if a port is open, the host is NOT supposed to send a response and if a port is closed, the host is supposed to return an "ICMP Port Unreachable" packet. Since UDP packets can be dropped or a host or network firewall can stop a packet, a scanner that does not get a response for a UDP probe can be fooled into thinking the port is open. Even for closed ports, if a network has implemented outbound ICMP filtering as a security measure, the scanner won't see the "ICMP Port Unreachable" messages.

Because of this, Nessus is designed to work directly with the applications that occur over UDP. Often these applications involve single packet queries and this is more efficient than scanning and then attempting to speak to the application. For example, rather than attempting scan for systems with port 111 open on UDP which is probably the RPC portmapper service, it is more efficient to simply send in the equivalent of the "rpcinfo -p" command and wait for a valid portmapper response.

Using Passive Technology

Tenable customers who have deployed a Passive Vulnerability Scanner (PVS) enjoy continuous monitoring of their network as well as some advantages over active scans. Since the PVS operates 24x7, it can see activity on the network that might not be present during an active scan. The PVS will also find what ports a host "browses" on. For example, if a web server is open on port 80 and 443, it might also browse the network on port 53 for DNS lookups and port 80 to reach out to the web and grab updates.

Tenable has received many requests to extend the API for the agent-less Nessus compliance checks. In response to our customers, we've added several new functions to the compliance plugins which are immediately available to all Security Center and Direct Feed users. The documentation for these new APIs has been updated here, and this post describes the new APIs available for UNIX and Windows configuration auditing.

For the Windows operating system, Nessus can now perform the following checks:

• FILE_CHECK - tests for the presence of a specific file
• REG_CHECK - tests for the presence of a specific registry entry
• FILE_CONTENT_CHECK - test for the presence of specific content in a given text file
• FILE_CONTENT_CHECK_NOT - test for the lack of presence of specific content in a given text file

For example, to test for the presence of a given file on Windows systems, consider the following:

<custom_item>
type       : FILE_CHECK
description: "Check the file win.ini exist"
value_type : POLICY_TEXT
value_data : "%SystemRoot%\win.ini"
file_option: MUST_EXIST
</item>

This text would cause Nessus 3 to search for the file win.ini under the %SystemRoot% directory and report a PASS (informational severity) if the file existed or a FAIL (severity reported as a hole) if it didn't exist.

In addition to these checks for Windows systems, the API for UNIX operating systems was extended to perform checks against the MD5 values of specific files. Here is an example setting:

<custom_item>
type       : FILE_CHECK
description: "/etc/passwd has the proper md5"
required   : YES
file       : "/etc/passwd"
md5        : "c1b38ca2f4656d91041b24b3fb762b7a"
</custom_item>

This tests the file /etc/passwd for a specific MD5 value and alerts if it changes.

Tenable will shortly begin to take advantage of these APIs in the next few updates and additions to the current set of compliance audit files available to customers. There were no changes to the existing APIs and none of the current audit files need to be modified or updated.