The name gives it away, Java Management Extensions (JMX) is a potentially juicy target for attack. One of the ways that a JMX service may be exposed is using Java Remote Method Invocation (RMI), which we can detect using nmap or my tool BaRMIe by looking for RMI registry services (by default on TCP port 1099) which expose an object named jmxrmi, or an object using the class javax.management.remote.rmi.RMIServer or javax.management.remote.rmi.RMIServerImpl_Stub.

Ignoring horrifically outdated/configured versions of Java where RMI is trivially exploitable with Metasploit, Braden Thomas (@drspringfield) did some research into exploiting the JMX RMI service back in 2013 and came up with a way to achieve remote code execution by instructing the service to load and execute code from a remote server that is under the attacker’s control. One of the recommended mitigations was to ensure that the JMX service is password protected.

Open Sesame!

When JMX is exposed over RMI, an object which uses one of the previously mentioned classes is bound to the RMI registry service. A connecting client will connect to the RMI registry service and request a reference to this object. The client then calls the newClient() method on this object to authenticate to the server and acquire an object that allows further interaction with the JMX service.

Let’s play spot the vulnerability.

Hint: it’s a well-deserved and long overdue entry in the OWASP Top 10 2017.

The JMX client supplies credentials to the JMX server in the form of a java.lang.Object, over RMI, which is based on Java’s built-in serialization format.

By calling RMIServer.newClient(Object) or RMIServerImpl_Stub.newClient(Object), an attacker can supply a specially crafted object to the JMX service in place of authentication credentials and potentially achieve remote code execution despite the service being password protected. Oops.

That’s So 2017…

I wrote an exploit for this issue and incorporated it into BaRMIe in September 2017, so why am I blogging about it now? Previously I just announced the exploit in a tweet and left it at that, but recently I was made aware of a JMX RMI deserialization vulnerability where a recommendation was being made to “secure” unpatched environments by setting a password on the JMX RMI service.

Well, if that unpatched environment has suitable gadgets available to it, such as that which was removed in the patch, then exploitation is still possible.

Stop deserializing everything!