تُعَد ثغرة Log4j، أو "Log4Shell"، واحدة من أخطر العيوب البرمجية على الإطلاق. على الرغم من أن Apache قد أصلحت الثغرة في ديسمبر 2021، فإنها لا تزال مصدر قلق لفِرق الأمن. وفي الواقع، لا تزال Log4j تُعَد من أكثر الثغرات الأمنية استغلالًا حتى اليوم.
يستمر وجود ثغرة Log4Shell؛ لأن حزمة برامج Apache Log4j 2 المتأثرة بها تُعَد واحدة من أكثر مكتبات تسجيل الأحداث استخدامًا في العالم. وفقًا لوزارة الأمن الداخلي الأمريكية، من المتوقع أن يستغرق العثور على كل حالة من Log4Shell وإصلاحها نحو عقد من الزمن.
في هذه الأثناء، يمكن لفرق الأمن اتخاذ بعض الإجراءات لتسريع التخفيف من ثغرة Log4Shell ومعالجتها في شبكاتهم.
انضم إلى قادة الأمن الإلكتروني الذين يعتمدون على الرسالة الإخبارية Think للحصول على أخبار مُنتقاة عن الذكاء الاصطناعي والأمن السيبراني والبيانات والأتمتة. تعلم بسرعة من برامج تعليمية وشروحات يقدّمها خبراء - تُرسَل مباشرة إلى بريدك الإلكتروني. راجع بيان الخصوصية لشركة IBM.
قبل التطرق إلى كيفية اكتشاف ثغرة 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 الإلكترونية النموذجية على النحو التالي:
بينما عملت Apache على تصحيح ثغرة Log4Shell، اكتشَف باحثو الأمن عددًا من الثغرات المرتبطة ببعض إصدارات Log4j. ويشمل ذلك ما يلي:
قد يكون من الصعب العثور على كل مثيل ضعيف من Log4j في الشبكة. يظهر Log4j في ما يُقدَّر بملايين التطبيقات، ما يعني أن فرق الأمن لديها العديد من الأصول التي يجب فحصها.
علاوةً على ذلك، غالبًا ما يكون Log4j موجودًا كتبعية غير مباشرة. وهذا يعني أنه لا يكون مضمَّنًا مباشرةً في التعليمات البرمجية المصدر للأصل، بل يظهر كاعتماد على حزمة برمجية أو تكامل يعتمد عليه الأصل. تُشير تقارير Google إلى أن معظم مثيلات 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، أو ما يُعرف باسم "JAR files". يمكن أن تحتوي ملفات JAR على ملفات JAR أخرى، والتي بدورها قد تحتوي على ملفات JAR إضافية، وهكذا. للعثور على جميع إصدارات Log4j المعرضة للخطر، يجب على فرق الأمن فحص جميع مستويات ملفات JAR وليس الملفات العليا فقط.
يوصي الخبراء باستخدام مجموعة من التقنيات للعثور على الثغرات الأمنية في Log4j.
عمليات البحث اليدوية. يمكن لفرق الأمان البحث يدويًا عن ثغرات Log4j. وبإمكانهم استخدام أدوات التطوير مثل Apache Maven لإنشاء أشجار تبعيات تعمل على ربط جميع التبعيات في التطبيق، أو يمكنهم استخدام استعلامات التهديدات الخارجية لتحديد الأصول المتأثرة. على سبيل المثال، تمكَّنت وكالة الأمن الإلكتروني وأمن البنية التحتية (CISA) من تجميع قائمة بالبرامج المعروفة بأنها تعاني من Log4Shell. وهذه القائمة متوفرة على GitHub.
على أنظمة التشغيل Linux وMicrosoft Windows وmacOS، يمكن لفرق الأمن البحث عن مثيلات Log4j في دلائل الملفات باستخدام واجهة سطر الأوامر.
أدوات فحص الثغرات الأمنية. بعد اكتشاف Log4Shell، أصدرت بعض المؤسسات أدوات مجانية مصممة للعثور على ثغرات Log4j الأمنية. ومن الأمثلة على ذلك Log4j-sniffer من Palantir وأداة الفحص التابعة لمركز CERT Coordination Center، من بين أدوات كثيرة أخرى.
رغم توفُّر أدوات الفحص المتخصصة، يمكن للعديد من حلول الأمن القياسية مثل أدوات فحص الثغرات الأمنية، ومنصات إدارة سطح الهجوم (ASM)، وحلول اكتشاف نقاط النهاية والاستجابة لها (EDR) اكتشاف ثغرات Log4j الأمنية الآن.
نظرًا لأن Log4Shell قد يختبئ عميقًا في سلاسل الاعتماديات، قد تعمل فرق الأمن على تكملة عمليات الفحص المؤتمتة بأساليب أكثر عملية، مثل اختبارات الاختراق.
صيد التهديدات. بحسب CISA، يستخدم المهاجمون Log4Shell لاختراق الشبكة، ثم يصححون الأصل الذي تم اختراقه لإخفاء آثارهم. لهذا السبب، يُنصح أن تفترض فرق الأمن حدوث خرق بالفعل وأن تُجري عمليات صيد نشطة للبحث عن أي دلائل على استغلال Log4Shell.
يمكن لأدوات الأمن الإلكتروني مثل حلول إدارة المعلومات والأحداث الأمنية (SIEM) ومنصات الكشف والاستجابة الموسَّعة (XDR) المساعدة على اكتشاف النشاط غير الطبيعي المرتبط بـ Log4Shell، مثل السجلات غير المعتادة أو أنماط حركة المرور المشبوهة. يجب على فرق الأمن بدء إجراءات الاستجابة للحوادث والتحقيقات بشكل كامل عند ظهور أي علامة محتملة على Log4Shell، نظرًا لخطورة تبعات الهجوم.
لدى فرق الأمن عدة خيارات عند التعامل مع ثغرات Log4j.
لضمان معالجة كاملة لثغرة Log4Shell والثغرات المرتبطة بها، يجب على المؤسسات تحديث جميع نسخ Log4j في شبكاتها إلى أحدث إصدار، أو على الأقل إلى الإصدار 2.17.1. الإصدارات الأخيرة من Log4j تزيل الوظائف التي يمكن للمهاجمين استغلالها، كما أنها تُلغي دعم البروتوكولات التي يُساء استخدامها عادةً مثل LDAP.
لا يوجد تصحيح واحد يغطي النظام بأكمله، وتحديث Java بحد ذاته لا يعمل على حل المشكلة. يجب على فرق الأمن تحديث كل نسخة من Log4j في كل أصل متأثر.
يتفق باحثو الأمن على أن التصحيح هو الحل الأمثل. إذا لم يكن التصحيح ممكنًا، فيمكن للمؤسسات استخدام خطوات تخفيف أخرى لتقليل فرص الهجوم.
منع البحث عن الرسائل في التطبيقات المعرضة للخطر. يستغل المهاجمون ميزة بدائل البحث عن الرسائل في Log4j والتي تُعرَف باسم Message Lookup Substitutions لإرسال أوامر خبيثة إلى التطبيقات الضعيفة. يمكن لفرق الأمن تعطيل هذه الوظيفة يدويًا عن طريق تغيير خاصية النظام "Log4j2.formatMsgNoLookups" إلى "true"، أو ضبط متغيّر البيئة "LOG4J_FORMAT_MSG_NO_LOOKUPS" على "true".
رغم أن إزالة وظيفة استبدالات استعلام الرسائل تجعل الهجمات أصعب على المهاجمين، فإنها ليست حلًا مضمونًا بالكامل. ما زال بإمكان الجهات الخبيثة استغلال CVE-2021-45046 لإرسال استعلامات JNDI خبيثة إلى التطبيقات التي تستخدم إعدادات غير افتراضية.
إزالة فئة JNDilookup من التطبيقات الضعيفة. في Log4j، تتحكم فئة JNDIlookup في كيفية تعامل أداة التسجيل مع استعلامات JNDI. إذا تمت إزالة هذه الفئة من دليل فئات Log4j، فلن يكون من الممكن إجراء استعلامات JNDI.
تشير Apache إلى أنه يمكن استخدام الأمر التالي لإزالة فئة JNDIlookup من التطبيقات المعرضة للخطر:
zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class
رغم أن هذه الطريقة أكثر فاعلية من تعطيل استبدالات استعلام الرسائل، فإنها لا تمنع المهاجمين من شنّ محاولات استغلال أخرى، مثل التسبب في هجمات حجب الخدمة عبر الاستعلامات المتكررة.
حظر حركة مرور هجمات Log4Shell المحتملة. يمكن لفرق الأمن استخدام جدران حماية تطبيقات الويب (WAFs)، وأنظمة كشف التسلل ومنعه (IDPS)، وحلول EDR، وأدوات الأمن الإلكتروني الأخرى لاعتراض حركة المرور من وإلى خوادم المهاجمين عن طريق حظر البروتوكولات الشائعة الاستخدام مثل LDAP أو RMI. يمكن لفرق الأمان أيضًا حظر العناوين المرتبطة بالهجمات أو السلاسل التي يستخدمها المهاجمون عادةً في الطلبات الضارة، مثل "jndi" و"ldap" و"rmi".
ومع ذلك، يمكن للمهاجمين الالتفاف على هذه الدفاعات باستخدام بروتوكولات وعناوين IP جديدة أو تعتيم السلاسل الضارة.
عزل الأصول المتأثرة. إذا فشل كل شيء آخر، يمكن لفرق الأمان عزل الأصول المتأثرة أثناء انتظار التصحيح. تتمثل إحدى طرق القيام بذلك في وضع الأصول المعرضة للخطر في جزء معزول من الشبكة لا يمكن الوصول إليه مباشرةً من الإنترنت. يمكن وضع WAF حول مقطع الشبكة هذا لمزيد من الحماية.
من الأمور المعقدة في معالجة Log4Shell أنه لا يبقى دائمًا مصحَّحًا بعد التحديث. في نوفمبر 2022، أفادت شركة Tenable أن 29% من الأصول التي لا تزال عرضة لخطر Log4Shell كانت "تكرارات"، ما يعني أنه تم تصحيحها، لكن الخلل عاد للظهور. تحدث التكرارات عندما يستخدم المطورون مكتبات البرامج التي تحتوي على إصدارات غير مصحَّحة من Log4j عن طريق الخطأ لإنشاء التطبيقات أو تحديثها.
رغم أن المطورين يمكنهم فحص أطر العمل التي يستخدمونها بدقة أكبر، فإنه من السهل تفويت نسخ Log4j الضعيفة عندما تكون متواجدة على عدة مستويات عميقة داخل ملفات JAR.
يمكن أن يوفر تنفيذ برامج رسمية لإدارة الثغرات الأمنية وإدارة التصحيحات لفرق الأمن طريقة أكثر فاعلية لمراقبة الأصول لرصد عودة ثغرات Log4j. ويمكن أن يساعد الفحص المنتظم للثغرات الأمنية واختبار الاختراق على اكتشاف الثغرات الأمنية الجديدة بسرعة، Log4Shell أو غيرها. تضمن إدارة التصحيح إغلاق الثغرات الأمنية الجديدة بمجرد إصدار البائعين للإصلاحات.