Tenable Network Security

Root Is Just A Few Clicks Away

Default vendor logins and passwords are a common security issue that Nessus can scan for. Some of these default accounts can pose a serious security risk, depending on the type of access they permit. Nessus plugin id 35029 ("Dell Remote Access Controller Default password (calvin) for 'root' account") is a great example of this. It looks for a default username and password present on DRAC (Dell Remote Access Controller) devices which provide remote systems management for Dell servers.

Updated Conficker Detection Plugin Released

The Tenable research team has been steadily working on creating accurate checking for Conficker infected hosts. Over the weekend researchers Felix Leder and Tillmann Werner of the University at Bonn released details on how to detect Conficker using network-based checks. This checking methodology was used as a basis for Nessus plugin 36036 as well as the Nmap NSE script created for the same purpose.

nessuscmd Tip: Finding Open SMB File Shares

Penetration testers spend a lot of time searching for software vulnerabilities, such as buffer overflows or SQL injection. However, there are many other ways in which networks and systems can present vulnerabilities. Open SMB file shares can disclose sensitive information about an organization: I've found everything from student grades to bank account numbers using this technique. A great way to check for the presence of open SMB shares is to run a quick Nessus scan from the command line as follows:

Detecting Malware Distribution With Nessus

Many of today's latest worms and viruses are using interesting methods to propagate across the network. For example, the Conficker.A / Downadup worm sets up a web server for victims to connect to and download a copy of the malware. What I find interesting about this method is that no matter what request is made to the HTTP server, it responds with a Microsoft executable file. Nessus detects such an HTTP server with plugin id 35322 "HTTP Backdoor Detection":

Insecure Software Update Detection

Getting In The Middle

Un-patched and out-of-date software is a common attack vector for penetration testers and attackers alike. Applications such as Adobe Reader and Microsoft Office are popular targets due to their widespread use on Windows systems and user’s willingness to click on just about anything. They both have the ability to perform self-updates, similar to the operating system, but limited to one particular software package. However, what happens when the software update process itself is insecure? Enter a program called "evilgrade", which exploits this process to install software of an attacker's choosing. For this attack to succeed, the victim machine must be the victim of a Man-In-The-Middle (MITM) attack.

Detecting Base64 Encoded Authentication Requests

Passive Detection

Monitoring networks for potential security violations can uncover some interesting events and surprising aspects of applications.
Base64 encoding is used by many applications to "obscure" the password when it travels across the network. Base64 encoding does not implement a cryptographic algorithm to protect sensitive information, yet is often used in many networks and end-user applications.

Scanning Vulnerable Linux Distributions With Nessus

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.

Enhanced Operating System Identification with 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.

Nessus Virtual Appliance

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.

Using Nessus to call Nikto

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.