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 [remote procedure call](https://null-byte.wonderhowto.com/how-to/hack-like-pro-exploit-and-gain-remote-access-pcs-running-windows-xp-0134709/), 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 [here](https://null-byte.wonderhowto.com/how-to/exploit-java-remote-method-invocation-get-root-0187685/).
// Bind this object instance to the name "RmiServer"
Naming.rebind("//localhost/RmiServer", server);
System.out.println("PeerServer bound in registry");
}
}
```
**`RmiServerIntf` interface** — defines the interface that is used by the client and implemented by the server.
```java
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface RmiServerIntf extends Remote {
String getMessage() throws RemoteException;
}
```
**`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.[\[2\]](https://en.wikipedia.org/wiki/Java_remote_method_invocation#cite_note-2)
```java
import java.rmi.Naming;
public class RmiClient {
public static void main(String args[]) throws Exception {
RmiServerIntf server = (RmiServerIntf)Naming.lookup("//localhost/RmiServer");
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 [**Java Insecure Deserialization**](../pentesting-web/deserialization/#java-http) and granting RCE to an attacker.
\(Research taken from [https://labs.bishopfox.com/tech-blog/rmiscout](https://labs.bishopfox.com/tech-blog/rmiscout)\)
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:
1.**Source code** representation of the signature:
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 [GitGot](https://labs.bishopfox.com/blog/gitgot-tool-release), I scraped GitHub for RMI interfaces in open source projects and found interesting patterns across the 15,000+ method signatures:
_**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`\).
### Brute-Forcing Signatures
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 clas**s. 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.
[https://github.com/NickstaDB/BaRMIe](https://github.com/NickstaDB/BaRMIe) to enumerate and attack
[https://github.com/siberas/sjet](https://github.com/siberas/sjet) 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 [Java Remote Method Invocation](https://en.wikipedia.org/wiki/Java_Remote_Method_Invocation) \(RMI\) interface over the [Internet Inter-Orb Protocol](https://en.wikipedia.org/wiki/Internet_Inter-Orb_Protocol) \(IIOP\), which delivers [Common Object Request Broker Architecture](https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture) \(CORBA\) [distributed computing](https://en.wikipedia.org/wiki/Distributed_computing) 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 [here](https://en.wikipedia.org/wiki/RMI-IIOP).
\(Research from [https://labs.bishopfox.com/tech-blog/lessons-learned-on-brute-forcing-rmi-iiop-with-rmiscout](https://labs.bishopfox.com/tech-blog/lessons-learned-on-brute-forcing-rmi-iiop-with-rmiscout)\)
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**:
1. 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.
2. 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:
```java
public int add(int paramInt1, int paramInt2) throws RemoteException;
public String sayTest19(int paramInt) throws RemoteException;
public String sayTest19(List paramList1, List paramList2) throws RemoteException;
public String sayTest19(List[] paramArrayOfList, int paramInt) throws RemoteException;
public Object sayTest20(String paramString) throws RemoteException;
```
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 nam**e, 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.
### RMI-IIOP Brute-forcing Limitations
**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.**
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 remote procedure call, 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.
nmap -sC -sV -Pn 10.11.1.73 -p 1100
may dump the reg of the java-rmi instance. If this is the case the machine may be vulnerable to a deserializaion exploit.
BaRMIe.jar is the way to go to directly exploit this vulnerability.
https://github.com/NickstaDB/BaRMIe/releases/tag/v1.01 is where the latest build is hosted, pre-built
