hacktricks/pentesting/1099-pentesting-java-rmi.md

1098/1099/1050 - Pentesting Java RMI - RMI-IIOP

Basic Information

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.

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.

Default port: 1099, 1098

PORT     STATE SERVICE     REASON
1099/tcp open  rmiregistry syn-ack
1099/tcp open  java-rmi    Java RMI

Example

Example taken from [here](https://en.wikipedia.org/wiki/Java_remote_method_invocation)
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.

import java.rmi.Naming;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
import java.rmi.registry.*;

public class RmiServer extends UnicastRemoteObject implements RmiServerIntf {
    public static final String MESSAGE = "Hello World";

    public RmiServer() throws RemoteException {
        super(0); // required to avoid the 'rmic' step, see below
    }

    public String getMessage() {
        return MESSAGE;
    }

    public static void main(String args[]) throws Exception {
        System.out.println("RMI server started");

        try { //special exception handler for registry creation
            LocateRegistry.createRegistry(1099);
            System.out.println("java RMI registry created.");
        } catch (RemoteException e) {
            //do nothing, error means registry already exists
            System.out.println("java RMI registry already exists.");
        }
           
        //Instantiate RmiServer
        RmiServer server = new RmiServer();

        // 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.

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]

import java.rmi.Naming;

public class RmiClient {
    public static void main(String args[]) throws Exception {
        RmiServerIntf server = (RmiServerIntf)Naming.lookup("//localhost/RmiServer");
        System.out.println(server.getMessage());
    }
}

RMI Enumeration

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 and granting RCE to an attacker.

RMI Method Signatures

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:
   void myRemoteMethod(int count, Object obj, boolean flag)
2. Bytecode representation of signature:
   myRemoteMethod(ILjava/lang/Object;Z)V
3. 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()

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, 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 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.

Automatic Enumeration

msf> use auxiliary/scanner/misc/java_rmi_server
msf> use auxiliary/gather/java_rmi_registry
nmap -sV --script "rmi-dumpregistry or rmi-vuln-classloader" -p <PORT> <IP>

https://github.com/BishopFox/rmiscout to explore and try to find RCE vulnerabilities.
https://github.com/NickstaDB/BaRMIe to enumerate and attack
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.

Reverse Shell

msf> use exploit/multi/misc/java_rmi_server

RMI-IIOP

RMI-IIOP read as "RMI over IIOP" denotes the Java Remote Method Invocation RMI interface over the Internet Inter-Orb Protocol IIOP, which delivers Common Object Request Broker Architecture CORBA 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.

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:

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:

if (paramString.equals("add"))
{
 int m = localInputStream.read_long();
 i2 = localInputStream.read_long();
 int i3 = localCorbaImpl.add(m, i2);
 localObject9 = paramResponseHandler.createReply();
 ((org.omg.CORBA.portable.OutputStream)localObject9).write_long(i3);
 return (org.omg.CORBA.portable.OutputStream)localObject9;
}

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:

if (paramString.equals("sayTest19__long"))
{
 int n = localInputStream.read_long();
 localObject6 = localCorbaImpl.sayTest19(n);
 localObject8 = (org.omg.CORBA_2_3.portable.OutputStream)paramResponseHandler.createReply();
 ((org.omg.CORBA_2_3.portable.OutputStream)localObject8).write_value((Serializable)localObject6, String.class);
 return (org.omg.CORBA.portable.OutputStream)localObject8;
}
if (paramString.equals("sayTest19__java_util_List__java_util_List"))
{
 localObject3 = (List)localInputStream.read_value(List.class);
 localObject6 = (List)localInputStream.read_value(List.class);
 localObject8 = localCorbaImpl.sayTest19((List)localObject3, (List)localObject6);
 localObject9 = (org.omg.CORBA_2_3.portable.OutputStream)paramResponseHandler.createReply();
 ((org.omg.CORBA_2_3.portable.OutputStream)localObject9).write_value((Serializable)localObject8, String.class);
 return (org.omg.CORBA.portable.OutputStream)localObject9;
}
if (paramString.equals("sayTest19__org_omg_boxedRMI_java_util_seq1_List__long"))
{
 localObject2 = (List[])localInputStream.read_value(new List[0].getClass());
 i2 = localInputStream.read_long();
 localObject7 = localCorbaImpl.sayTest19((List[])localObject2, i2);
 localObject9 = (org.omg.CORBA_2_3.portable.OutputStream)paramResponseHandler.createReply();
 ((org.omg.CORBA_2_3.portable.OutputStream)localObject9).write_value((Serializable)localObject7, String.class);
 return (org.omg.CORBA.portable.OutputStream)localObject9;
}

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.

if (paramString.equals("sayTest20"))
{
 localObject1 = (String)localInputStream.read_value(String.class);
 localObject4 = localCorbaImpl.sayTest20((String)localObject1);
 localObject7 = paramResponseHandler.createReply();
 Util.writeAny((org.omg.CORBA.portable.OutputStream)localObject7, localObject4);
 return (org.omg.CORBA.portable.OutputStream)localObject7;
}

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.

Shodan

• port:1099 java