<summary><strong>Learn AWS hacking from zero to hero with</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=1099-pentesting-java-rmi) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
_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).
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.
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:
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.
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_.
[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:
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:
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):
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.
[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_:
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=1099-pentesting-java-rmi) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\
<summary><strong>Learn AWS hacking from zero to hero with</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
