muhammad-ali007/log4j_cve-2021-44228लॉग4शेल (CVE-2021-44228) का शोषण करने के लिए व्यावहारिक प्रयोगशाला अभ्यास, जिसमें JNDI इंजेक्शन, LDAP रेफरल सर्वर और रिवर्स शेल पेलोड शामिल हैं। इसमें पहचान, बायपास तकनीक और पोस्ट-एक्सप्लॉइटेशन मार्गदर्शन शामिल है।
Log4j भेद्यता, जिसे "Log4Shell" या "CVE-2021-44228" के नाम से भी जाना जाता है, Apache Log4j लाइब्रेरी में एक गंभीर सुरक्षा दोष है। Log4j एक व्यापक रूप से उपयोग किया जाने वाला जावा-आधारित लॉगिंग फ्रेमवर्क है जो डेवलपर्स को फ़ाइलों, डेटाबेस और कंसोल आउटपुट जैसे विभिन्न गंतव्यों पर एप्लिकेशन से संदेश लॉग करने की अनुमति देता है।
यह भेद्यता दिसंबर 2021 में खोजी गई थी और इसकी गंभीरता और शोषण की संभावना के कारण इसने काफी ध्यान आकर्षित किया है। यह Log4j संस्करण 2.x को प्रभावित करता है, और कुछ मामलों में, पिछले संस्करणों को भी। Log4j भेद्यता एक रिमोट कोड एक्ज़ीक्यूशन (RCE) भेद्यता है, जिसका अर्थ है कि एक हमलावर इस दोष का शोषण करके लक्षित सिस्टम पर मनमाना कोड निष्पादित कर सकता है। यह भेद्यता Log4j लाइब्रेरी में एक डिज़ाइन दोष के कारण होती है जो विशेष रूप से तैयार किए गए डेटा वाले लॉग संदेशों के प्रसंस्करण से संबंधित है।
भेद्यता का शोषण लॉग संदेश में दुर्भावनापूर्ण कोड इंजेक्ट करने की क्षमता पर निर्भर करता है। यह विभिन्न वैक्टरों के माध्यम से प्राप्त किया जा सकता है, जैसे कि उपयोगकर्ता-नियंत्रित इनपुट फ़ील्ड, HTTP अनुरोध हेडर, या अन्य उपयोगकर्ता-प्रदत्त डेटा जो लॉग स्टेटमेंट को पास किया जाता है।
जब कोई कमजोर एप्लिकेशन विशेष रूप से तैयार किए गए डेटा वाले लॉग संदेश को संसाधित करता है, तो Log4j डेटा को जावा नेमिंग एंड डायरेक्टरी इंटरफ़ेस (JNDI) लुकअप के रूप में व्याख्या करता है। इस व्यवहार का शोषण करके, एक हमलावर एक पेलोड तैयार कर सकता है जो हमलावर द्वारा नियंत्रित एक दुर्भावनापूर्ण सर्वर पर JNDI लुकअप को ट्रिगर करता है। यह सर्वर तब एक पेलोड के साथ प्रतिक्रिया दे सकता है जो लक्षित सिस्टम पर निष्पादित होता है, जिससे हमलावर को रिमोट कोड निष्पादन प्राप्त करने की अनुमति मिलती है।
Log4j भेद्यता का प्रभाव गंभीर है क्योंकि Log4j का व्यापक रूप से विभिन्न जावा-आधारित एप्लिकेशनों में उपयोग किया जाता है, जिसमें वेब सर्वर, एप्लिकेशन और क्लाउड सेवाएँ शामिल हैं। यह भेद्यता हमलावरों को प्रभावित सिस्टम तक अनधिकृत पहुंच प्राप्त करने की अनुमति देती है, जिससे संभावित रूप से डेटा उल्लंघन, सिस्टम से समझौता और समझौता किए गए वातावरण का आगे शोषण हो सकता है।
आज, log4j संस्करण 2.16.0 उपलब्ध है और इस भेद्यता को पैच करता है (JNDI पूरी तरह से अक्षम है, मैसेज लुकअप का समर्थन हटा दिया गया है, और नया DoS भेद्यता CVE-2021-45046 मौजूद नहीं है)। (https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0)
हालांकि, इस भेद्यता का असली खतरा इस तथ्य के कारण है कि लॉगिंग पैकेज कितना सर्वव्यापी है। लाखों एप्लिकेशन और सॉफ्टवेयर प्रदाता अपने स्वयं के कोड में निर्भरता के रूप में इस पैकेज का उपयोग करते हैं। जबकि आप log4j का उपयोग करके अपने स्वयं के कोडबेस को पैच करने में सक्षम हो सकते हैं, अन्य विक्रेताओं और निर्माताओं को अभी भी अपने स्वयं के सुरक्षा अपडेट को डाउनस्ट्रीम धकेलने की आवश्यकता होगी। कई सुरक्षा शोधकर्ताओं ने इस भेद्यता की तुलना इसके विशाल हमले की सतह की प्रकृति के कारण शेलशॉक से की है। हम इस भेद्यता को आने वाले वर्षों तक देखेंगे।
CVE-2021-44228 के लिए कमजोर सॉफ्टवेयर और सेवाओं की एक बढ़ती सामुदायिक-समर्थित सूची के लिए, इस GitHub रिपॉजिटरी (https://github.com/YfryTchsGD/Log4jAttackSurface) को देखें।
जबकि CVE-2021-44228 के आसपास कई अन्य लेख, ब्लॉग, संसाधन और सीखने की सामग्री हैं, मैं (इस अभ्यास के लेखक) विशेष रूप से इन्हें पसंद करता हूँ:
log4j पैकेज प्रविष्टियों को "पार्स" करके लॉग में अतिरिक्त तर्क जोड़ता है, अंततः डेटा को समृद्ध करने के लिए -- लेकिन यह अतिरिक्त कार्रवाई भी कर सकता है और यहां तक कि प्रविष्टि डेटा के आधार पर कोड का मूल्यांकन भी कर सकता है। यह CVE-2021-44228 का सार है। अन्य सिंटैक्स वास्तव में लॉग फ़ाइलों में दर्ज होते ही निष्पादित हो सकते हैं। इस सिंटैक्स के कुछ उदाहरण इस प्रकार हैं:
आप शायद पहले से ही इस log4j भेद्यता का दुरुपयोग करने के लिए सामान्य पेलोड जानते हैं। इसका लाभ उठाने वाले सामान्य सिंटैक्स का प्रारूप इस प्रकार दिखता है:
यह सिंटैक्स इंगित करता है कि log4j "JNDI", या "जावा नेमिंग एंड डायरेक्टरी इंटरफ़ेस" से कार्यक्षमता लागू करेगा। अंततः, इसका उपयोग बाहरी संसाधनों, या "संदर्भों" तक पहुंचने के लिए किया जा सकता है, जो इस हमले में हथियार बनाया गया है।
"ldap://" स्कीमा पर ध्यान दें। यह इंगित करता है कि लक्ष्य LDAP प्रोटोकॉल के माध्यम से एक एंडपॉइंट (इस हमले के मामले में, एक हमलावर-नियंत्रित स्थान) तक पहुंचेगा। संक्षिप्तता के लिए, हमें यहां LDAP के सभी अंदर-बाहर और विवरणों को कवर करने की आवश्यकता नहीं होगी, लेकिन जान लें कि जैसे-जैसे हम अपने हमले को परिष्कृत करेंगे, हमें इसके साथ काम करना होगा। अभी के लिए, जान लें कि लक्ष्य वास्तव में एक बाहरी स्थान से कनेक्शन बनाएगा। यह उपरोक्त सिंटैक्स में ATTACKERCONTROLLEDHOST प्लेसहोल्डर द्वारा इंगित किया गया है। आप, इस परिदृश्य में हमलावर के रूप में कार्य करते हुए, इस कनेक्शन को देखने के लिए एक सरल लिसनर होस्ट कर सकते हैं।
अगला प्रश्न यह है कि हम इस सिंटैक्स को कहाँ दर्ज कर सकते हैं? कहीं भी जहां डेटा एप्लिकेशन द्वारा लॉग किया जाता है।
यह इस भेद्यता का मूल बिंदु है। दुर्भाग्य से, विभिन्न अनुप्रयोगों के लिए हमले की सतह निर्धारित करना बहुत कठिन है, और इसलिए, यह निर्धारित करना भी कठिन है कि कौन से एप्लिकेशन वास्तव में कमजोर हैं। केवल log4j फ़ाइलों की उपस्थिति देखने से सटीक संस्करण संख्या का पता नहीं चलता है, या यह भी पता नहीं चलता है कि एप्लिकेशन पैकेज का उपयोग कहाँ या कैसे कर सकता है।
अन्य स्थान जहां आप यह JNDI सिंटैक्स प्रदान कर सकते हैं:
यदि आप इस JNDI हमले वेक्टर के बारे में अधिक जानकारी चाहते हैं, तो कृपया 2016 से इस Black Hat USA प्रस्तुति की समीक्षा करें। https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
POC
शोषण इस बिंदु पर, आपने अपने netcat लिसनर में इस कनेक्शन को देखकर सत्यापित कर लिया है कि लक्ष्य वास्तव में कमजोर है। हालांकि, इसने एक LDAP अनुरोध किया... इसलिए आपके netcat लिसनर ने जो कुछ देखा होगा, वह गैर-मुद्रण योग्य वर्ण (अजीब दिखने वाले बाइट्स) हो सकते हैं। अब हम एक वास्तविक LDAP हैंडलर के साथ प्रतिक्रिया देने के लिए इस नींव पर निर्माण कर सकते हैं।
हम एक "LDAP रेफरल सर्वर" को मंचित करने के लिए एक ओपन-सोर्स और सार्वजनिक उपयोगिता का उपयोग करेंगे। इसका उपयोग पीड़ित के प्रारंभिक अनुरोध को दूसरे स्थान पर रीडायरेक्ट करने के लिए किया जाएगा, जहां आप एक द्वितीयक पेलोड होस्ट कर सकते हैं जो अंततः लक्ष्य पर कोड चलाएगा। यह इस प्रकार टूटता है:
इसका मतलब है कि हमें एक HTTP सर्वर की आवश्यकता होगी, जिसे हम निम्नलिखित विकल्पों में से किसी के साथ आसानी से होस्ट कर सकते हैं (पोर्ट 8000 पर सेवा):
