BaRMIe - Java RMI Enumeration And Attack Tool

RMI services often expose dangerous functionality without adequate security controls, however RMI services tend to pass under the radar during security assessments due to the lack of effective testing tools. In 2008 Adam Boulton spoke at AppSec USA (YouTube) and released some RMI attack tools which disappeared soon after, however even with those tools a successful zero-knowledge attack relies on a significant brute force attack (~64-bits/9 quintillion possibilities) being performed over the network.

The goal of BaRMIe is to enable security professionals to identify, attack, and secure insecure RMI services. Using partial RMI interfaces from existing software, BaRMIe can interact directly with those services without first brute forcing 64-bits over the network.

Disclaimer

BaRMIe was written to aid security professionals in identifying insecure RMI services on systems which the user has prior permission to attack. Unauthorised access to computer systems is illegal and BaRMIe must be used in accordance with all relevant laws. Failure to do so could lead to you being prosecuted. The developers of BaRMIe assume no liability and are not responsible for any misuse or damage caused by this program.

Usage

Use of BaRMIe is straightforward. Run BaRMIe with no parameters for usage information.

Enumeration mode (-enum) extracts details of objects that are exposed through an RMI registry service and lists any known attacks that affect the endpoint.Attack mode (-attack) first enumerates the given targets, then provides a menu system for launching known attacks against RMI services.A single target can be specified on the command line. Alternatively BaRMIe can extract targets from a simple text file or nmap output.

No Vulnerable Targets Identified?Great! This is your opportunity to help improve BaRMIe! BaRMIe relies on some knowledge of the classes exposed over RMI so contributions will go a long way in improving BaRMIe and the security of RMI services.If you have access to JAR files or source code for the target application then producing an attack is as simple as compiling code against the relevant JAR files. Retrieve the relevant remote object using the LocateRegistry and Registry classes and call the desired methods. Alternatively look for remote methods that accept arbitrary objects or otherwise non-primitive parameters as these can be used to deliver deserialization payloads. More documentation on attacking RMI and producing attacks for BaRMIe will be made available in the near future.Alternatively, get in touch, and provide as much detail as possible including BaRMIe -enum output and ideally the relevant JAR files.

Attack TypesBaRMIe is capable of performing three types of attacks against RMI services. A brief description of each follows. Further technical details will be published in the near future at https://nickbloor.co.uk/. In addition to this, I presented the results of my research at 44CON 2017 and the slides can be found here: BaRMIe - Poking Java's Back Door.

1. Attacking Insecure MethodsThe first and most straightforward method of attacking insecure RMI services is to simply call insecure remote methods. Often dangerous functionality is exposed over RMI which can be triggered by simply retrieving the remote object reference and calling the dangerous method. The following code is an example of this:

2. Deserialization via Object-type ParaetersSome RMI services do not expose dangerous functionality, or they implement security controls such as authentication and session management. If the RMI service exposes a method that accepts an arbitrary Object as a parameter then the method can be used as an entry point for deserialization attacks. Some examples of such methods can be seen below:

3. Deserialization via Illegal Method InvocationDue to the use of serialization, and insecure handling of method parameters on the server, it is possible to use any method with non-primitive parameter types as an entry point for deserialization attacks. BaRMIe achieves this by using TCP proxies to modify method parameters at the network level, essentially triggering illegal method invocations. Some examples of vulnerable methods can be seen below:

The parameters to each of these methods can be replaced with a deserialization payload as the method invocation passes through a proxy. This attack is possible because Java does not attempt to verify that remote method parameters received over the network are compatible with the actual parameter types before deserializing them.

Disclaimer

Any actions and or activities related to the material contained within this Website is solely your responsibility.The misuse of the information in this website can result in criminal charges brought against the persons in question. The authors and www.hack4.net will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.