اكتشفوا ثغرة أمنية في Spring Framework

مؤخرا اندلعت الأخبار ذلك تم الكشف عن ثغرة أمنية خطيرة من نوع يوم الصفر في الوحدة يتم شحن Spring Core كجزء من إطار الربيع، والذي يسمح لمهاجم بعيد غير مصدق بتنفيذ التعليمات البرمجية الخاصة به على الخادم.

حسب بعض التقديرات ، وحدة الربيع الأساسية تستخدم في 74٪ من تطبيقات جافا. يتم تقليل خطر الضعف من خلال حقيقة أن التطبيقات فقط استخدم التعليق التوضيحي "RequestMapping" لـمن خلال ربط معالجات الطلب واستخدام ربط معلمات نموذج الويب بتنسيق "name = value" (POJO ، كائن Java قديم عادي) ، بدلاً من JSON / XML ، تكون عرضة للهجوم. لم يتضح بعد أي تطبيقات وأطر عمل Java التي تأثرت بالمشكلة.

هذه الثغرة ، المسماة "Spring4Shell" ، تستفيد من الحقن الطبقي الذي يؤدي إلى RCE كامل وهي خطيرة للغاية. تم اختيار اسم "Spring4Shell" لأن Spring Core مكتبة موجودة في كل مكان ، على غرار log4j الذي ولّد ثغرة Log4Shell سيئة السمعة.

نعتقد أن المستخدمين الذين يقومون بتشغيل الإصدار 9 من JDK والإصدارات الأحدث معرضون لهجوم RCE. تتأثر جميع إصدارات Spring Core.

هناك استراتيجيات للتخفيف من حدة الهجوم ونعتقد أنه ليست كل خوادم Spring معرضة للخطر بالضرورة ، اعتمادًا على العوامل الأخرى التي تمت مناقشتها أدناه. ومع ذلك ، نوصي حاليًا بأن يقوم جميع المستخدمين بتطبيق عوامل التخفيف أو الترقية إذا كانوا يستخدمون Spring Core.

لا يمكن استغلال الثغرة الأمنية إلا عند استخدام Java / JDK 9 أو إصدار أحدث. تمنع الثغرة وضع القائمة السوداء للحقول "class" و "module" و "classLoader" أو استخدام قائمة بيضاء صريحة للحقول المسموح بها.

المشكلة يرجع إلى القدرة على تجاوز الحماية ضد الثغرة الأمنية CVE-2010-1622 ، تم إصلاحه في Spring Framework في عام 2010 ومرتبط بتنفيذ معالج classLoader عند تحليل معلمات الطلب.

يتم اختصار عملية استغلال الثغرة إلى إرسال طلب جباستخدام المعلمات "class.module.classLoader.resources.context.parent.pipeline.first. *" ، والتي تؤدي معالجتها ، عند استخدام "WebappClassLoaderBase" ، إلى استدعاء فئة AccessLogValve.

تسمح لك الفئة المحددة بتكوين المسجل لإنشاء ملف jsp عشوائي في بيئة جذر Apache Tomcat وكتابة الكود الذي حدده المهاجم إلى هذا الملف. الملف الذي تم إنشاؤه متاح للطلبات المباشرة ويمكن استخدامه كقذيفة ويب. لمهاجمة تطبيق ضعيف في بيئة Apache Tomcat ، يكفي إرسال طلب بمعلمات معينة باستخدام الأداة المساعدة curl.

المشكلة قيد النظر في Spring Core عدم الخلط بينه وبين نقاط الضعف التي تم تحديدها حديثًا CVE-2022-22963 و CVE-2022-22950. تؤثر المشكلة الأولى على حزمة Spring Cloud وتسمح أيضًا بتنفيذ التعليمات البرمجية عن بُعد (استغلال). تم إصلاح CVE-2022-22963 في إصدار Spring Cloud 3.1.7 و 3.2.3.

المشكلة الثانية CVE-2022-22950 موجودة في Spring Expression ، ويمكن استخدامها لإطلاق هجمات DoS ، وتم إصلاحها في Spring Framework 5.3.17. هذه نقاط ضعف مختلفة اختلافًا جوهريًا. لم يصدر مطورو Spring Framework حتى الآن أي بيان حول الثغرة الأمنية الجديدة ولم يصدروا أي إصلاح.

كإجراء حماية مؤقت ، يوصى باستخدام قائمة سوداء لمعلمات الاستعلام غير الصالحة في التعليمات البرمجية الخاصة بك.

بعد ليس من الواضح إلى أي مدى يمكن أن تكون العواقب وخيمة المشكلة التي تم تحديدها وما إذا كانت الهجمات ستكون ضخمة كما في حالة الثغرة الأمنية في Log4j 2. تم إطلاق الثغرة الأمنية بالاسم الرمزي Spring4Shell و CVE-2022-22965 ، وتم إصدار تحديثات Spring Framework 5.3.18 و 5.2.20 لمعالجة الضعف.

يتوفر التصحيح الآن اعتبارًا من 31 مارس 2022 في الإصدارين الأحدث من الربيع 5.3.18 و 5.2.20. نوصي جميع المستخدمين بالترقية. بالنسبة لأولئك غير القادرين على الترقية ، فإن عوامل التخفيف التالية ممكنة:

استنادًا إلى منشور Praetorian الذي يؤكد وجود RCE في Spring Core ، فإن النهج الموصى به حاليًا هو تصحيح DataBinder عن طريق إضافة قائمة سوداء لأنماط الحقول الضعيفة اللازمة للاستغلال.

نعم في النهاية أنت مهتم بمعرفة المزيد عنها حول الملاحظة ، يمكنك التحقق من التفاصيل في الرابط التالي.


محتوى المقال يلتزم بمبادئنا أخلاقيات التحرير. للإبلاغ عن خطأ انقر فوق هنا.

كن أول من يعلق

اترك تعليقك

لن يتم نشر عنوان بريدك الإلكتروني.

*

*

  1. المسؤول عن البيانات: ميغيل أنخيل جاتون
  2. الغرض من البيانات: التحكم في الرسائل الاقتحامية ، وإدارة التعليقات.
  3. الشرعية: موافقتك
  4. توصيل البيانات: لن يتم إرسال البيانات إلى أطراف ثالثة إلا بموجب التزام قانوني.
  5. تخزين البيانات: قاعدة البيانات التي تستضيفها شركة Occentus Networks (الاتحاد الأوروبي)
  6. الحقوق: يمكنك في أي وقت تقييد معلوماتك واستعادتها وحذفها.