ثغرة Log4j، أو "Log4Shell"، تعتبر واحدة من أكثر العيوب البرمجية كارثية على الإطلاق. وقد أصلحت شركة Apache الخلل في ديسمبر 2021، إلا أنها تظل مصدر قلق للفرق الأمنية. في الواقع، لا يزال من بين أكثر الثغرات الأمنية استغلالاً.

يستمر Log4Shell لأن حزمة برامج Apache Log4j 2 التي تؤثر عليها هي إحدى مكتبات التسجيل الأكثر استخدامًا في العالم. من المتوقع أن يستغرق العثور على كل مثيل لـ Log4Shell وإصلاحه عقدًا من الزمن، وفقًا لـ وزارة الأمن الداخلي الأمريكية.

في هذه الأثناء، يمكن لفرق الأمان اتخاذ بعض الخطوات لتسريع عملية تخفيف Log4Shell ومعالجتها في شبكاتهم. 

فهم نقاط الضعف في Log4j  

قبل الخوض في كيفية اكتشاف Log4Shell وتصحيحه، من المهم فهم طبيعة الثغرة الأمنية.

log4j هو برنامج تسجيل مفتوح المصدر (تحتفظ به مؤسسة Apache Software Foundation) يقوم بتسجيل المعلومات والأحداث في البرنامج. Log4j ليس برنامجًا مستقلاً ولكنه عبارة عن حزمة من التعليمات البرمجية التي يمكن للمطورين توصيلها بتطبيقات Java الخاصة بهم. يتم استخدام إطار عمل Apache Log4j في بعض أكبر الخدمات على الويب، بدءًا من البنية التحتية للشبكة مثل Amazon Web Services (AWS) وحلول Cisco إلى التطبيقات الشائعة مثل Twitter وMinecraft.

تعاني بعض إصدارات Log4j — على وجه التحديد، Log4j 2.17.0 والإصدارات الأقدم — من ثغرات أمنية خطيرة. والأخطر منهم هو Log4Shell (CVE-2021-44228؛ تصنيف CVSS: 10)، تنفيذ التعليمات البرمجية عن بعد (RCE) الضعف في اليوم صفر تم العثور عليه في إصدارات Log4j 2.14.1 والإصدارات السابقة. 

Log4Shell هو نتيجة لكيفية تعامل الإصدارات الضعيفة من Log4j مع واجهة Java للتسمية والدليل (JNDI)، API التي تستخدمها تطبيقات Java للوصول إلى الموارد المستضافة على خوادم خارجية. يمكن للجهات الفاعلة في مجال التهديد السيطرة بشكل كامل تقريبًا على الأنظمة الضعيفة عن طريق إرسال أوامر بحث JNDI ضارة من خلال Log4j. تخدع هذه الأوامر التطبيق لتشغيل تعليمات برمجية عشوائية يمكنها فعل أي شيء تقريبًا: سرقة البيانات، التثبت الفدية، وإيقاف الأجهزة دون الاتصال بالإنترنت، والمزيد.

هجمات Log4Shell

Log4Shell نموذجي هجوم إلكتروني يعمل مثل هذا: 

1. يقوم المتسلل بإعداد خادم باستخدام بروتوكول شائع، مثل بروتوكول الوصول إلى الدليل الخفيف (LDAP) أو نظام اسم المجال (DNS). 
2. يقوم المتسلل بتخزين البرامج الضارة أو بعض الحمولات الضارة الأخرى على الخادم.
3. يرسل المتسلل بحث JNDI إلى تطبيق يقوم بتشغيل Log4j، ويوجه التطبيق إلى خادم المتسلل. 
4. يؤدي بحث JNDI إلى اتصال التطبيق بخادم المتسلل، وتنزيل الحمولة الضارة، وتنفيذ التعليمات البرمجية الضارة. 

ثغرات Log4j ذات الصلة وكيفية استغلالها

بينما كان Apache يعمل على تصحيح Log4Shell، حدد الباحثون الأمنيون عددًا من العيوب ذات الصلة في بعض إصدارات Log4j. وتشمل هذه: 

• CVE-2021-45046 يمكّن المتسللين من إرسال عمليات بحث JNDI ضارة إلى الأنظمة التي تستخدم إعدادات غير افتراضية معينة، حتى لو قامت هذه الأنظمة بإصلاح Log4Shell. موجود في إصدارات Log4j 2.15 والإصدارات الأقدم.  
• CVE-2021-45105 تمكن المتسللين من إطلاق هجمات الحرمان من الخدمة عن طريق إرسال رسائل ضارة إلى Log4j. موجود في إصدارات Log4j 2.16 والإصدارات الأقدم. 
• CVE-2021-44832 هي ثغرة أمنية في تنفيذ التعليمات البرمجية عن بعد. يعد هذا الخلل أقل أهمية من Log4Shell لأن المتسللين يحتاجون إلى الحصول على أذونات مرتفعة قبل أن يتمكنوا من استغلاله. موجود في إصدارات Log4j 2.17 والإصدارات الأقدم.  

كيفية اكتشاف ثغرات Log4j   

قد يكون من الصعب العثور على كل مثيل ضعيف لـ Log4j في الشبكة. يظهر Log4j في تقدير ملايين التطبيقاتمما يعني أن فرق الأمن لديها الكثير من الأصول التي يتعين عليها فحصها. 

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

ومع ذلك، يمكن لفرق الأمان اكتشاف ثغرات Log4j باستخدام التكتيكات والأدوات المناسبة.  

ما الذي تبحث عنه

كل إصدار من Log4j 2 من 2.0-beta9 إلى 2.17 يكون عرضة لـ Log4Shell أو أي عيب ذي صلة. وبعبارة أخرى، يجب على فرق الأمان العثور على أي إصدار من Log4j أقدم من 2.17.1 ومعالجته.

Log4Shell والعيوب المرتبطة به موجودة فقط في ملفات "Log4j-core"، والتي توفر الوظيفة الأساسية لـ Log4j. العيوب غير موجودة في ملفات "Log4j-api"، التي تتحكم في الواجهة بين التطبيقات وأدوات تسجيل Log4j.

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

ضمن تطبيقات Java، غالبًا ما يتم تجميع المكتبات مثل Log4j في ملفات Java Archive، أو "ملفات JAR". يمكن أن تحتوي ملفات JAR على ملفات JAR أخرى، والتي بدورها يمكن أن تحتوي على ملفات JAR الخاصة بها، وهكذا. للعثور على كافة الإصدارات الضعيفة من Log4j، يجب على فرق الأمان فحص جميع مستويات ملفات JAR، وليس فقط ملفات المستوى الأعلى.

كيف تجدها 

يوصي الخبراء باستخدام مجموعة من التقنيات للعثور على ثغرات Log4j.

عمليات البحث اليدوية. يمكن لفرق الأمان البحث يدويًا عن عيوب Log4j. يمكنهم استخدام أدوات التطوير مثل Apache Maven لإنشاء أشجار التبعية التي تحدد جميع التبعيات في التطبيق، أو يمكنهم استخدام أدوات خارجية استخبارات التهديد لتحديد الأصول المتضررة. على سبيل المثال، قامت وكالة الأمن السيبراني وأمن البنية التحتية (CISA) بتجميع قائمة من البرامج المعروفة بأنها تعاني من Log4Shell. القائمة متاحة على جيثب.

في أنظمة التشغيل Linux وMicrosoft Windows وmacOS، يمكن لفرق الأمان البحث في دلائل الملفات عن مثيلات Log4j باستخدام واجهة سطر الأوامر.

أدوات فحص الثغرات الأمنية. بعد اكتشاف Log4Shell، أصدرت بعض المؤسسات أدوات مجانية مصممة للعثور على ثغرات Log4j. الامثله تشمل Palantir's Log4j-sniffer و  الماسح الضوئي لمركز التنسيق CERT، من بين عدة آخرين.

على الرغم من أن الماسحات الضوئية المتخصصة لا تزال متاحة، إلا أن العديد من الحلول الأمنية القياسية مثل ماسحات الضعف, إدارة سطح الهجوم منصات (ASM) و الكشف عن نقطة النهاية والاستجابة لها يمكن لحلول (EDR) الآن اكتشاف الثغرات الأمنية في Log4j.

نظرًا لأن Log4Shell يمكنه الاختباء عميقًا في سلاسل التبعية، فقد تقوم فرق الأمان بتكملة عمليات الفحص الآلي بمزيد من الأساليب العملية، مثل اختبارات الاختراق.

صيد التهديد. وفقًا لـ CISAمن المعروف أن المهاجمين يستخدمون Log4Shell لاقتحام الشبكة ثم تصحيح الأصول التي قاموا باختراقها لتغطية مساراتهم. ولهذا السبب، يوصى بأن تفترض فرق الأمان أن الاختراق قد حدث بالفعل مطاردة بنشاط بحثًا عن علامات استغلال Log4Shell.

أدوات الأمن السيبراني مثل المعلومات الأمنية وإدارة الأحداثحلول t (SIEM) و الكشف والاستجابة الممتدة يمكن أن تساعد الأنظمة الأساسية (XDR) في اكتشاف الأنشطة غير الطبيعية المرتبطة بـ Log4Shell، مثل إدخالات السجل الغريبة أو أنماط حركة المرور المشبوهة. يجب أن تبدأ فرق الأمن بكامل طاقتها استجابة الحادث وإجراءات التحقيق بحثًا عن أي تلميح محتمل لـ Log4Shell، نظرًا لمدى خطورة عواقب الهجوم.

كيفية إصلاح الثغرات الأمنية في Log4j

لدى فرق الأمان بعض الخيارات عند معالجة الثغرات الأمنية في Log4j.

أفضل حالة: تصحيح الأنظمة الضعيفة  

للمعالجة الكاملة لـ Log4Shell والعيوب ذات الصلة، يجب على المؤسسات تحديث كافة مثيلات Log4j في شبكاتها إلى الإصدار الأحدث (أو على الأقل إلى الإصدار 2.17.1). تعمل أحدث الإصدارات من Log4j على إزالة الوظائف التي يمكن للمهاجمين استغلالها، كما أنها تزيل الدعم للبروتوكولات التي يتم إساءة استخدامها بشكل شائع مثل LDAP.

لا يوجد تصحيح واحد متاح على مستوى النظام، كما أن تحديث Java بحد ذاته لا يعالج المشكلة. يجب على فرق الأمان تحديث كل مثيل لـ Log4j في كل الأصول المتأثرة. 

تدابير التخفيف الأخرى

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

منع عمليات البحث عن الرسائل في التطبيقات الضعيفة. يستخدم المهاجمون ميزة Log4j تسمى "بدائل البحث عن الرسائل" لإرسال أوامر ضارة إلى التطبيقات الضعيفة. يمكن لفرق الأمان عدم السماح بهذه الوظيفة يدويًا عن طريق تغيير خاصية النظام "Log4j2.formatMsgNoLookups" إلى "true" أو تعيين قيمة متغير البيئة "LOG4J_FORMAT_MSG_NO_LOOKUPS" إلى "true".  

على الرغم من أن إزالة وظيفة استبدال البحث عن الرسائل تجعل من الصعب على المهاجمين الهجوم، إلا أنها ليست مضمونة. لا يزال بإمكان الجهات الفاعلة الضارة استخدام CVE-2021-45046 لإرسال عمليات بحث JNDI ضارة إلى التطبيقات ذات الإعدادات غير الافتراضية.

إزالة فئة JNDIlookup من التطبيقات الضعيفة. في Log4j، تتحكم فئة JNDIlookup في كيفية معالجة المُسجل لعمليات بحث JNDI. إذا تمت إزالة هذه الفئة من دليل الفئات في Log4j، فلن يعد من الممكن إجراء عمليات بحث JNDI.

أباتشي يلاحظ أنه يمكن استخدام الأمر التالي لإزالة فئة JNDIlookup من التطبيقات الضعيفة:   

zip -q -d Log4j-core-*.jar org/Apache/logging/Log4j/core/lookup/JndiLookup.class

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

منع حركة مرور هجمات Log4Shell المحتملة. يمكن لفرق الأمن استخدامها جدران حماية تطبيقات الويب (واف)، أنظمة كشف ومنع التسلل (IDPS) وEDRs وأدوات الأمن السيبراني الأخرى لاعتراض حركة المرور من وإلى الخوادم التي يتحكم فيها المهاجم عن طريق حظر البروتوكولات شائعة الاستخدام مثل LDAP أو RMI. يمكن لفرق الأمن أيضًا الحظر عناوين IP المرتبطة بالهجمات أو السلاسل التي يستخدمها المهاجمون عادةً في الطلبات الضارة، مثل "jndi" و"ldap" و"rmi".

ومع ذلك، يمكن للمهاجمين تجاوز هذه الدفاعات باستخدام بروتوكولات وعناوين IP جديدة أو تشويش السلاسل الضارة.

الحجر الصحي على الأصول المتضررة. إذا فشل كل شيء آخر، فيمكن لفرق الأمان عزل الأصول المتأثرة أثناء انتظار التصحيح. إحدى الطرق للقيام بذلك هي وضع الأصول المعرضة للخطر في جزء شبكة معزول لا يمكن الوصول إليه مباشرة من الإنترنت. يمكن وضع WAF حول قطاع الشبكة هذا لتوفير حماية إضافية.

الحفاظ على Log4Shell في الخليج

أحد الأشياء الصعبة المتعلقة بمعالجة Log4Shell هو أنه لا يظل مُصححًا دائمًا. في نوفمبر 2022، تم الإبلاغ عنها أن 29% من الأصول التي لا تزال عرضة لهجوم Log4Shell كانت "متكررة"، مما يعني أنه تم تصحيحها، ولكن الخلل عاد للظهور مرة أخرى. تحدث التكرارات عندما يستخدم المطورون عن طريق الخطأ مكتبات البرامج التي تحتوي على إصدارات غير مُصححة من Log4j لإنشاء التطبيقات أو تحديثها.

بينما يمكن للمطورين فحص أطر العمل التي يستخدمونها عن كثب، فمن السهل تفويت الإصدارات الضعيفة من Log4j عندما تكون موجودة على عدة مستويات في ملفات JAR.

التنفيذ رسمي إدارة الضعف و إدارة التصحيح يمكن للبرامج أن تقدم لفرق الأمان طريقة أكثر فعالية لمراقبة الأصول من أجل عودة ثغرات Log4j. يمكن أن يساعد فحص الثغرات الأمنية واختبار الاختراق بانتظام في اكتشاف الثغرات الأمنية الجديدة بسرعة، مثل Log4Shell أو غير ذلك. تضمن إدارة التصحيح إغلاق الثغرات الأمنية الجديدة بمجرد قيام البائعين بإصدار الإصلاحات.   

مزيد من المساعدة في مكافحة Log4Shell ونقاط الضعف الأخرى في يوم الصفر

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

يقوم IBM Security® QRadar® EDR، المعروف سابقًا باسم ReaQta، بمعالجة تهديدات نقاط النهاية المعروفة وغير المعروفة في الوقت الفعلي تقريبًا باستخدام التشغيل الآلي الذكي سهل الاستخدام الذي يتطلب القليل من التفاعل البشري أو لا يتطلب أي تفاعل بشري. باستخدام QRadar EDR، يمكن للمحللين اتخاذ قرارات سريعة ومستنيرة واستخدام إدارة التنبيهات الآلية للتركيز على التهديدات الأكثر أهمية. تعمل إمكانات الذكاء الاصطناعي المتقدمة للتعلم المستمر والواجهة سهلة الاستخدام على إعادة السيطرة لموظفي الأمن وتساعد في حماية استمرارية الأعمال.

اكتشف IBM Security QRadar EDR