كانت ثغرة Log4shell بمثابة نهاية مناسبة ومذعورة لما كان عامًا صعبًا بالفعل. الآن بعد أن انتهى الذعر الأولي، وهناك بعض الطرق المجربة والمختبرة لاكتشاف الثغرة الأمنية والتخفيف من حدتها - من الضروري التوقف والتفكير في ما حدث في تلك الأسابيع القليلة الماضية من عام 2021. ما الذي سار بشكل جيد وما الذي كان يمكن أن يتحسن. ما هي أفضل طريقة للقيام بذلك من تشريح الجثة؟
نظرة عامة وتأثير ثغرة Log4shell
كانت ثغرة Log4shell نقطة ضعف في وظيفة بحث JNDI في Log4j2، بين الإصدار 2.0 و 2.14. سمح هذا للمهاجم، الذي كان يتحكم في ما تمت طباعته في السجلات (على سبيل المثال، إذا قام الخادم بطباعة رأس HTTP)، بتنفيذ أي كود يحبه.
يوجد Log4j2 في كل مكان بين التطبيقات والمكتبات التي تعتمد عليها، مما يعني أن العديد من التطبيقات كانت تستخدم Log4j2 دون أن تدرك ذلك. حتى التطبيقات التي لم تتم كتابتها بلغة Java غالبًا ما يتم استضافتها في حاويات الويب web containers، مما يعني أنه لا يمكن أن يكون للمشروع أي اعتماد واضح على Log4j2 ولا يزال يتم كشفه. أدى ذلك إلى تأثير هائل عبر جميع الصناعات تقريبًا.
كانت ثغرة Log4shell نقطة ضعف في وظيفة بحث JNDI في Log4j2، بين الإصدار 2.0 و 2.14. سمح هذا للمهاجم، الذي كان يتحكم في ما تمت طباعته في السجلات (على سبيل المثال، إذا قام الخادم بطباعة رأس HTTP)، بتنفيذ أي كود يحبه.
يوجد Log4j2 في كل مكان بين التطبيقات والمكتبات التي تعتمد عليها، مما يعني أن العديد من التطبيقات كانت تستخدم Log4j2 دون أن تدرك ذلك. حتى التطبيقات التي لم تتم كتابتها بلغة Java غالبًا ما يتم استضافتها في حاويات الويب web containers، مما يعني أنه لا يمكن أن يكون للمشروع أي اعتماد واضح على Log4j2 ولا يزال يتم كشفه. أدى ذلك إلى تأثير هائل عبر جميع الصناعات تقريبًا.
السبب الجذري لثغرة Log4shell
لم يكن السبب الجذري حدثًا واحدًا لمشكلة كهذه. شقت الميزة الأصلية طريقها إلى الإصدار دون فحص أمني. لا شك أن المساهمين الأساسيين core contributors في Log4j2 كانوا يفكرون في كيفية تحسين عمليات تقييم الأمان الخاصة بهم.
المكتبات مثل Log4j2 كبيرة ومعقدة أيضًا، مما يعني أن الغالبية العظمى من الفرق لم تكن تستخدم وظيفة بحث JNDI الضعيفة. شقت هذه الشفرة الخبيثة طريقها بسبب الطبيعة المتجانسة لهذه التبعيات. قد يكون اتباع نهج أكثر قابلية للتركيب لوظيفة Log4j2 قد قلل بشكل كبير من التأثير المحتمل لثغرة Log4j2. ومع ذلك، كان سيأتي على حساب سهولة الاستخدام لهؤلاء المهندسين الذين اعتمدوا عليه بالفعل.
إذن، ما الذي سار بشكل جيد؟
كانت استجابة الصناعة فيما يتعلق بثغرة Log4shell فورية وفعالة. قامت مجتمعات المصادر المفتوحة بإنشاء الموارد، ومشاركات المدونة المسودة، والتصحيحات المنفذة. مكّن هذا الجهد المؤسسات من البقاء في صدارة المنحنى والتخفيف بشكل استباقي من المشكلات بدلاً من الرد المحموم.
بالإضافة إلى ذلك، كان المساهمون الأساسيون في مكتبة Log4j2 مجتهدين بشكل لا يصدق في إصداراتهم. بينما كانت رحلة وعرة بعض الشيء (المزيد حول هذا لاحقًا)، سرعان ما تكررت لإصدار معقول كان متوافقًا مع الإصدارات السابقة مع جميع الوظائف باستثناء الوظائف الضعيفة.
تتحدث هذه الإيجابيات عن الجمال الأنيق للمجتمعات مفتوحة المصدر التي تركز على الفلسفة من الخبراء الذين يعملون لدى مجموعة هائلة من المنظمات. في بعض الأحيان يرتكبون أخطاء، مثل أي جهد هندسي، ولكن يتم اكتشاف هذه الأخطاء وإصلاحها بسرعة.
ما الذي لم يتم بشكل جيد؟
المشكلة الواضحة في ضعف Log4shell هي طبيعتها. تم تخزين الكود في آلاف التطبيقات، وكان كل واحد بحاجة إلى التخفيف من حدته واختباره ونشره في الإنتاج. بالنسبة لبعض المنظمات، كان هذا طبيعيًا. بالنسبة للآخرين، كانوا لا يزالون يعملون في دورات إطلاق بطيئة، وكان هذا التغيير المفاجئ بمثابة اضطراب كبير في طريقة عملهم.
كان هناك أيضًا بعض الالتباس حول مسار التخفيف الصحيح أثناء الحادث مع نمو فهم ثغرة Log4shell. تحقق من الجدول الزمني أدناه للحصول على نكهة لهذا الالتباس. هذا يعني أن المنظمات التي كانت نشطة اضطرت بعد ذلك إلى العودة والبدء من جديد.
الجدول الزمني للأحداث Timeline of events
9 ديسمبر 2021
تم العثور على ثغرة Log4Shell الأصلية. تم تقديم المشورة للتخفيف من هذه المشكلة عن طريق تعيين LOG4J_FORMAT_MSG_NO_LOOKUPS أو تعيين علامة التكوين المقابلة لها. في الوقت نفسه، تم إصدار الإصدار 2.15 الذي عطّل هذه الوظيفة افتراضيًا.
14 ديسمبر 2021
تم العثور على ثغرة أمنية vulnerability ثانية في الإصدار 2.15 من Log4j. كانت هذه ثغرة "رفض الخدمة denial of service"، مما يمكن العوامل الخبيثة من إبطاء الأنظمة المستهدفة وإيقافها في نهاية المطاف. تم تغيير النصيحة من تحديد قيمة التكوين إلى ترقية، إلى الإصدار 2.16 الذي تم إصداره حديثًا. تم تصنيف CVE هذا في البداية نسبيًا منخفض، 3.7 / 10، ولكن تم إعادة تسجيله عند 9.8 / 10، مما يعني أن المنظمات التي اتخذت قرارًا معقولاً قائمًا على المخاطر، أُجبرت على التمحور مرة أخرى والترحيل.
17 ديسمبر 2021
تم العثور على ثغرة ثالثة في الإصدار 2.16. كان هذا هجوم "رفض الخدمة" آخر كان له تأثير مشابه للثغرة الأمنية السابقة. لتقليل هذا، تم إصدار الإصدار 2.17. بسبب الدرجة العالية نسبيًا الممنوحة ل CVE 7.5 / 10، تم نصح المنظمات بالانتقال إلى الإصدار 2.17 في أقرب وقت ممكن.
28 ديسمبر 2021
تم العثور على ثغرة رابعة في الإصدار 2.17. كانت هذه الثغرة أقل حدة من سابقاتها (6.6 / 10) وتطلبت بالفعل اختراق أجزاء أخرى من النظام المستهدف. تطلبت هذه الثغرة الأمنية الأخيرة أن يتم تحميل التكوين من خادم بعيد، مما يعني أنه لن يكون له تأثير واسع النطاق. أدى ذلك إلى إصدار 2.17.1.
إذا ما هو التالي؟
هناك بعض الأسئلة الجادة التي يجب طرحها. أولاً، طريقة إدارة التبعية method of dependency management مناسبة للغرض في عالم الخدمات المصغرة، حيث يتم نسخ نفس التبعية عبر عشرات أو مئات أو ربما آلاف الحالات
ثانيًا، هل هناك حاجة للانتقال إلى مكتبات أصغر قابلة للتكوين بدلاً من مكتبات متجانسة توفر قدرًا كبيرًا من الوظائف غير المرغوب فيها؟ لم يكن معظم ضحايا هذه الثغرة الأمنية يستخدمون كود بحث JNDI في المقام الأول. يهرب المهندسون بانتظام في السيول من التعليمات البرمجية غير الضرورية والتي من المحتمل أن تكون خطرة إلى ثنائياتهم، خاصة للغات مثل Java التي تفضل في كثير من الأحيان التبعيات الكبيرة التي يمكن تكوينها بشكل كبير.
أخيرًا، يجب أن يأتي قدر من القبول مع هذه الانتقادات. سوف تحدث ثغرات يوم الصفر. إنها نتيجة حتمية لمشاركة التعليمات البرمجية، والتي تستحق المخاطرة بلا شك. يتمثل التحدي الذي تواجهه في تحديد العمليات والتقنيات والأدوات التي تريد تنفيذها لتمكنك من الانتقال إلى المرحلة التالية.
الحيلة هي الاستجابة بسرعة، وهناك أشياء يمكننا القيام بها لرفع انتباهنا إلى نقاط الضعف على الفور.
عمليات المسح التلقائي لنقاط الضعف Log4shell
يمكنك استخدام مكتبات مثل Snyk لاكتشاف نقاط الضعف في تبعياتك تلقائيًا. يمكنك أيضًا تكوين هذا لفشل خطوط أنابيب CI / CD الخاصة بك تلقائيًا إذا كنت ترغب في منع حتى نشر الثغرات الأمنية. هذه آلية قوية للغاية ولكنها قوية لمنع إصدار المشكلات.
اتبع خلاصة CVE
تُعد خلاصة CVE على Twitter طريقة رائعة يمكنك من خلالها متابعة الثغرات الأمنية فور إطلاقها. قد تكون هذه معلومات كثيرة عليك معالجتها، لكنك ستعرف تلك الفظيعة من خلال كل الإعجابات والتغريدات.
الكل في الكل All in all
لقد كانت أسابيع قليلة معقدة بالنسبة للفرق الهندسية في جميع أنحاء العالم. ومع ذلك، إذا أثبتت هذه الثغرة الأمنية أي شيء، فإن مجتمع المصادر المفتوحة يكون مرنًا في مواجهة الفشل، ومستجيب للغاية، ومجتهد. في حين أن هذه كانت نقطة ضعف خطيرة ستظل بلا شك باقية لسنوات قادمة، فقد تم تخفيفها واحتوائها بسرعة من خلال الاستجابة السريعة من مجتمع من المهندسين المركّز والاجتهاد.
