قبل أسابيع قليلة ، كانت أخبار المشاكل الأمنية في Log4j تقلب العديد من المستخدمين على الشبكة رأسًا على عقب ، وهي واحدة من العيوب التي تم استغلالها كثيرًا والتي وصفها العديد من الخبراء بأنها «الأكثر خطورة في منذ وقت طويل »، من الثغرات التي تم الكشف عنها في الشبكة نتحدث عن بعضها هنا في المدونة وهذه المرة وجدنا خبر آخر.
وكان ذلك قبل أيام قليلة تم نشر الأخبار التي تفيد بأنه تم تحديد ثغرة أمنية أخرى في مكتبة Log4j 2 (المدرجة بالفعل ضمن CVE-2021-45105) والتي ، على عكس المسألتين السابقتين ، تم تصنيفها على أنها خطيرة ، ولكنها ليست حرجة.
المشكلة الجديدة يسمح برفض الخدمة ويتجلى في شكل حلقات وإنهاءات غير طبيعية عند معالجة خطوط معينة.
عالي التأثر يؤثر على الأنظمة التي تستخدم بحث السياق ، مثل $ {ctx: var}، لتحديد تنسيق إخراج السجل.
ال إصدارات Log4j 2.0-alpha1 إلى 2.16.0 تفتقر إلى الحماية ضد العودية غير المنضبط، ماذا سمح للمهاجم بالتلاعب بالقيمة المستخدمة في الاستبدال لإحداث حلقة لا نهاية لها من شأنها أن تنفد من المساحة على المكدس وتتسبب في تعليق العملية. على وجه الخصوص ، حدثت المشكلة عند استبدال قيم مثل "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
وبالإضافة إلى ذلك، وتجدر الإشارة إلى أن باحثي Blumira قد اقترحوا هجومًا على تطبيقات Java المعرضة للخطر التي لا تقبل الطلبات من الشبكات الخارجية ، على سبيل المثال ، أنظمة المطورين أو مستخدمي تطبيقات Java يمكن مهاجمتها بهذه الطريقة.
جوهر الطريقة هو أنه في حالة وجود عمليات Java ضعيفة على نظام المستخدم الذي يقبل اتصالات الشبكة فقط من المضيف المحلي (المضيف المحلي) ، أو يعالج طلبات RMI (استدعاء الطريقة البعيدة ، المنفذ 1099) ، يمكن تنفيذ الهجوم عن طريق تنفيذ كود JavaScript عندما يفتح المستخدم صفحة ضارة في المتصفح. لإنشاء اتصال بمنفذ الشبكة لتطبيق Java في مثل هذا الهجوم ، يتم استخدام WebSocket API ، والتي ، على عكس طلبات HTTP ، لا يتم تطبيق قيود المصدر نفسه (يمكن أيضًا استخدام WebSocket لفحص منافذ الشبكة على المستوى المحلي مضيف لتحديد برامج تشغيل الشبكة المتاحة).
نتائج تقييم ضعف المكتبات المرتبطة بالتبعية مع Log4j المنشورة من قبل Google هي أيضا ذات أهمية. وفقًا لـ Google ، تؤثر المشكلة على 8٪ من جميع الحزم في مستودع Maven Central.
على وجه الخصوص ، تعرضت 35863 حزم Java ذات الصلة بـ Log4j ذات التبعيات المباشرة وغير المباشرة إلى نقاط ضعف. في المقابل ، يتم استخدام Log4j كاعتماد مباشر للمستوى الأول فقط في 17٪ من الحالات ، وفي 83٪ من الحزم التي تغطيها الثغرة الأمنية ، يتم الربط من خلال حزم وسيطة تعتمد على Log4j ، أي. تبعيات المستوى الثاني والأعلى (21٪ - المستوى الثاني ، 12٪ - الثالث ، 14٪ - الرابع ، 26٪ - الخامس ، 6٪ - السادس).
لا تزال وتيرة إصلاح الثغرات الأمنية تترك الكثير مما هو مرغوب فيه ، بعد أسبوع من تحديد الثغرة الأمنية ، من بين 35863 حزمة تم تحديدها ، تم إصلاح المشكلة حتى الآن فقط في 4620 ، أي بنسبة 13٪.
تعد تغييرات الحزمة ضرورية لتحديث متطلبات التبعية واستبدال روابط الإصدار القديم بإصدارات ثابتة من Log4j 2 (تمارس حزم Java الارتباط بإصدار معين ، وليس نطاقًا مفتوحًا يسمح بتثبيت أحدث إصدار).
يعيق القضاء على الثغرة الأمنية في تطبيقات Java حقيقة أن البرامج غالبًا ما تتضمن نسخة من المكتبات قيد التسليم ، ولا يكفي تحديث إصدار Log4j 2 في حزم النظام.
وفي الوقت نفسه ، أصدرت الوكالة الأمريكية لحماية البنية التحتية والأمن السيبراني توجيهًا طارئًا يطلب من الوكالات الفيدرالية تحديد أنظمة المعلومات المتأثرة بثغرة Log4j وتثبيت التحديثات التي تمنع المشكلة. قبل 23 ديسمبر.
من ناحية أخرى ، تم إصدار دليل إرشادي حتى 28 ديسمبر ، حيث كان على المنظمات الالتزام بالإبلاغ عن الأعمال المنجزة. لتبسيط تحديد الأنظمة الإشكالية ، تم إعداد قائمة بالمنتجات التي تم فيها تأكيد ظهور ثغرة أمنية (هناك أكثر من 23 ألف تطبيق في القائمة).
وأخيرا، الجدير بالذكر أنه تم إصلاح الثغرة الأمنية في Log4j 2.17 الذي تم نشره قبل أيام قليلة يوصى والمستخدمون الذين تم تعطيل التحديثات بتنفيذ التحديث المقابل ، بالإضافة إلى حقيقة أن خطر الثغرة الأمنية يتم تخفيفه من خلال حقيقة أن المشكلة تظهر فقط على الأنظمة التي تحتوي على Java 8.
مصدر: https://logging.apache.org/