خلال الأيام الماضية على شبكة الإنترنت كان هناك الكثير من الحديث عن ضعف Log4j التي تم فيها اكتشاف نواقل هجوم مختلفة وتم أيضًا تصفية العديد من الثغرات الوظيفية من أجل استغلال الثغرة الأمنية.
تكمن خطورة الأمر في أن هذا إطار شائع لتنظيم التسجيل في تطبيقات Java.، والذي يسمح بتنفيذ تعليمات برمجية عشوائية عند كتابة قيمة منسقة بشكل خاص في التسجيل بالتنسيق "{jndi: URL}". يمكن تنفيذ الهجوم على تطبيقات Java التي تسجل القيم التي تم الحصول عليها من مصادر خارجية ، على سبيل المثال من خلال عرض القيم الإشكالية في رسائل الخطأ.
وعليه يقوم المهاجم بعمل طلب HTTP على نظام مستهدف ، والذي يقوم بإنشاء سجل باستخدام Log4j 2 والتي تستخدم JNDI لتقديم طلب إلى الموقع الذي يتحكم فيه المهاجم. ثم تتسبب الثغرة الأمنية في وصول العملية المستغلة إلى الموقع وتنفيذ الحمولة. في العديد من الهجمات التي تمت ملاحظتها ، فإن المعلمة التي تنتمي إلى المهاجم هي نظام تسجيل DNS ، يهدف إلى تسجيل طلب على الموقع لتحديد الأنظمة المعرضة للخطر.
كما قال زميلنا إسحاق:
تسمح هذه الثغرة الأمنية في Log4j باستغلال التحقق من صحة الإدخال غير الصحيح لـ LDAP ، مما يسمح بامتداد تنفيذ التعليمات البرمجية عن بعد (RCE) ، والمساومة على الخادم (السرية وتكامل البيانات وتوافر النظام). بالإضافة إلى ذلك ، تكمن مشكلة أو أهمية هذه الثغرة الأمنية في عدد التطبيقات والخوادم التي تستخدمها ، بما في ذلك برامج الأعمال والخدمات السحابية مثل Apple iCloud أو Steam أو ألعاب الفيديو الشائعة مثل Minecraft: Java Edition و Twitter و Cloudflare و Tencent و ElasticSearch و Redis و Elastic Logstash وما إلى ذلك.
الحديث عن هذه المسألة ، مؤخرا تم إصدار مؤسسة Apache Software Foundation من خلال وظيفة ملخص للمشاريع التي تعالج ثغرة خطيرة في Log4j 2 والذي يسمح بتشغيل تعليمات برمجية عشوائية على الخادم.
تتأثر مشاريع Apache التالية: Archiva و Druid و EventMesh و Flink و Fortress و Geode و Hive و JMeter و Jena و JSPWiki و OFBiz و Ozone و SkyWalking و Solr و Struts و TrafficControl و Calcite Avatica. أثرت الثغرة الأمنية أيضًا على منتجات GitHub ، بما في ذلك GitHub.com و GitHub Enterprise Cloud و GitHub Enterprise Server.
في الأيام الأخيرة كانت هناك زيادة كبيرة من النشاط المتعلق باستغلال الضعف. فمثلا، سجلت Check Point حوالي 100 محاولة استغلال في الدقيقة على خوادمها الوهمية ذروتها ، وأعلنت Sophos عن اكتشاف روبوت جديد لتعدين العملات المشفرة ، يتكون من أنظمة ذات ثغرة أمنية غير مصححة في Log4j 2.
فيما يتعلق بالمعلومات التي تم إصدارها حول المشكلة:
- تم تأكيد الثغرة الأمنية في العديد من صور Docker الرسمية ، بما في ذلك couchbase ، elasticsearch ، flink ، solr ، صور العاصفة ، إلخ.
- الثغرة الأمنية موجودة في منتج MongoDB Atlas Search.
- تظهر المشكلة في مجموعة متنوعة من منتجات Cisco ، بما في ذلك Cisco Webex Meetings Server و Cisco CX Cloud Agent و Cisco
- تقارير أمان الويب المتقدمة ، Cisco Firepower Threat Defense (FTD) ، Cisco Identity Services Engine (ISE) ، Cisco CloudCenter ، Cisco DNA Center ، Cisco. برودوركس ، إلخ.
- المشكلة موجودة في IBM WebSphere Application Server وفي منتجات Red Hat التالية: OpenShift و OpenShift Logging و OpenStack Platform و Integration Camel و CodeReady Studio و Data Grid و Fuse و AMQ Streams.
- مشكلة مؤكدة في Junos Space Network Management Platform و Northstar Controller / Planner و Paragon Insights / Pathfinder / Planner.
- تتأثر أيضًا العديد من المنتجات من Oracle و vmWare و Broadcom و Amazon.
مشاريع Apache التي لم تتأثر بالثغرة الأمنية Log4j 2: Apache Iceberg و Guacamole و Hadoop و Log4Net و Spark و Tomcat و ZooKeeper و CloudStack.
يُنصح مستخدمو الحزم التي بها مشكلات بتثبيت التحديثات التي تم إصدارها على وجه السرعة بالنسبة لهم ، قم بتحديث إصدار Log4j 2 بشكل منفصل أو اضبط المعلمة Log4j2.formatMsgNoLookups على true (على سبيل المثال ، إضافة المفتاح "-DLog4j2.formatMsgNoLookup = True" عند بدء التشغيل).
لقفل النظام المعرض للخطر الذي لا يوجد وصول مباشر له ، تم اقتراح استغلال لقاح Logout4Shell ، والذي ، من خلال ارتكاب هجوم ، يفضح إعداد Java "log4j2.formatMsgNoLookups = true"، "com.sun.jndi .rmi.object. trustURLCodebase = false "و" com.sun.jndi.cosnaming.object.trustURLCodebase = false "لمنع المزيد من مظاهر الثغرة الأمنية على الأنظمة غير الخاضعة للرقابة.