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