spring-shell-vuln

Spring4Shell: ثغرة تنفيذ أوامر عن بعد في نواة Spring

أكدت Spring وجود ثغرة تنفيذ أوامر عن بعد (RCE) في إطار Spring. أصدر الفريق بيانًا رسميًا إلى جانب إرشادات التخفيف للمشكلة. يمكن تتبع هذه الثغرة الأمنية تحت المعرف CVE-2022-22965.

بعض المعلومات حول ثغرة Spring4Shell ومشاركة التفاصيل في منشور Spring4Shell: التفاصيل والاستغلال. بالإضافة إلى ذلك، أكد فريق الأمن من Praetorian أن Spring Core على JDK9+ معرض لتنفيذ الأوامر عن بعد بسبب تجاوز لثغرة CVE-2010-1622.

في البداية، بدأ الأمر في 30 مارس، حيث ألمح قائد فريق KnownSec 404، Heige، إلى أول إشعار بالثغرة. غرّد برسالة تحذيرية "Spring core RCE （JDK >=9" مع صورة الإثبات.

بينما ننشر قصة الثغرة، اختفى Heige من تويتر. لا نعرف السبب وراء ذلك ولكن قد يكون هناك شيء ما.

الأحداث

في نهاية عام 2021، اشتعلت الإنترنت بسبب تسريب ثغرة يوم الصفر لتنفيذ الأوامر عن بعد المعروفة أيضًا باسم Log4Shell، في Apache Log4j2. تم اكتشاف الثغرة بواسطة فريق أمن Alibaba Cloud.

- هذه الثغرة ليست بنفس خطورة Log4Shell. جميع سيناريوهات الهجوم أكثر تعقيدًا بسبب طبيعة هجمات التلاعب بمُحمل الفئات (Class Loader Manipulation) في Java. يتطلب استغلال Spring4Shell معرفة عميقة بـ Java للحصول على إثبات مفهوم عملي. التلاعب بمُحمل الفئات أكثر تعقيدًا في الفهم من ثغرة Log4Shell.

اليوم، عثر الباحثون على ثغرة أخرى خطيرة قد تسبب أضرارًا جسيمة. يتم تتبع الخطأ الآن تحت المعرف CVE-2022-22965، ويمكننا تسميته Spring4Shell. توجد الثغرة في نواة Spring مع إصدار JDK أكبر من أو يساوي 9.0.

إطار Spring والأطر المشتقة منه، ملفات spring-beans-*.jar أو CachedIntrospectionResults.class

جميع التفاصيل أدناه مؤكدة الآن. لا أتحمل أي مسؤولية عن أي ضرر ناتج.

تفاصيل الثغرة والتحقيق

باعتباره أحد أشهر أطر العمل مفتوحة المصدر خفيفة الوزن في Java، يتيح Spring للمطورين التركيز على منطق الأعمال ويبسط دورة تطوير تطبيقات Java للمؤسسات.

يتطلب الاستغلال وجود نقطة نهاية مع تمكين DataBinder (مثل طلب POST يقوم بفك تشفير البيانات من جسم الطلب تلقائيًا) ويعتمد بشكل كبير على حاوية servlet الخاصة بالتطبيق. على سبيل المثال، عند نشر Spring على Apache Tomcat، يكون WebAppClassLoader متاحًا، مما يسمح للمهاجم باستدعاء getters و setters لكتابة ملف JSP ضار على القرص. ومع ذلك، إذا تم نشر Spring باستخدام حاوية Tomcat المضمنة، فإن مُحمل الفئات هو LaunchedURLClassLoader الذي يتمتع بوصول محدود.

ومع ذلك، في إصدار JDK9 (وما فوق) من إطار Spring، يمكن للمهاجم عن بعد الحصول على كائن AccessLogValve وقيم الحقول الضارة من خلال وظيفة ربط المعلمات (parameter binding) في الإطار، بشرط استيفاء شروط معينة.

• من المعروف حاليًا أن استغلال هذه الثغرة يتطلب شرطين أساسيين:
• استخدام إطار Spring MVC و JDK9 وما فوق

(1). التحقق من رقم إصدار JDK

على الخادم قيد التشغيل لنظام المؤسسة، قم بتشغيل الأمر "java -version" للتحقق من إصدار JDK قيد التشغيل. إذا كان رقم الإصدار أقل من أو يساوي 8، فإنه لا يتأثر بالثغرة.

(2). التحقق من استخدام إطار Spring

1. إذا كان مشروع نظام المؤسسة منشورًا على شكل حزمة war، فاتبع الخطوات أدناه للحكم.

• فك ضغط حزمة war: قم بتغيير لاحقة ملف war إلى .zip وقم بفك ضغط ملف zip.
• ابحث عن ملف jar بتنسيق spring-beans-*.jar (مثال: spring-beans-5.3.16.jar) في دليل فك الضغط. إذا كان موجودًا، فهذا يعني أن نظام الأعمال مطور باستخدام إطار Spring.
• إذا لم يكن ملف spring-beans-*.jar موجودًا، فابحث عن وجود ملف CachedIntrospectionResuLts.class في دليل فك الضغط. إذا كان موجودًا، فهذا يعني أن نظام الأعمال مطور باستخدام إطار Spring.

2. إذا كان مشروع نظام المؤسسة يعمل بشكل مباشر ومستقل على شكل حزمة jar، فاحكم وفقًا للخطوات التالية.

• فك ضغط حزمة jar: قم بتغيير لاحقة ملف jar إلى .zip، وقم بفك ضغط ملف zip.
• ابحث عن ملف jar بتنسيق spring-beans-*.jar (مثال: spring-beans-5.3.16.jar) في دليل فك الضغط. إذا كان موجودًا، فهذا يعني أن نظام الأعمال مطور باستخدام إطار Spring.
• إذا لم يكن ملف spring-beans-*.jar موجودًا، فابحث عن وجود ملف CachedIntrospectionResuLts.class في دليل فك الضغط. إذا كان موجودًا، فهذا يعني أن نظام الأعمال مطور باستخدام إطار Spring.

(3) التحقيق الشامل

بعد إتمام خطوتي التحري أعلاه، إذا تحقق الشرطان التاليان معًا، يتم تحديد أنه متأثر بهذه الثغرة:

1. رقم إصدار JDK هو 9 وما فوق;
2. استخدام إطار Spring أو الأطر المشتقة منه.

إرشادات إصلاح الثغرة

الآن قام فريق Spring بإصلاح الثغرة وأصدر أحدث إصدارات Spring Boot 2.6.6 و 2.5.12 التي تعتمد على Spring Framework 5.3.18.

حماية WAF

على أجهزة حماية الشبكة مثل WAF، قم بتنفيذ تصفية قاعدة للسلاسل مثل "class."، "Class."، ".class."، و ".Class." وفقًا لحركة المرور الفعلية للخدمات المنشورة. بعد تصفية القواعد، اختبر تشغيل الأعمال لتجنب أي تأثير إضافي.

إجراءات الإصلاح المؤقتة

يجب إجراء الإصلاح المؤقت للثغرة في الخطوتين التاليتين في وقت واحد:

1. ابحث عن التعليق التوضيحي @InitBinder عالميًا في التطبيق لمعرفة ما إذا كانت طريقة dataBinder.setDisallowedFields قد تم استدعاؤها في نص الطريقة. إذا تم العثور على إدخال هذا المقطع البرمجي، أضف {"class.", "Class.", ".class.", ".Class."} إلى القائمة السوداء الأصلية. (ملاحظة: إذا تم استخدام هذا المقطع البرمجي كثيرًا، فيجب إلحاقه في كل مكان.)

2. قم بإنشاء الفئة الشاملة التالية تحت حزمة مشروع نظام التطبيق، وتأكد من تحميل هذه الفئة بواسطة Spring (يوصى بإضافتها في الحزمة التي يوجد بها Controller). بعد إضافة الفئة، يحتاج المشروع إلى إعادة الترجمة والتعبئة، واختبار التحقق الوظيفي، وإعادة نشر المشروع.

import org.springframework.core.annotation.Order;

import org.springframework.web.bind.WebDataBinder;

import org.springframework.web.bind.annotation.ControllerAdvice;

import org.springframework.web.bind.annotation.InitBinder;

@ControllerAdvice

@Order(10000)

public class GlobalControllerAdvice{ 

     @InitBinder

     public void setAllowedFields(webdataBinder dataBinder){

         String[]abd=new string[]{"class.*","Class.*","*.class.*","*.Class.*"};

         dataBinder.setDisallowedFields(abd);

     }

}

من مستودع Git لمشاريع Spring، يبدو أن مطوري Spring يعملون على إصلاح ثغرة تنفيذ الأوامر عن بعد، لكن علينا انتظار التأكيد الرسمي.