قال كبير مديري الأبحاث الأمنية في JFrog إن للثغرة سبب جذري مشابه لـ Log4Shell.
قال باحثون أمنيون من JFrog يوم الخميس إنهم اكتشفوا ثغرة خطيرة قائمة على JNDI في وحدة تحكم قاعدة بيانات H2 تستغل سببًا جذريًا مشابهًا لـ Log4Shell . لم يتم نشر CVE بواسطة NIST ولكن سيتم تعيين CVE-2021-42392 له .
في منشور مدونة ، قالت الشركة إن CVE-2021-42392 لا ينبغي أن يكون منتشرًا مثل Log4Shell على الرغم من أنها مشكلة حرجة لها سبب جذري مشابه.
أوضح JFrog أن Java Naming and Directory Interface (JNDI) هي واجهة برمجة تطبيقات توفر وظيفة التسمية والدليل لتطبيقات Java. H2 هي قاعدة بيانات Java SQL مفتوحة المصدر مستخدمة على نطاق واسع في العديد من المشاريع التي تتراوح من منصات الويب مثل Spring Boot إلى منصات إنترنت الأشياء مثل ThingWorks. لاحظ الباحثون أن حزمة com.h2database: h2 هي "جزء من أفضل 50 حزمة Maven الأكثر شيوعًا ، مع ما يقرب من 7000 من التبعيات الأثرية."
قال Shachar Menashe ، كبير مديري الأبحاث الأمنية في JFrog ، لـ ZDNet إنه على غرار ثغرة Log4Shell التي تم الكشف عنها في أوائل ديسمبر ، يمكن لعناوين URL التي يتحكم فيها المهاجمون والتي تنتشر في عمليات بحث JNDI أن تسمح بتنفيذ التعليمات البرمجية عن بُعد غير المصادق ، مما يمنح المهاجمين التحكم الوحيد في تشغيل شخص آخر أو أنظمة المنظمة.
قالت شركة الأمان إن CVE-2021-42392 لوحدة التحكم في قاعدة بيانات H2 هي أول مشكلة حرجة تم نشرها منذ Log4Shell ، على مكون آخر غير Log4j ، والذي يستغل نفس السبب الجذري لثغرة Log4Shell ، ألا وهو تحميل فئة JNDI عن بُعد.
كتب الباحثون: "على حد علمنا ، فإن CVE-2021-42392 هي أول ثغرة RCE غير مصادق مرتبطة بـ JNDI يتم نشرها منذ Log4Shell ، لكننا نشك في أنها لن تكون الأخيرة".
"كانت إحدى النقاط الرئيسية التي استخلصناها من حادثة ثغرة Log4Shell هي أنه نظرًا للاستخدام الواسع النطاق لـ JNDI ، لا بد أن يكون هناك المزيد من الحزم التي تتأثر بنفس السبب الجذري مثل Log4Shell - قبول عناوين URL التعسفية لبحث JNDI. عدّل إطار عمل اكتشاف الثغرات الأمنية الخاص بنا ليأخذ في الاعتبار وظيفة javax.naming.Context.lookup باعتبارها وظيفة خطيرة (بالوعة) وأطلق العنان لإطار العمل في مستودع Maven لنأمل في العثور على مشكلات مشابهة لـ Log4Shell. "
كانت حزمة قاعدة بيانات H2 واحدة من أولى حزم البيانات التي تم التحقق من صحتها وقد أبلغوا مسؤولي صيانة H2 الذين قاموا على الفور بإصلاحها في إصدار جديد ، مما أدى إلى إنشاء مستشار GitHub مهم .
وفقًا لـ JFrog ، فإن العديد من مسارات الكود في إطار قاعدة بيانات H2 تمر دون تصفية في عناوين URL التي يتحكم فيها المهاجمون إلى وظيفة javax.naming.Context.lookup ، والتي قالوا إنها تسمح بتحميل قاعدة البيانات عن بُعد. من بين جميع نواقل الهجوم ، يكون أخطرها من خلال وحدة التحكم H2.
"يمكن أن تؤثر هذه الميزة على أولئك الذين يقومون بتشغيل وحدة تحكم قاعدة بيانات H2 المكشوفة للشبكة ونوصي بتحديث قاعدة بيانات H2 الخاصة بك إلى الإصدار 2.0.206 على الفور. لاحظ أن قاعدة بيانات H2 مستخدمة من قبل العديد من أطر عمل الجهات الخارجية ، بما في ذلك Spring Boot و Play Framework و جي هيبستر ، "قال منشيه.
"في حين أن هذه الثغرة الأمنية ليست واسعة الانتشار مثل Log4Shell ، إلا أنه لا يزال من الممكن أن يكون لها تأثير كبير على المطورين وأنظمة الإنتاج إذا لم يتم التعامل معها وفقًا لذلك."
يشير التقرير إلى أنه نظرًا لاستخدام قاعدة بيانات H2 بواسطة العديد من المصنوعات اليدوية ، فمن الصعب عليهم تحديد عدد عمليات النشر الضعيفة لوحدة التحكم H2 الموجودة في البرية. شرح JFrog أيضًا العديد من متجهات الهجوم الأخرى باستخدام نفس الثغرة الأمنية.
اقترح JFrog على المستخدمين ترقية قاعدة بيانات H2 الخاصة بهم إلى أحدث إصدار . وأشاروا إلى أنهم شاهدوا عددًا من أدوات المطورين "التي تعتمد على قاعدة بيانات H2 وتكشف بشكل خاص وحدة التحكم H2."
قالت الشركة "إذا كنت تقوم بتشغيل وحدة تحكم H2 معرضة لشبكة LAN الخاصة بك (أو ما هو أسوأ ، WAN) ، فهذه المشكلة حرجة للغاية (تنفيذ رمز بعيد غير مصدق) ويجب عليك تحديث قاعدة بيانات H2 الخاصة بك إلى الإصدار 2.0.206 على الفور". "يمكن لمسؤولي الشبكات فحص الشبكات الفرعية المحلية الخاصة بهم بحثًا عن مثيلات مفتوحة لوحدة التحكم H2 باستخدام nmap. ومن المحتمل جدًا أن تكون أي خوادم تم إرجاعها قابلة للاستغلال."
وفقًا للباحثين ، فإن الإصدار 2.0.206 مشابه لـ Log4j 2.17.0 لأنه يحل المشكلة عن طريق تقييد عناوين URL لـ JNDI لاستخدام بروتوكول java (المحلي) فقط ، والذي يرفض أي استعلامات LDAP / RMI بعيدة.
قدم JFrog أيضًا العديد من خيارات التخفيف لأولئك الذين لا يستطيعون ترقية H2.
قال ماثيو وارنر ، كبير موظفي التكنولوجيا في Blumira ، لـ Mulkhas إنه وفقًا لـ OSINT ، من المحتمل أن يكون هناك أقل من 100 خادم متأثر على الإنترنت لأن وحدة التحكم في قاعدة بيانات H2 يجب أن تتعرض عن قصد للإنترنت عن طريق تغيير التكوين ليس فقط للاستماع إلى المضيف المحلي.
قال وارنر: "بينما تستخدم هذه الثغرة الأمنية أيضًا تحميل فئة JNDI عن بُعد ، فإنها تتطلب وصولاً غير متوفر مع التكوين الافتراضي لقاعدة بيانات H2".
قال جيك ويليامز ، مدير التكنولوجيا في BreachQuest ، إن الاستغلال على نطاق واسع أمر غير مرجح لأن هذه الثغرة الأمنية موجودة في تطبيق مقارنة بمكتبة مثل log4j ، مما يعني أن الأنظمة الضعيفة يجب أن يكون اكتشافها ومعالجتها أسهل بكثير.
في التكوين الافتراضي ، لا يمكن تشغيل الثغرة الأمنية إلا من نفس الجهاز الذي تعمل به وحدة التحكم في قاعدة البيانات على أساس أن الاستغلال مشروط للغاية.
قال ويليامز: "من غير المحتمل أن يتسبب ذلك في أضرار واسعة النطاق ، على الرغم من أن مديري الثغرات يجب أن يكونوا مستعدين لإصلاح ثغرات JNDI المكتشفة حديثًا عند الكشف عنها". "من الواضح أن هذه الثغرة الأمنية لن تكون آخر ثغرة يتم اكتشافها فيما يتعلق بـ log4j."
قال آخرون ، مثل راي كيلي من NTT Application Security ، إنه في حين أن الاستغلال غير مرجح ، فإن استخدام مزيج من SQL و JNDI لاستغلال ثغرة RCE "هو مثال مبتكر تمامًا وممتاز على كيفية إساءة استخدام مشكلة واحدة بطرق متعددة."
البحث مفيد أيضًا لأنه على الرغم من وجود عيوب تشفير معينة في log4j أدت إلى Log4Shell ، فإن الفكرة الأوسع لنقص التحقق من صحة عمليات بحث JNDI التي تؤدي إلى نقاط الضعف هي مسار هجوم عام من المحتمل أن يكون موجودًا في مكان آخر ، وبالنظر إلى ثغرات log4j التي لم تكن موجودة ' تم اكتشافه عاجلاً ، ومن المحتمل أنه لم يخضع للتدقيق الموجه ، وفقًا لـ Bugcrowd CTO Casey Ellis.
قال إليس: "هذا مثال كلاسيكي على" مجموعات البحث "وهي ظاهرة لاحظها Bugcrowd عدة مرات من قبل وتوقعناها بعد النشر الأولي لـ Log4Shell".
"اختارت بعض فرق البحث الاستفادة من الشعور بالذعر لإيصال رسالتهم إلى هناك ، بينما يبدو أن أفراد JFrog قد حرصوا بشدة على إيصال رسالتهم ، لكنهم لم يتسببوا في عمل لا داعي له لفرق الأمن المثقلة بالفعل."
