Exploitation and gaining access

To gain access to the target, we need to copy this exploit into Metasploit. However, copying external exploits directly to Metasploit's exploit directory is highly discouraged and bad practice since you will lose the modules on every update. It's better to keep external modules in a generalized directory rather than Metasploit's modules directory. However, the best possible way to keep the modules is to create a similar directory structure elsewhere on the system and load it using the loadpath command. Let's copy the found module to some directory:

Let's create the directory structure, as shown in the following screenshot:

We can see that we created a Metasploit-friendly structure in the MyModules folder which is modules/exploits/nipun, and moved the exploit into the directory as well. Let's load this structure into Metasploit as follows:

We have successfully loaded the exploit into Metasploit. Let's use the module, as shown in the following screenshot:

The module requires us to set the address of the remote host, remote port, and the path to the PhpCollab application. Since the path (TARGETURI) and the remote port (RPORT) are already set, let's set RHOST to the IP address of the target and issue the exploit command:

Voila! We got access to the system. Let's make use of some of the basic post-exploitation commands and analyze the output, as shown in the following screenshot:

As we can see in the preceding screenshot, running the sysinfo command harvests the system's information such as computer name, OS, architecture, which is the 64-bit version, and the Meterpreter version, which is a PHP-based Meterpreter. Let's drop into a system shell on the compromised host using the shell command, as shown in the following screenshot:

We can see that as soon as we dropped into a system shell, running commands such as id provides us with the input that our current user is using, www-data which means that to gain complete control of this system, we require root privileges. Additionally, issuing the lsb_release -a command outputs the OS version with the exact release and codename. Let's take a note of it as it would be required in gaining root access to the system. However, before we move on to the rooting part, let's gain some of the basic information from the system, such as the current process ID using the getpid command, the current user ID using the getuid command, the uuid for the unique user identifier, and the machine_id, which is the identifier to the compromised machine. Let's run all of the commands we just discussed and analyze the output:

The amount of information we got is pretty straightforward. We have the ID of the current process our Meterpreter is sitting in, we have the user ID, UUID, and the machine ID. However, an important thing to take note of here is that our access is PHP Meterpreter-based and the limitation of the PHP Meterpreter is that we can't run privileged commands which can easily be provided by more concrete binary Meterpreter shells such as reverse TCP. First, let's escalate us onto a more concrete shell to gain a better level of access to the target. We will make use of the msfvenom command to create a malicious payload; we will then upload it to the target system and execute it. Let's get started:

Since our compromised host is running on a 64-bit architecture, we will use the 64-bit version of the Meterpreter, as shown in the preceding screenshot. MSFvenom generates robust payloads based on our requirements. We have specified the payload using the -p switch, and it is none other than linux/x64/meterpreter/reverse_tcp. This payload is the 64-bit Linux compatible Meterpreter payload which, once executed on the compromised system, will connect back to our listener and will provide us with access to the machine. Since the payload has to connect back to us, it should know where to connect to. We specify the LHOST and LPORT options for this very reason, where LHOST serves as our IP address where our listener is running, and LPORT specifies the port for the listener. We are going to use the payload on a Linux machine. Therefore, we specify the format (-f) to be elf, which is the default executable binary format for Linux-based operating systems. The -b option is used to specify the bad characters which may encounter problems in the communication and may break the shellcode. More information on bad characters and their evasion will follow in the upcoming chapters. Finally, we write the payload to the reverse_connect.elf file.

Next, since we already have a PHP Meterpreter access on the machine, let's upload the newly created payload using the upload command, which is followed by the path of the payload, as shown in the preceding screenshot. We can verify the current path of the upload by issuing the pwd command, which signifies the current directory we are working with. The uploaded payload, once executed, will connect back to our system. However, we need something on the receiving end as well to handle the connections. Let's run a handler which will handle the incoming connections, as shown in the following screenshot:

We can see that we pushed our PHP Meterpreter session to the background using the background command. Let's use the exploit/multi/handler module and set the same payload, LHOST, and LPORT we used in reverse_connect.elf and run the module using the exploit command.

Exploiting the -j command starts the handler in background mode as a job and can handle multiple connections, all in the background.

We have successfully set up the handler. Next, we just need to execute the payload file on the target, as shown in the following screenshot:

We can see that we just dropped in a shell using the shell command. We checked the current working directory on the target using the pwd command. Next, we gave executable permissions to the payload file so we can execute it and finally, we ran the reverse_connect.elf executable in the background using the & identifier. The preceding screenshot shows that as soon as we run the executable, a new Meterpreter session gets opened to the target system. Using the sessions -i command, we can see that we now have two Meterpreters on the target:

However, x64/Linux Meterpreter is apparently a better choice over the PHP Meterpreter, and we will continue interacting with the system through this Meterpreter unless we gain a more privileged Meterpreter. However, if anything goes unplanned, we can switch access to the PHP Meterpreter and re-run this payload like we just did. An important point here is that no matter if we have got a better level of access type on the target, we are still a low privileged users, and we would like to change that. The Metasploit framework incorporates an excellent module called local_exploit_suggester, which aids privilege escalation. It has a built-in mechanism to check various kinds of local privilege escalation exploits and will suggest the best one to use on the target. We can load this module, as shown in the following screenshot:

We loaded the module using the use command followed by the absolute path of the module, which is post/multi/recon/local_exploit_suggester. Since we want to use this exploit on the target, we will naturally choose the better Meterpreter to route our checks. Hence, we set SESSION to 2 to route our check through SESSION 2, which is the identifier for x64/Linux Meterpreter. Let's run the module and analyze the output:

Simply amazing! We can see that the suggester module states that the overlayfs_priv_esc local exploit module from the exploit/linux directory can be used on the target to gain root access. However, I leave it as an exercise for you all to complete. Let's do it manually by downloading the local root exploit on the target, compiling and executing it to get root access on the target system. We can download the exploit from: https://www.exploit-db.com/exploits/37292. However, let's gather some of the details about this exploit in the next section.