تخفيف Log4J-CVE-2021-44228,CVE-2021-45046,CVE-2021-45105,CVE-2021-44832

يُرجى متابعة هذه الصفحة حيث يكشف فريق Apache Log4j عن المزيد من ثغرات CVE ويصلح المشكلات الأمنية بسرعة كبيرة.

تحديث - 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:

jndiarch

تخفيفات للبيئات المختلفة:

تحديث - 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

 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

<dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.14.1</version>
<!-- استبدل بما يلي لإثبات أنه تم الإصلاح -->            
<!--         <version>2.17.0</version>-->
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.14.1</version>
<!-- استبدل بما يلي لإثبات أنه تم الإصلاح -->       
<!--         <version>2.17.0</version>-->
        </dependency>
    </dependencies>

المرجع: https://github.com/justincormack/log4jpoc/blob/main/pom.xml#L18

3. Azure App Service (Windows و Linux):

إذا أمكن، يجب على العملاء ترقية Log4j إلى الإصدار v2.15.0 وإعادة نشر التطبيقات. هذا هو التخفيف الأساسي الموصى به. إذا لم تتمكن من إعادة نشر تطبيقك، في إصدارات Log4j 2.10 والأحدث، يمكنك تخفيف هذا السلوك عن طريق تعيين خاصية النظام "-Dlog4j2.formatMsgNoLookups=true". في App Service، يمكنك تعيين هذه الخاصية عن طريق إنشاء إعداد تطبيق باسم JAVA_OPTS بقيمة "-Dlog4j2.formatMsgNoLookups=true". يتم تمرير إعداد التطبيق JAVA_OPTS إلى تطبيق Java عند بدء التشغيل. إذا كان لديك بالفعل إعداد التطبيق JAVA_OPTS، فما عليك سوى إلحاق "-Dlog4j2.formatMsgNoLookups=true" بالقيمة الحالية. إذا كنت تستخدم Log4J الإصدار 2.9 أو أقل، فلن يعمل تخفيف خاصية النظام هذا ويجب عليك الترقية إلى v2.15.0.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings <setting-name>="<value>"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"

4. أي تطبيقات معبأة في حاويات

بالنسبة للتطبيقات المعبأة في حاويات، إذا كان إصدار Log4j 2 الذي تستخدمه هو 2.10.0 أو أحدث، فهناك متغير بيئي أو خيار سطر أوامر Java يمكنك استخدامه لتعطيل سلوك الاستبدال غير الآمن. يمكنك إضافة السطر:
```
 ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true
```
مرجع ملف Docker: https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay/blob/master/Dockerfile
إلى ملف Dockerfile الخاص بك، أو يمكنك إضافة العلامة المكافئة "-Dlog4j.formatMsgNoLookups=true" إلى الأمر الذي تقوم بتشغيله في الحاوية، على سبيل المثال:
```
 CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."]
```
يمكنك أيضًا تكوين المتغير البيئي في وقت التشغيل، وهو ما قد يكون أسهل، على سبيل المثال بالنسبة لـ Kubernetes يمكنك إضافة هذه الأسطر إلى التكوين الخاص بك.
```
 spec:
   containers:
   - name: ...
     image: ...
     env:
     - name: LOG4J_FORMAT_MSG_NO_LOOKUPS
       value: "true"
```

5. Azure Functions:

يعتمد تكوين خاصية النظام على اختيارك لخيار الاستضافة: مخصص، متميز، أو استهلاك. كتذكير، التخفيف الأساسي الموصى به هو ترقية Log4J إلى 2.15.0 وإعادة نشر تطبيقك. إذا لم تتمكن من القيام بذلك لأي سبب، فيمكنك تطبيق خاصية النظام.

- وظائف مخصصة ومتميزة:

قم بإنشاء إعداد تطبيق باسم JAVA_OPTS بقيمة "-Dlog4j2.formatMsgNoLookups=true". إذا كان لديك بالفعل إعداد التطبيق JAVA_OPTS، فما عليك سوى إلحاق "-Dlog4j2.formatMsgNoLookups=true" بالقيمة الحالية.

- وظائف الاستهلاك:

Linux: قم بإنشاء إعداد تطبيق باسم "languageWorkers__java__arguments" بقيمة "-Dlog4j2.formatMsgNoLookups=true". Windows: قم بإنشاء إعداد تطبيق باسم "languageWorkers:java:arguments" بقيمة "-Dlog4j2.formatMsgNoLookups=true". **لاحظ أن تحديث إعداد التطبيق سيعيد تشغيل تطبيقات الويب والوظائف الخاصة بك، مما قد يؤثر على أداء البدء البارد. إذا كنت تستخدم Log4J الإصدار 2.9 أو أقل، فلن يعمل تخفيف خاصية النظام هذا ويجب عليك الترقية إلى v2.15.0.

6. التصحيح السريع لـ Apache Log4j

كيف يعمل؟ تقوم هذه الأداة بحقن وكيل Java في عملية JVM قيد التشغيل. يحاول الوكيل تصحيح طريقة lookup() لجميع مثيلات org.apache.logging.log4j.core.lookup.JndiLookup المحملة لإرجاع السلسلة "Patched JndiLookup::lookup()" بشكل غير مشروط. تم تصميم هذا لمعالجة ثغرة تنفيذ التعليمات البرمجية عن بُعد CVE-2021-44228 في Log4j دون إعادة تشغيل عملية Java.

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

Github : https://github.com/corretto/hotpatch-for-apache-log4j2

7. كيف يجد Defender for Cloud الأجهزة المتأثرة بثغرات Log4j

باستخدام المخزون، لديك طريقتان قويتان لتحديد مدى تعرضك:

مخزون البرامج

نتائج تقييم الثغرات

https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/how-defender-for-cloud-finds-machines-affected-by-log4j/ba-p/3037271

8. الكشف على Azure Sentinel وسجلات WAF:

صيد ثغرة Azure WAF Log4j CVE-2021-44228

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AzureDiagnostics/WAF_log4j_vulnerability.yaml

مطابقة Azure WAF لثغرة Log4j (CVE-2021-44228)

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AzureDiagnostics/AzureWAFmatching_log4j_vuln.yaml

9. تكوين إضافة Maven لحظر الإصدارات الضعيفة من log4j2 في الإنشاءات المستقبلية:

تكوين إضافة Maven لوضعه في POM الأصلي الخاص بك لتجنب أي استخدامات لإصدارات log4j2 القديمة، بعضها يخضع لـ RCE CVE-2021-44228 ("Log4Shell")، و CVE-2021-45046، و CVE-2021-45105.

المرجع: https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d

 <!-- تكوين الإضافة لوضعه في POM الأصلي الخاص بك لتجنب أي استخدامات
     لإصدارات log4j2 القديمة، بعضها يخضع لـ RCE CVE-2021-44228
     ("Log4Shell")، و CVE-2021-45046، و CVE-2021-45105. تأكد من التحقق من
     أحدث إصدار من log4j2 على
     https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
...
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>3.0.0</version>
  <executions>
    <execution>
      <id>ban-bad-log4j-versions</id>
      <phase>validate</phase>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <bannedDependencies>
            <excludes>
              <exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
            </excludes>
          </bannedDependencies>
        </rules>
        <fail>true</fail>
      </configuration>
    </execution>
  </executions>
</plugin>
...

المساهمة:

يسرني تلقي المساهمات من المجتمع. إرشادات المساهمة:

-->يرجى عمل PR.

-->يرجى التأكد من تضمين مصدر مرجعي لمزيد من السياق

قد تكون هناك عدة بيئات مختلفة وطرق أخرى للإصلاح، لا تتردد في فتح طلب سحب (PR):

المراجع:

https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/

https://github.com/justincormack/log4jpoc

https://www.rumble.run/blog/finding-log4j/

https://www.veracode.com/blog/research/exploiting-jndi-injections-java

https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay