Clusterd is an open source application server attack toolkit. It automates the fingerprinting, reconnaissance, and exploitation phases of an application server attack.

Clusterd can be downloaded from the Github link below

https://github.com/hatriot/clusterd

The recommended way to install clusterd is to clone the Github repository using git as shown below.

git clone https://github.com/hatRiot/clusterd.git

Clusterd currently supports the following application server platforms:

  • JBoss
  • ColdFusion
  • WebLogic
  • Tomcat
  • Railo
  • Axis2
  • Glassfish

Clusterd in action

Following is the lab setup we are using in this article.

Attacking machine: Kali Linux with Clusterd installed (192.168.56.101)

Target machine: Windows 7 running Jboss with exposed JMX Console (192.168.56.102)

Information Gathering

The following figure shows a very basic scan using clusterd tool.

As we can see in the above figure, Clusterd performs checks to see the exact type and version of the target app server.

The following figure shows the matching fingerprints after completing the scan.

As we can see in the above figure, there are multiple matching fingerprints confirming that the target server is running JBoss 4.0

Additionally, we can specify the app server type using –a flag to limit the checks only to that specific app server. The following figure shows how we can scan a server with ColdFusion specific checks.

The above results are as expected since the target server is running JBoss but not ColdFusion.

Adding –fingerprint option to the above command with JBoss as the target has revealed the following. It shows additional flags that we can use against JBoss servers.

./clusterd –i 192.168.56.102 –a jboss –fingerprint

We can use –jb-info flag to retrieve JBoss information as shown in the following command.

./clusterd -i 192.168.56.102 –a jboss –jb-info

Let’s also try to retrieve the list of deployed applications. This can be done using the following command with –jb-list flag.

./clusterd –i 192.168.56.102 –a jboss –jb-list

As we can see in the above figure, we obtained the list of war files deployed.

Exploitation:

This section shows how we can use Clusterd to exploit vulnerable JBoss server.

Manually exploiting JBoss JMX Console:

Let’s first understand how we can exploit an exposed JMX Console without automated tools.

The following figure shows the JBoss server running on the target machine.

Clicking on “JMX Console” button in the above window will launch the JMX Console as shown below.

There are multiple ways to deploy a war file to upload a shell. We can use the following option to deploy a war file from a remote URL. First, search for “Scanner” in JMX Console and we should see the following.

Scrolling down the page will show us the following where we can specify the URL of the war file. In our case, it is a war file with JSP shell hosted on Kali Linux’s webserver.

Click “Invoke” and you should see the following message showing that deployment is a success.

Now, we can browse the following URL to access our shell as shown below.

We can now run any system commands using this shell. The following figure shows the output of “ipconfig” command.

Exploitation using Clusterd – 1:

We can automatically deploy a shell on the remote server using Clusterd using –deploy flag as shown below.

./clusterd –I 192.168.56.102 –a jboss –deploy /var/www/cmd.war

/var/www/cmd.war is the location of the war file with JSP shell.

As you can see in the above figure, the shell has been successfully deployed.

Ethical Hacking Training – Resources (InfoSec)

Exploitation using Clusterd – 2:

The target Jboss server is also vulnerable to Verb Tampering(CVE-2010-0738) attack where security restrictions are enabled only for “GET” and “POST” methods. Any other HTTP method such as HEAD if supported by the server will be not restricted.

Running the following command will deploy our shell on the target server.

./clusterd –i 192.168.56.102 –a jboss –verb-tamper /var/www/cmd.war

/var/www/cmd.war is the location of the war file with JSP shell.

The shell has been deployed in this case too.

We can now access this shell and run commands as shown below.