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 :
Informations de base
L'invocation de méthode à distance Java, ou Java RMI, est un mécanisme de 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 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 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 :
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).
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 :
importjava.rmi.registry.Registry;importjava.rmi.registry.LocateRegistry;importlab.example.rmi.interfaces.RemoteService;publicclassExampleClient {privatestaticfinalString remoteHost ="172.17.0.2";privatestaticfinalString boundName ="remote-service";publicstaticvoidmain(String[] args){try {Registry registry =LocateRegistry.getRegistry(remoteHost); // Connect to the RMI registryRemoteService ref = (RemoteService)registry.lookup(boundName); // Lookup the desired bound nameString 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 :
Le Registre RMI (ObjID = 0)
Le Système d'Activation (ObjID = 1)
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 la signature de la méthode correspondante à l'avance. 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:
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:
En plus de 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
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 :
