thedevappsecguy/log4j-mitigation-cve-2021-44228--cve-2021-45046--cve-2021-45105--cve-2021-44832Log4J CVE-2021-44228 : ورقة مساعدة للتخفيف
تحديث - 28-Dec-2021
CVE-2021-44832: Apache Log4j2 عرضة لـ RCE عبر JDBC Appender عندما يتحكم المهاجم في الإعدادات.
تم الإصلاح في Log4j 2.17.1 (Java 8)، و2.12.4 (Java 7)، و2.3.2 (Java 6)
تحديث - 17-Dec-2021
خلال الليلة الماضية، تم الكشف من قبل Apache أن إصدار Log4j 2.16 معرض أيضًا لهجوم رفض الخدمة، مع تأثير يتمثل في تعطل التطبيق بالكامل، وقد تم تصنيف الخطورة على أنها عالية (7.5) وتم إصدار CVE-2021-45105، وتم نشر إصدار جديد ثابت (2.17) من قبل Apache، يُوصى بالترقية إليه.
الخلفية:
كانت المناقشات على الإنترنت تدور حول ثغرة يوم-صفر (يمكن أن تؤدي إلى تنفيذ تعليمات برمجية عن بُعد) في مكتبة تسجيل Log4J الشهيرة من Apache بلغة Java. توجد هذه الثغرة المحددة – التي تم تتبعها كـ CVE-2021-44228 بأعلى درجة "حرجة" من CVSS وهي 10 – في قدرة البحث في Log4J، بالإضافة إلى JNDI (واجهة تسمية ودليل جافا). المشكلة واسعة الانتشار لأن العديد من المطورين لم يكونوا على دراية بأن استخدام Log4J مع إدخال غير مُفلتر خطير.
التأثير الأكبر هو أن المهاجم يمكنه جعل سلسلة نصية تصل إلى المسجل، والتي عند معالجتها بواسطة Log4J، تنفذ تعليمات برمجية عشوائية. استخدمت الأمثلة الأولى لهذا المسار ${jndi:ldap}، والذي يمكن أن يؤدي إلى تحميل تعليمات برمجية عشوائية من عنوان URL بعيد. يتم تخفيف هذا المسار جزئيًا باستخدام بيئات تشغيل Java الأحدث التي تحظر محمل الفئات المستند إلى عنوان URL افتراضيًا. لسوء الحظ، قد لا تكون نسخة حديثة من Java كافية لمنع الاستغلال، حيث قد يعرض التطبيق نفسه فئات يمكن استخدامها لتشغيل تعليمات برمجية عشوائية.
بنية JNDI:
تخفيفات للبيئات المختلفة:
تحديث - 17-Dec-2021
ثغرة أمنية CVE-2021-45105
التفاصيل:
لم تحمي إصدارات Apache Log4j2 من 2.0-alpha1 حتى 2.16.0 من التكرار غير المنضبط الناتج عن عمليات البحث المرجعية الذاتية. عند استخدام تهيئة تسجيل غير افتراضية مع Pattern Layout مع Context Lookup (على سبيل المثال، $${ctx:loginId})، يمكن للمهاجمين الذين لديهم سيطرة على بيانات إدخال Thread Context Map (MDC) صياغة بيانات إدخال ضارة تحتوي على بحث متكرر، مما يؤدي إلى StackOverflowError الذي سينهي العملية. يُعرف هذا أيضًا بهجوم DOS (رفض الخدمة).
التخفيف:
من الإصدار 2.17.0 (لـ Java 8)، يتم توسيع سلاسل البحث في الإعدادات فقط بشكل متكرر؛ وفي أي استخدام آخر، يتم حل البحث العلوي فقط، ولا يتم حل أي عمليات بحث متداخلة.
في الإصدارات السابقة، يمكن تخفيف هذه المشكلة من خلال التأكد من أن إعدادات التسجيل الخاصة بك تقوم بما يلي:
في PatternLayout في إعدادات التسجيل، استبدل Context Lookups مثل ${ctx:loginId} أو $${ctx:loginId} بأنماط Thread Context Map (%X، %mdc، أو %MDC).
بخلاف ذلك، في الإعدادات، قم بإزالة المراجع إلى Context Lookups مثل ${ctx:loginId} أو $${ctx:loginId} عندما تكون أصولها من مصادر خارج التطبيق مثل رؤوس HTTP أو إدخال المستخدم.
تحديث - 13-Dec-2021
Log4j (الإصدار 2.16.0 – 2021-12-13) يحتوي على ميزتين محسّنتين:
---------------!!موصى به بشدة للترقية إلى أحدث إصدار متاح حيث يتم تعطيل عمليات البحث عن الرسائل افتراضيًا!!------------
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0
تعطيل JNDI افتراضيًا. يتطلب تعيين log4j2.enableJndi على true للسماح بـ JNDI.
إزالة الدعم لـ Message Lookups بالكامل
تحديث جديد:
------------------CVE-2021-45046-----------------
Apache Log4j2 Thread Context Message Pattern و Context Lookup Pattern معرضان لهجوم رفض الخدمة.
التخفيف:
تخفيف Log4j 1.x: لا يتأثر Log4j 1.x بهذه الثغرة الأمنية.
تخفيف Log4j 2.x: قم بتطبيق إحدى تقنيات التخفيف أدناه.
يجب على مستخدمي Java 8 (أو أحدث) الترقية إلى الإصدار 2.16.0. يجب على المستخدمين الذين يحتاجون إلى Java 7 الترقية إلى الإصدار 2.12.2 عندما يصبح متاحًا (قيد العمل، من المتوقع أن يكون متاحًا قريبًا).
بخلاف ذلك، قم بإزالة فئة JndiLookup من مسار الفئة: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
لاحظ أن ملف JAR log4j-core فقط هو المتأثر بهذه الثغرة. التطبيقات التي تستخدم ملف JAR log4j-api فقط بدون ملف JAR log4j-core لا تتأثر بهذه الثغرة.
------------------CVE-2021-44228-------------------
التخفيف
تخفيف Log4j 1.x: لا يحتوي Log4j 1.x على Lookups لذا فإن المخاطر أقل. التطبيقات التي تستخدم Log4j 1.x تكون معرضة لهذا الهجوم فقط عند استخدامها JNDI في إعداداتها. تم تقديم CVE منفصل (CVE-2021-4104) لهذه الثغرة. للتخفيف: قم بمراجعة إعدادات التسجيل الخاصة بك للتأكد من عدم وجود JMSAppender مهيأ.
إعدادات Log4j 1.x بدون JMSAppender لا تتأثر بهذه الثغرة.
تخفيف Log4j 2.x: قم بتطبيق إحدى تقنيات التخفيف أدناه.
يجب على مستخدمي Java 8 (أو أحدث) الترقية إلى الإصدار 2.16.0.
يجب على المستخدمين الذين يحتاجون إلى Java 7 الترقية إلى الإصدار 2.12.2 عندما يصبح متاحًا (قيد العمل، من المتوقع أن يكون متاحًا قريبًا).
بخلاف ذلك، قم بإزالة فئة JndiLookup من مسار الفئة: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
لاحظ أن ملف JAR log4j-core فقط هو المتأثر بهذه الثغرة. التطبيقات التي تستخدم ملف JAR log4j-api فقط بدون ملف JAR log4j-core لا تتأثر بهذه الثغرة.
1. Apache Log4j:
في الإصدارات >=2.10** و
للإصدارات >=2.0-beta9 و <=2.10.0
2. إصلاح pom.xml:
3. Azure App Service (Windows و Linux):
4. أي تطبيقات معبأة في حاويات:
5. Azure Functions:
6. التصحيح السريع لـ Apache Log4j
7. كيف يجد Defender for Cloud الأجهزة المتأثرة بثغرات Log4j
8. الكشف على Azure Sentinel وسجلات Azure WAF
9. تكوين إضافة Maven لحظر الإصدارات الضعيفة من log4j2 في الإنشاءات المستقبلية
1. Apache Log4j:
CVE-2021-44228: لا تحمي ميزات JNDI في Apache Log4j2 من LDAP المتحكم به من قبل المهاجم ونقاط نهاية JNDI الأخرى ذات الصلة.
الإصدارات المتأثرة: جميع إصدارات log4j-core >=2.0-beta9 و <=2.14.1 لا تحمي ميزات JNDI في Apache Log4j <=2.14.1 المستخدمة في الإعدادات والرسائل والمعلمات من LDAP المتحكم به من قبل المهاجم ونقاط نهاية JNDI الأخرى ذات الصلة. يمكن للمهاجم الذي يمكنه التحكم في رسائل السجل أو معلمات رسائل السجل تنفيذ تعليمات برمجية عشوائية تم تحميلها من خوادم LDAP عند تمكين استبدال البحث عن الرسائل. من Log4j 2.15.0، تم تعطيل هذا السلوك افتراضيًا.
في الإصدارات >=2.10**، يمكن تخفيف هذا السلوك عن طريق تعيين خاصية النظام log4j2.formatMsgNoLookups أو المتغير البيئي LOG4J_FORMAT_MSG_NO_LOOKUPS إلى true. للإصدارات >=2.7 و <=2.14.1، يمكن تعديل جميع أنماط PatternLayout لتحديد محول الرسائل كـ %m{nolookups} بدلاً من %m فقط.
للإصدارات >=2.0-beta9 و <=2.10.0، التخفيف هو إزالة فئة JndiLookup من مسار الفئة: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
2. إصلاح pom.xml:
قم بتحديث التبعية في pom.xml واستبدلها بأحدث إصدار متاح في قسم التبعيات: https://search.maven.org/artifact/org.apache.logging.log4j/log4j/2.15.0/pom