PRP: JMX Exploitation through Deserialization

[h0ng10]

I would like to implement a new Detector for exploiting insecure JMX Instances through direct Java Deserialization, as described in this blog post from Code White.

Please note that Tsunami already has a JMX scanner module, however this module tries to use JMX internal functions, which are often blocked by IPS systems.

[maoning]

@h0ng10 Does this RCE works with remote JMX that has authentication configured? Could this technique replace the existing javax.management.loading.MLet based payload entirely or are they both needed for different configuration/versions of jmx and jvm?

[h0ng10]

Hello

From an attackers perspectice, the difference to the existing exploitation methods is the fact that no outgoing network connection for loading the code is required. The attack vector involves invocation of the "createMBean" method to create a new MBean instance on the server. Similar to the existing/implemented detection technique this will not work if authentication is enabled, even with valid credentials.

I tested the exploit using different JDKs and LTS versions (Java 8, 11, 17) all do work as expected.

If you have a demand on detections that work with enabled authentication, I could provide you implementations for the following issues:

• Exploiting deserialization over JMX RMI as described here, section "Deserialization on the JMX/MBean level".
• Exploiting deserialization in the JMX authentication process as described here.

Please note that later are variants of CVE-2016-3427, which require that the JMX service implements a custom JMX service. For example, this was the case in Apache Cassandra or Apache Karaf. Normal RMI based JMX services that simply use the Java command line arguments for service creation are no longer affected.

[maoning]

@h0ng10, thanks for the follow up. Correct me if I'm wrong, the initially reported exploit here can replace the current Tsunami JMX scanner module with more robust detection. If this is correct, you can go ahead updating the current JMX detector with the updated exploitation method.

My follow up questions is that for JMX server with no auth configured, does it always lead to serious exploits like RCE? I wonder if Tsunami should generate a finding if auth is not configured in the first place.

[h0ng10]

@maoning, you are right, it actually makes sense to "simplify" the plugin and always rate it as a security vulnerability, if a successful JMX connection is made without authentication, regardless if you can load the "javax.management.loading.MLet" MBean or not.

From my personal experience, I would always a JMX instance without authentication as a serious security issue, practical exploitation (gaining RCE) was sometimes prevented through network segmentation (blocking outgoing network connections that were required to load the additional Java code). With the new technique presented by Code White, this is no longer the case.

In this case, the lines 103 to 111 in the original plugin should be removed.

I am closing this issue and will provide a separate update (not marked as PRB).