Java Remote Method Invocation, या Java RMI, एक ऑब्जेक्ट उन्मुख RPC तंत्र है जो एक Java वर्चुअल मशीन में स्थित एक ऑब्जेक्ट को दूसरे Java वर्चुअल मशीन में स्थित एक ऑब्जेक्ट पर विधियों को कॉल करने की अनुमति देता है। यह डेवलपर्स को ऑब्जेक्ट-उन्मुख पैराजाइम का उपयोग करके वितरित अनुप्रयोग लिखने में सक्षम बनाता है। एक आक्रामक दृष्टिकोण से Java RMI का एक संक्षिप्त परिचय इस ब्लैकहैट टॉक में पाया जा सकता है।
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
Usually, only the default Java RMI components (the RMI Registry and the Activation System) are bound to common ports. The remote objects that implement the actual RMI application are usually bound to random ports as shown in the output above.
nmap has sometimes troubles identifying SSL protected RMI services. If you encounter an unknown ssl service on a common RMI port, you should further investigate.
RMI Components
साधारण शब्दों में, Java RMI एक डेवलपर को नेटवर्क पर एक Java object उपलब्ध कराने की अनुमति देता है। यह एक TCP पोर्ट खोलता है जहाँ ग्राहक कनेक्ट कर सकते हैं और संबंधित ऑब्जेक्ट पर विधियों को कॉल कर सकते हैं। हालांकि यह सरल लगता है, Java RMI को कई चुनौतियों का सामना करना पड़ता है:
Java RMI के माध्यम से एक विधि कॉल को भेजने के लिए, ग्राहकों को लक्षित ऑब्जेक्ट के IP पते, सुनने वाले पोर्ट, लागू की गई क्लास या इंटरफेस और ObjID के बारे में जानना आवश्यक है ( ObjID एक अद्वितीय और यादृच्छिक पहचानकर्ता है जो तब बनाया जाता है जब ऑब्जेक्ट नेटवर्क पर उपलब्ध कराया जाता है। यह आवश्यक है क्योंकि Java RMI एक ही TCP पोर्ट पर कई ऑब्जेक्ट्स को सुनने की अनुमति देता है)।
दूरस्थ ग्राहक सर्वर पर संसाधनों को आवंटित कर सकते हैं जो उजागर किए गए ऑब्जेक्ट पर विधियों को कॉल करके। Java virtual machine को यह ट्रैक करना होगा कि इनमें से कौन से संसाधन अभी भी उपयोग में हैं और कौन से को गार्बेज कलेक्ट किया जा सकता है।
पहली चुनौती का समाधान RMI registry द्वारा किया जाता है, जो मूल रूप से Java RMI के लिए एक नामकरण सेवा है। RMI registry स्वयं भी एक RMI service है, लेकिन लागू की गई इंटरफेस और ObjID निश्चित और सभी RMI ग्राहकों द्वारा ज्ञात होते हैं। यह RMI ग्राहकों को केवल संबंधित TCP पोर्ट को जानकर RMI रजिस्ट्री का उपभोग करने की अनुमति देता है।
जब डेवलपर्स अपने Java objects को नेटवर्क के भीतर उपलब्ध कराना चाहते हैं, तो वे आमतौर पर उन्हें एक RMI registry से जोड़ते हैं। registry सभी जानकारी को संग्रहीत करता है जो ऑब्जेक्ट से कनेक्ट करने के लिए आवश्यक है (IP पता, सुनने वाला पोर्ट, लागू की गई क्लास या इंटरफेस और ObjID मान) और इसे एक मानव-पठनीय नाम ( bound name ) के तहत उपलब्ध कराता है। ग्राहक जो RMI service का उपभोग करना चाहते हैं, वे संबंधित bound name के लिए RMI registry से पूछते हैं और रजिस्ट्री सभी आवश्यक जानकारी लौटाती है। इस प्रकार, स्थिति मूल रूप से एक सामान्य DNS सेवा के समान है। निम्नलिखित सूची एक छोटा उदाहरण दिखाती है:
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();}}}
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. 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.
Together with the deprecated Activation System, these are the three default components of Java RMI:
The RMI Registry (ObjID = 0)
The Activation System (ObjID = 1)
The Distributed Garbage Collector (ObjID = 2)
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 RMI service.
RMI Enumeration
remote-method-guesser is a Java RMI vulnerability scanner that is capable of identifying common RMI vulnerabilities automatically. Whenever you identify an RMI endpoint, you should give it a try:
$ 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
The output of the enumeration action is explained in more detail in the documentation pages 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 may allows to identify other vulnerabilities:
यहां तक कि जब enumeration के दौरान कोई कमजोरियां नहीं पाई गई हैं, उपलब्ध RMI सेवाएं अभी भी खतरनाक कार्यों को उजागर कर सकती हैं। इसके अलावा, हालांकि RMI संचार RMI डिफ़ॉल्ट घटकों के लिए deserialization फ़िल्टर द्वारा सुरक्षित है, कस्टम RMI सेवाओं से बात करते समय, ऐसे फ़िल्टर आमतौर पर मौजूद नहीं होते हैं। इसलिए, RMI सेवाओं पर मान्य विधि हस्ताक्षर जानना मूल्यवान है।
दुर्भाग्यवश, Java RMIremote objects पर विधियों की enumeration का समर्थन नहीं करता है। यह कहा जा सकता है कि, विधि हस्ताक्षरों को remote-method-guesser या rmiscout जैसे उपकरणों के साथ bruteforce करना संभव है:
अनुमान लगाने के अलावा, आपको खोज इंजनों या GitHub पर उस RMI सेवा के इंटरफेस या यहां तक कि कार्यान्वयन की तलाश करनी चाहिए। bound name और कार्यान्वित वर्ग या इंटरफेस का नाम यहां सहायक हो सकता है।
ज्ञात इंटरफेस
remote-method-guesser उन वर्गों या इंटरफेस को known के रूप में चिह्नित करता है यदि वे उपकरण के ज्ञात RMI सेवाओं के आंतरिक डेटाबेस में सूचीबद्ध हैं। इन मामलों में, आप संबंधित RMI सेवा पर अधिक जानकारी प्राप्त करने के लिए known क्रिया का उपयोग कर सकते हैं:
$ 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}
Trickest का उपयोग करें ताकि आप दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित कार्यप्रवाहों को आसानी से बना और स्वचालित कर सकें।
आज ही एक्सेस प्राप्त करें:
