1098/1099/1050 - Pentesting Java RMI - RMI-IIOP
Last updated
Was this helpful?
Last updated
Was this helpful?
The Java Remote Method Invocation, or Java RMI, is a mechanism that allows an object that exists in one Java virtual machine to access and call methods that are contained in another Java virtual machine; This is basically the same thing as a , but in an object-oriented paradigm instead of a procedural one, which allows for communication between Java programs that are not in the same address space.
One of the major advantages of RMI is the ability for remote objects to load new classes that aren't explicitly defined already, extending the behavior and functionality of an application. From .
Default port: 1099, 1098
(Example taken from ) The following classes implement a simple client-server program using RMI that displays a message.
RmiServer class — listens to RMI requests and implements the interface which is used by the client to invoke remote methods.
RmiServerIntf interface — defines the interface that is used by the client and implemented by the server.
To execute remote methods, Java RMI clients submit a 64-bit hash of the method signature, which the server uses to identify the corresponding server-side method. These hashes are computed with the following logic:
Source code representation of the signature:
void myRemoteMethod(int count, Object obj, boolean flag)
Bytecode representation of signature:
myRemoteMethod(ILjava/lang/Object;Z)V
Method Hash: big-endian representation of first 8 bytes of the SHA1 of the signature:
Hash = SHA1String(“myRemoteMethod(ILjava/lang/Object;Z)V”).substring(0,8).reverse()
Figure 2: Distribution of return types of 15,000 functions sampled from RMI interfaces on GitHub
As shown above, using int, boolean, and void as our guessed return types gives us a 61.4% chance of guessing correctly based off this data. If we add java.lang.String, we can add an extra 9.8% to our probable success, as it represents nearly a third of the non-primitive return types. That brings our final list of candidate return types (int, boolean, void, String) to a 71.22% probability in the observed dataset.
RMIScout includes a deduped wordlist of prototypes (prototypes.txt) found from this exploration and it also includes a list of most frequently occurring method names (methods.txt).
To identify RMI functions without executing them, RMIScout leverages low-level JRE RMI functions and uses dynamic class generation to send RMI invocations with deliberately mismatched types to trigger RemoteExceptions. These exceptions allow us to identify remote methods without actually invoking them.
To accomplish this, RMIScout computes the method hash using the original user-supplied types, but substitutes the values of all parameters for an instance of a dynamically generated, serializable class. The class is generated with a random 255-character name (the underlying assumption being that this random name does not exist in the remote class path). For example:
Candidate Remote Interface:
void login(String user, String password)
RMIScout will invoke:
login((String) new QUjsdg83..255 chars..(), (String) new QUjsdg83..255 chars..())
If the RMI method is present, it will attempt to unmarshal the parameters. This will result in a remote exception disclosed to the client. Specifically, it’ll be a java.rmi.UnmarshalException either caused by a ClassNotFoundException (due to our non-existent random class) or by other exceptions (finding object-typed data when primitive-typed data was expected in the stream) without invoking the underlying method.
I was not able to discover a method for identifying parameter-less methods without invoking them. As such, by default void argument prototypes are skipped by RMIScout unless the option --allow-unsafe is used. Note: --allow-unsafe will cause parameter-less methods to be invoked on discovery, which can lead to unexpected and possibly destructive behavior on the remote server.
Unlike standard Java RMI (aka RMI-JRMP) services that are identified by a method hash, Java Method invocation over the CORBA Internet Inter-Orb Protocol (RMI-IIOP) uses two different algorithms to identify method signatures:
For non-overloaded methods, the signature is just the method name represented as a string. Parameter types, the number of parameters, and return type are all disregarded.
For overloaded methods (methods sharing the same name), RMI-IIOP uses a concatenated string with the method name and its respective ordered types (examples below).
Let’s take a look at an example interface and a decompiled RMI-IIOP stub. Here is an excerpt of the remote interface from the RMIScout demo:
First let’s look at the add(int,int) method. Since its method name is unique, the generated stub is simply the method name. The server compares the client’s requested method (paramString in the figure below) against a string literal.
Because this method only uses primitive parameter types, the compiled stub has no type safety. The server will perform two 8-byte reads and interpret the bytes as long integers. For brute-forcing, the lack of type safety makes it impossible to know if we guessed the correct types. Furthermore, any additional input from the client is disregarded, thus preventing safe identification via an error for too many supplied parameters:
Now, let’s look at the overloaded sayTest19 methods. Here, the CORBA stub compiler appends the signature with information about the types to differentiate between the overloaded method names. Some naming schemes are more intuitive than others. In this case, we are provided type safety by the signature itself:
And for sayTest20(String), we again have a unique method name, but here we are deserializing a String class. In this case, the complex parameter allows us to force a ClassCastException to allow identification without invocation.
So, what does this mean for safely brute-forcing RMI-IIOP stubs? Overall, it’s a significantly smaller keyspace; most of the time we will only need to get the name of the method correct. That said, we will likely accidentally invoke methods that only use primitives, and we won’t always know the true method signature.
1. We can't identify methods solely using primitive typed parameters without invoking the method
This is because there is no concept of type checking in the generated stubs, any values sent along will be deserialized and cast to the expected primitive (as seen in the add(int, int) example above). Unlike RMI-JRMP, primitives are not up-cast to an Object-derived type, upcasting throws a ClassCastException instead of execution.
2. We can't identify the maximum number or types of parameters
If a method is not overloaded, we will only have an exception if there is a ClassCastException when deserializing a parameter or an unexpected EOFException because of insufficient parameters. Extra parameters in the input stream will just be ignored.
3. We can't identify the return types
Return types are not included in any part of the signature matching, so there’s no guaranteed way to identify the return type. If it’s an Object-derived type, we may get a local ClassCastException if RMIScout attempts to deserialize an incorrect typed response (invoke mode), but for primitives, we won’t know.
4. We have to send two requests for every check
RMIScout needs to test both possible signature formats because the overloaded methods use a distinct alternative format.
5. We need to use JRE8 to successfully use RMIScout's RMI-IIOP functionality
JRE9 stripped out RMI-IIOP functionality, so to run these tests and take advantage of existing standard library code, we need to use JRE8.
Overall, there is a risk of accidental invocation in brute-forcing these signatures. As such, RMIScout displays a warning prior to running IIOP brute-forcing. However, it is also significantly easier to enumerate signatures for IIOP. Using custom wordlists with method names least likely to cause harm is recommended (e.g., a method name like deleteRecord may match against deleteRecord(int) whereas evaluateString is less likely to match a primitive).
We can still achieve arbitrary Java deserialization by replacing object or array types in a method signature. Unlike RMI-JRMP, String types can still be exploited in RMI-IIOP servers compiled with the latest build of the JDK8.
port:1099 java
RmiClient class — this is the client which gets the reference (a proxy) to the remote object living on the server and invokes its method to get a message. If the server object implemented java.io.Serializable instead of java.rmi.Remote, it would be serialized and passed to the client as a value.
RMI registries do not disclose a list of available method signatures, but if you can guess it, you can invoke it. Therefore, a good approach to abuse this service is to brute-force the available method signatures. RMI methods are usually interesting as a bunch of them will deserialize the received data making them vulnerable to and granting RCE to an attacker.
(Research taken from )
As shown above, the information that is used to compute a method hash are: the method name, the return types, and an ordered list of the fully qualified names of the parameters’ types. Instead of brute-forcing the 64-bit keyspace, we can use wordlists for each of these categories to guess common signatures. Using , I scraped GitHub for RMI interfaces in open source projects and found interesting patterns across the 15,000+ method signatures:
to explore and try to find RCE vulnerabilities.
to enumerate and attack
allows an easy exploitation of insecure configured JMX services (I tried and It gave me Error: Can't connect to remote service let me know if you know how to fix this issue).
RMI-IIOP (read as "RMI over IIOP") denotes the (RMI) interface over the (IIOP), which delivers (CORBA) capabilities to the Java platform. It was initially based on two specifications: the Java Language Mapping to OMG IDL, and CORBA/IIOP 2.3.1
With features inherited from CORBA, software components that work together can be written in multiple computer languages and run on multiple computers. In other words, it supports multiple platforms and can make remote procedure calls to execute, subroutines on another computer as defined by RMI. Description from .
(Research from )