تم التحديث في 13 أبريل 2022 ليشمل أحدث المعلومات المتاحة حول CVE-2022-22965، وشرحًا إضافيًا للتبعيات في Spring Framework، وبيانات حول مدى انتشار هذه الثغرة الأمنية في البيئات السحابية.
تم مؤخرًا تصحيح اثنتين من نقاط الضعف الهامة الخاصة بتنفيذ التعليمات البرمجية عن بُعد (RCE) في مكتبات Spring Java الشهيرة، وقد أثارت كلتاهما قدرًا كبيرًا من الضجة:
CVE-2022-22965 (Spring Framework RCE عبر Data Binding على الإصدار 9 من JDK أو أعلى) –
-
تؤثر مشكلة عدم الحصانة هذه على برامج Java التي تعتمد على إصدارات Spring Framework الأقدم من 5.2.19، والإصدارات من 5.3.0 إلى 5.3.17. يجب على المطورين تحديث تبعيات برامجهم إلى إصدارات Spring Framework 5.3.18 أو 5.2.20، أو تطبيق أي من الحلول المتعددة التي يقترحها Spring.
-
مدبلج “سبرينغ 4 شل” (على غرار “Log4Shell”)، حظيت هذه الثغرة الأمنية بأكبر قدر من الاهتمام حتى الآن. ويرجع ذلك في الغالب إلى الاستخدام الواسع النطاق لمكتبات Spring Framework في البرامج المستندة إلى Java، وجزئيًا بسبب المقارنات المثيرة للجدل مع Log4Shell والنقص الأولي في التحقق من صحة البائع بعد ظهور الثغرة الأمنية لأول مرة. ادعى بريتوريان أن هذه الثغرة الأمنية هي في الواقع تجاوز لثغرة أمنية أقدم بكثير في Spring Framework (CVE-2010-1622).
CVE-2022-22963 (وظيفة Spring Cloud RCE عبر البرامج الضارة لعبة تعبير) –
-
تؤثر مشكلة عدم الحصانة هذه على برامج Java التي تعتمد على إصدارات Spring Cloud Function (SCF) الأقدم من 3.1.6، والإصدارات 3.2.0 إلى 3.2.2. يجب على المطورين تحديث تبعيات برامجهم إلى إصدارات SCF 3.1.7 أو 3.2.3.
-
تم تصنيفها في البداية على أنها متوسطة الخطورة، ثم قامت شركة VMware منذ ذلك الحين بتغيير تقييمها وصنفت هذه الثغرة الأمنية على أنها خطيرة. ونظرًا لأن هذه الثغرة الأمنية تؤثر أيضًا على مكتبة Spring (غير ذات صلة)، وتم نشرها في نفس يوم نشر Spring4Shell وتم تعيينها بالفعل لـ CVE، فقد تم الخلط بين الثغرات الأمنية بشكل متكرر. والآن بعد أن أصبح لدى Spring4Shell برنامج مكافحة التطرف العنيف الخاص به، نتوقع أن يتضاءل هذا الارتباك.
التفاصيل الفنية
باختصار، من المحتمل أن تكون الموارد التي تقوم بتشغيل البرامج التي تتضمن الإصدارات المتأثرة من هذه المكتبات عرضة لطلبات HTTP POST المعدة خصيصًا والتي تسمح للمهاجم بتنفيذ التعليمات البرمجية على الجهاز عن بعد. تتطلب إمكانية الاستغلال عن بعد لكلتا الثغرات الأمنية أن يتم كشف الموارد التي تقوم بتشغيل التطبيقات الضعيفة وأن يكون لها منفذ HTTP مفتوح.
ومع ذلك، هناك عوامل مخففة تحد من استغلال نقاط الضعف هذه في مواقف الحياة الواقعية. في حالة Spring4Shell، على سبيل المثال:
-
يجب أن تستخدم التطبيقات الإصدار 9 من JDK أو أعلى
-
يجب أن تتضمن تبعيات التطبيق Spring-webmvc أو Spring-webflux
-
يجب أن تستخدم التطبيقات ربط البيانات مع أنواع معلمات معينة
يرجع هذا المزيج من المتطلبات إلى طبيعة Spring4Shell – في حين أن الخطأ الأساسي موجود تقنيًا في Spring-beans، فإن الطرق الوحيدة المعروفة حاليًا لتشغيله هي عبر مكتبات Spring-webmvc أو Spring-webflux المذكورة أعلاه – وكلاهما يعتمد على Spring-beans، كما يمكن رؤيته في شجرة التبعية التالية:
بالإضافة إلى ذلك، فإن طرق الاستغلال المعروفة حاليًا لـ Spring4Shell لها المتطلبات الأساسية التالية، على الرغم من أنها قد تتغير تمامًا مع ظهور برمجيات إكسبلويت جديدة:
قد تكون كل هذه الشروط موجودة فقط في عدد قليل من التطبيقات الفعلية في العالم الحقيقي، ولم يتم اكتشاف أي منها علنًا حتى الآن (باستثناء التطبيقات الضعيفة عمدًا والتي أنشأها باحثون أمنيون عمدًا لعرض هذه الثغرة الأمنية). ومع ذلك، تؤثر هذه الثغرة الأمنية على بعض نماذج التعليمات البرمجية من البرامج التعليمية على موقع Spring، ويمكن استخدامها كأساس لبعض التطبيقات، لذلك من الصعب تحديد التأثير الدقيق لـ Spring4Shell في الوقت الحالي.
أما بالنسبة لثغرة CVE-2022-22963 (ثغرة SCF)، على الرغم من أن الاستغلال بسيط وتم بالفعل نشر عمليات استغلال إثبات المفهوم (POC) عبر الإنترنت، إلا أنها قابلة للاستغلال فقط في التطبيقات التي تستخدم وظيفة التوجيه. علاوة على ذلك، من المحتمل أن معظم البرامج المعتمدة على مكتبة SCF تعمل على مثيلات وظيفة كخدمة (FaaS) قصيرة العمر. تُظهر بياناتنا أن هذه المكتبة ليست منتشرة بشكل كبير في البيئات السحابية، وهي موجودة بالفعل في الغالب على الموارد التي لا تحتوي على خادم. لذلك، على الرغم من أن العديد من البيئات قد تحتوي على بعض الموارد المتأثرة، إلا أننا نتوقع أن يكون التأثير العملي لهذه الثغرة الأمنية محدودًا.
لاحظ أنه كما هو الحال في حالة Log4Shell، لا يمكن للمستخدمين النهائيين تحديث إصدارات التبعية لتطبيقات الطرف الثالث الضعيفة، ويجب عليهم الانتظار حتى يقوم المشرفون بإصدار تصحيحات للبرامج المتأثرة.
حماية البيئة السحابية الخاصة بك باستخدام Wiz
اعتبارًا من 31 مارس 2022، يقوم Wiz بفحص البيئات السحابية للعملاء بحثًا عن أي تطبيق متأثر يعتمد على الإصدارات الضعيفة من مكتبات Spring Java المذكورة أعلاه.
Wiz هو حل كامل بدون وكيل لتأمين البيئات السحابية. تسمح تقنية المسح الفريدة لدينا للمستخدمين باكتشاف عمليات التثبيت الضعيفة عبر جميع أعباء العمل السحابية في بيئاتهم في غضون دقائق من النشر، وتتبع تقدمهم في تصحيح الموارد المتأثرة، وتحديد أولويات جهود التصحيح بناءً على مجموعات سامة مثل التعرض الخارجي أو أذونات المسؤول على مورد متأثر.
في حالة هذه الثغرات الأمنية المكتشفة حديثًا، توفر Wiz سابقة إضافية للموارد ذات منافذ HTTP المفتوحة، لمساعدة العملاء على التركيز على تحديد وتصحيح الموارد الأكثر عرضة لخطر الاستغلال.
يعد Wiz Threat Center أفضل مكان لعرض أية مشكلات أمنية حرجة تؤثر على بيئتك. ويحتوي على عناصر تحكم معدة مسبقًا تسترد جميع الموارد ذات الإصدارات الضعيفة من Spring Cloud Function وSpring Framework، وتعرض مسارات تصعيد الامتيازات المقابلة لها – كل ذلك بنقرة واحدة.
انتشار CVE-2022-22965 في البيئات السحابية
تظهر بياناتنا أن حوالي 63% من البيئات السحابية تتأثر بالثغرة CVE-2022-22965، على الرغم من أن الموارد المعرضة للخطر في كثير من الحالات لا تكون قابلة للاستغلال من خلال عمليات الاستغلال المعروفة حاليًا. من بين جميع الموارد المتأثرة، حوالي 75% عبارة عن أجهزة افتراضية و25% عبارة عن حاويات.
تمت كتابة هذه المدونة بواسطة فريق أبحاث Wiz، كجزء من مهمتنا المستمرة لتحليل التهديدات التي تواجه السحابة، وبناء آليات تمنعها وتكتشفها، وتقوية استراتيجيات أمان السحابة.
