Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 01:17:36 +00:00
Code Issues Projects Releases Packages Wiki Activity

Fix some typos

Browse source
This commit is contained in:
TNeitzel 2021-12-29 10:26:25 +01:00
parent 96aa43e4f5
commit 53b564d9ee
1 changed files with 14 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
pentesting/1099-pentesting-java-rmi.md
View file

@ -5,7 +5,7 @@
*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)
to *Java RMI* from an offensive perspective can be found in [this blackhat talk](https://youtu.be/t_aw1mDNhzI?t=202).
**Default port:** 1090,1098,1099,1199,4443-4446,8999-9010,9999
@ -40,7 +40,7 @@ there are several challenges that *Java RMI* needs to solve:
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 it's corresponding *TCP*
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*.
@ -59,9 +59,9 @@ public class ExampleClient {
public static void main(String[] args) {
try {
Registry registry = LocateRegistry.getRegistry(remoteHost);
RemoteService ref = (RemoteService)registry.lookup("remote-service");
String response = ref.remoteMethod();
Registry registry = LocateRegistry.getRegistry(remoteHost); // Connect to the registry
RemoteService ref = (RemoteService)registry.lookup("remote-service"); // Lookup the desired bound name
String response = ref.remoteMethod(); // Call a method on the remote object
} catch( Exception e) {
e.printStackTrace();
@ -71,7 +71,7 @@ public class ExampleClient {
```
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*. Then an *RMI client*
*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.
@ -81,11 +81,11 @@ Together with the deprecated *Activation System*, these are the three default co
2. The *Activation System* (``ObjID = 1``)
3. The *Distributed Garbage Collector* (``ObjID = 2``)
The default components of *Java RMI* have been a known attack vectors for quite some time and multiple vulnerabilities
are known for outdated *Java* versions. From an attacker perspective these default components are interisting, because
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 custom *RMI service*.
method signature in advance. Without knowing an existing method signature, there is no way to communicate to a *RMI service*.
## RMI Enumeration
@ -153,11 +153,11 @@ $ rmg enum 172.17.0.2 9010
[+] --> Client codebase enabled - Configuration Status: Non Default
```
The different outputs of the enumeration action are explained in the [documentation pages](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action)
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 could be used to identify other vulnerabilities:
This may allows to identify other vulnerabilities:
```console
$ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
@ -174,10 +174,10 @@ $ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
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 uses deserialization filters, when talking to custom *RMI* services, such filters are
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 now support enumerating methods on *remote objects*. That being said,
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):
@ -251,7 +251,7 @@ More information can be found in these articles:
* [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 implemented class / interface
implementation of an encountered *RMI* service. The *bound name* and the name of the implemented class or interface
can be helpful here.