Beanshooter - JMX Enumeration And Attacking Tool

Beanshooter is a command line tool written in Java, which helps to identify common vulnerabilities on JMX endpoints.

Introduction

JMX stands for Java Management Extensions and can be used to monitor and configure the Java Virtual Machine from remote. Applications like tomcat or JBoss are often installed together with a JMX instance, which enables server administrators to monitor and manage the corresponding application.

JMX uses so called MBeans for monitoring and configuration tasks. The JMX agent (sever, port) is basically just an interface, that handles remote connections and supports methods to communicate with the underlying MBean objects. The actual functionality is then implemented in the MBean itself and the JMX agent only relays input and output to the MBean object.

By default, JMX endpoints support a MBean with name MLet. This MBean can be used to deploy new MBeans on the JMX agent. The codebase for these new MBean objects can be obtained over the network e.g. in form of a HTTP request. Using the MLet feature, attackers with access to a JMX agent can easily deploy their own malicious MBean objects and compromise the underlying application server.

Beanshooter is a Proof-of-Concept tool, that can be used to identify vulnerable endpoints. It works for unauthenticated JMX endpoints as well as for authenticated ones (assumed you have valid credentials and sufficient permissions). Furthermore, it can be used to test other vulnerabilities like insecure Java Deserialization or CVE-2016-3427. Also connections using the JMXMP protocol are supported.

Installation

Beanshooter is a Maven project. This makes the installation a straight forward process and no manual installation of libraries should be required. First of all, make sure that you have maven installed on your system:

Then, clone the beanshooter project in a location of your choice and run mvn package inside of the projects folder.

Since the main purpose of beanshooter is the deployment of MBean objects, you need also a corresponding MBean. Theoretically you can deploy any MBean that fulfills the MBean specifications. However, this project does also provide a reference implementation, the tonka-bean. The tonka-bean is a separate maven project and you can compile it in the same way as you compiled beanshooter:

After maven has finished, you should find the executable .jar files in the target folders of the corresponding projects. Notice, that beanshooter needs to know where the tonka-bean.jar file is located. If you have placed beanshooter inside of your /opt folder, this should work automatically. Otherwise, you need to specify the path by using a configuration file or the corresponding command line options.

Beanshooter also supports autocompletion for bash. To take advantage of autocompletion, you need to have the completion-helpers project installed. If setup correctly, just copying the completion script to your ~/.bash_completion.d folder enables autocompletion.

Usage

For demonstration purposes, the project contains a docker image of an Apache Tomcat with JMX enabled and listening on port 9010. The corresponding docker-files can be found inside this repository and should enable you to practice the usage of beanshooter yourself.

The listing below shows the nmap output for the corresponding container.

This output can be misleading, as nmap is not able to detect the rmiregistry right away. This is because the rmiregistry on this server is configured for TLS usage, which breaks most of the common detection and enumeration tools. However, by looking at the high port that was successfully flagged as Java RMI, once can guess that one of the SSL ports has to be the rmiregistry. Using remote-method-guesser (one of the few tools that support SSL protected registry servers), one can verify that a JMX agent is running:

To verify unauthenticated access, you can use beanshooter with the status action. On an unprotected JMX endpoint, the output should look like this:

The status command shows that neither MLet nor the malicious MBean are registered on the JMX endpoint. You could now either deploy them one by one by using the deployMLet and deployMBean actions, or you can simply use deployAll to deploy both in one step. However, for deploying the malicious MBean the remote server needs to establish a HTTP connection to your listener. Therefore, you might need a firewall whitelisting and you have to use the corresponding --stager-host and --stager-port options of beanshooter to specify where your listener can be found. Lastly, make sure that the MBean you want to deploy can be found in the path that is specified in your configuration file (default is: /opt/beanshooter/tonka-bean/target/). If you use a custom MBean, you should also adopt the beanClass and objectName values.

Now one can use the status or ping command to verify that the malicious MBean was successfully deployed:

If you deployed a custom malicious MBean, you can now invoke your MBean methods directly from within jconsole. While this is also possible for the tonka-bean, beanshooter supports actions to interact with the tonka-bean from the command line:

You can also use the shell action, to launch multiple commands as in a (pseudo) command shell. The shell also contains wrappers around the upload, download and executeBackground actions of beanshooter:

Once you are done with your MBean, you should make sure to undeploy all changes that you have made to the server. At least you should remove your malicious MBean from the server, but if MLet was not available when you started, you should also remove the MLet. beanshooter makes the cleanup pretty easy, by just invoking:

Now the JMX endpoint should be clean again and MLet and the malicious MBean should be removed.

JMXMP Support

JMXMP (JMX Messaging Protocol) is just an alternate way (alternate connector) to access a JMX agent and differs in some points from the Java RMI based access as described above. However, for the purpose of this tool, these differences do not really matter. The important thing is that also the JMXMP connector can allow unauthenticated connections and it is also possible to use the MLet MBean over this connector.

The required classes for the JMXMP connector can be found inside a .jar file called jmxremote_optional.jar. Unfortunately, this .jar does not has its own project on Maven anymore (it seems like it was an artifact of the JMX project once, but was removed for some reason). Now, it can be loaded as an artifact of other projects. beanshooter supports the JMXMP protocol by using the jmxremote-optional artifact from org.glassfish.external.

In order to test JMXMP support, the provided docker-image also opens multiple JMXMP listener on the ports 5555 to 5560. The following listing shows just the same examples as above, but this time using the JMXMP protocol:

Apart from the plain JMXMP listener on port 5555, the other JMXMP listeners implement different kind of protections:

Beanshooter supports all these types of protections and corresponding examples can be found inside the README.md of the docker-container.

Useful tip: It is also possible to use jconsole to connect to a running JMX agent via JMXMP. Instead of simply specifying the host and port number for the connection, you have to use the JMXMP service URI service:jmx:jmxmp://<JMXMPHOST>:<JMXMPPORT> and you have to make sure that the jmxremote_optional.jar is inside your classpath.

Deserialization Support

In case of authenticated JMX endpoints, it is pretty common that usage of MLet does not work, even with valid credentials. The following listing shows an attempt to deploy a malicious MBean on an authenticated JMX endpoint:

In these cases it might still be possible to attack the JMX endpoint by using deserialization attacks. To allow such attacks, the ysoserial project can be integrated to beanshooter by specifying the path to the corresponding ysoserial .jar file. This can be configured either in the configuration file or by using the --yso command line option. The default location is /opt/ysoserial/target/ysoserial-0.0.6-SNAPSHOT-all.jar.

With ysoserial setup correctly, one can attempt a deserialization attack against the target:

Older JMX instances might also be vulnerable to CVE-2016-3427, which is basically a pre-auth deserialization vulnerability. Whereas the above deserialization attack should work against the RMI based connector as well as against JMXMP based connector, the pre-auth attack only works against the RMI based connector:

Advanced Usage

Above it was already mentioned that beanshooter can read options from a configuration file. Options that would require long values, like the name of the MBean class or the corresponding ObjectName can only be passed inside of the configuration file. The following snipped shows you the default configuration file that is used by beanshooter internally:

It is possible to overwrite each option by specifying a custom configuration file using the --config parameter. The custom config file does not need to contain all options. Options that are not present were simply set to the default value. If you want your custom configuration to apply for each usage of beanshooter, you can also modify the config.properties file inside of the src folder before compiling the project.

In situations where the targeted server cannot access your host because of restrictive firewall rules, you may be able to use the --remote-stager option to specify a remote stager host. If you have access to the remote-stager, you can also use beanshooter to deploy the MBean by using the --stager-only option, which only spawns the HTTP listener. When using this option, no additional command line parameters are required. However, on your attacking machine you still need to specify the correct --stager-host, either by using command line options or a configuration file.

Why beanshooter

Here are some of the advantages why you may choose beanshooter in favor of other JMX scanning solutions:

Credits

Copyright 2020, Tobias Neitzel and the beanshooter contributors.