mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-15 01:17:36 +00:00
Fix some typos
This commit is contained in:
parent
96aa43e4f5
commit
53b564d9ee
1 changed files with 14 additions and 14 deletions
|
@ -5,7 +5,7 @@
|
||||||
*Java Remote Method Invocation*, or *Java RMI*, is an object oriented *RPC* mechanism that allows an object
|
*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*.
|
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
|
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
|
**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
|
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
|
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.
|
port.
|
||||||
|
|
||||||
When developers want to make their *Java objects* available within the network, they usually bind them to an *RMI registry*.
|
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) {
|
public static void main(String[] args) {
|
||||||
|
|
||||||
try {
|
try {
|
||||||
Registry registry = LocateRegistry.getRegistry(remoteHost);
|
Registry registry = LocateRegistry.getRegistry(remoteHost); // Connect to the registry
|
||||||
RemoteService ref = (RemoteService)registry.lookup("remote-service");
|
RemoteService ref = (RemoteService)registry.lookup("remote-service"); // Lookup the desired bound name
|
||||||
String response = ref.remoteMethod();
|
String response = ref.remoteMethod(); // Call a method on the remote object
|
||||||
|
|
||||||
} catch( Exception e) {
|
} catch( Exception e) {
|
||||||
e.printStackTrace();
|
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
|
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.
|
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 *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``)
|
2. The *Activation System* (``ObjID = 1``)
|
||||||
3. The *Distributed Garbage Collector* (``ObjID = 2``)
|
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
|
The default components of *Java RMI* have been 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
|
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.
|
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
|
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
|
## RMI Enumeration
|
||||||
|
@ -153,11 +153,11 @@ $ rmg enum 172.17.0.2 9010
|
||||||
[+] --> Client codebase enabled - Configuration Status: Non Default
|
[+] --> 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.
|
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.
|
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
|
```console
|
||||||
$ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
|
$ 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
|
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
|
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.
|
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)
|
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):
|
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)
|
* [rmiscout](https://bishopfox.com/blog/rmiscout)
|
||||||
|
|
||||||
Apart from guessing, you should also look in search engines or *GitHub* for the interface or even the
|
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.
|
can be helpful here.
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue