CVE 2022-22978: تجاوز التفويض في RegexRequestMatcher 🥶

نظرة عامة

وفقًا للمعلومات التي وجدتها، فإن هذه الثغرة مرتبطة بفئة RegexRequestMatcher في إطار عمل Spring Security. على وجه التحديد، التطبيقات التي تستخدم RegexRequestMatcher والتي تحتوي تعبيراتها المنتظمة على نقطة (.) يمكن تجاوزها باستخدام الأحرف \r(%0a) و \n(%0d)؛ وبالتالي يمكن للمهاجمين الوصول إلى المسارات غير المسموح بها دون مصادقة.

الإصدارات المتأثرة بالثغرة من إطار عمل Spring Security:

• 5.5.x قبل 5.5.7
• 5.6.x قبل 5.6.4
• والإصدارات غير المدعومة السابقة.

تحليل

نحتاج إلى الوصول إلى الكود المصدري لـ Spring Security لتحليل هذه الثغرة بشكل ثابت. على وجه التحديد، استخدمت ميزة مقارنة الالتزامات بين الإصدارين 5.6.3 (الإصدار المتأثر) و 5.6.4 (الإصدار المُصحح) على Github. انظر الرابط التالي: Comparing 5.6.3...5.6.4 · spring-projects/spring-security (github.com)

قمت بفحص التغييرات في الفئة RegexRequestMatcher. يمكن ملاحظة أنه في الإصدار 5.6.4، تستخدم هذه الفئة Pattern.DOTALL بدلاً من استخدام . الافتراضي كما في الإصدار 5.6.3.

حيث:

• Pattern: هي واحدة من ثلاث فئات في حزمة java.util.regex، وتقوم بمعالجة التعبيرات المنتظمة.
• Pattern.DOTALL: عند استخدام هذه العلامة، سيتطابق "." في التعبير المنتظم مع جميع الأحرف، بما في ذلك أحرف السطر الجديد مثل \n , \r.
• Pattern.CASE_INSENSITIVE: لا يهتم بالأحرف الكبيرة أو الصغيرة.

افتراضيًا، يتطابق . في التعبير المنتظم مع جميع الأحرف باستثناء أحرف السطر الجديد مثل \n, \r. في هذه الحالة، إذا كانت هناك دالة regex للتحقق من نمط سلسلة ما، فلن تتطابق دالة regex إذا كانت السلسلة تحتوي على أحرف سطر جديد. لتجنب ذلك، يمكن استخدام العلم Pattern.DOTALL.

ولكن إذا استخدم شخص ما عمدًا %0d بدلاً من \n أو %0a بدلاً من \r، فلن يتمكن regex أعلاه من التطابق. لذلك، في الإصدار 5.6.4، تمت إضافة فحص إضافي لهذه الحالة في RegexRequestMatcherTests.java. على وجه التحديد، يقوم بتحويل %0d و %0a إلى \n و \r على التوالي ثم التحقق بواسطة regex.

عرض توضيحي

الخطوة 1: إنشاء تطبيق ويب Spring Boot باستخدام Spring Initializr مع تبعيتين: Spring Security و Spring Web.

الخطوة 2: إنشاء وحدة تحكم تطبع النص This is a CVE-2022-22978 demo عند وصول طلب إلى المسار /admin/*

الخطوة 3: إعداد آلية المصادقة عندما يصل المستخدم إلى المسار /admin/<أي> باستخدام regexMatchers("/admin/.*").authenticated(). هذه هي الثغرة التي يستغلها المهاجمون لعرض محتوى صفحات /admin/<أي> دون مصادقة.

الخطوة 4: في ملف التكوين، قم بتعريف إصدار Spring Security الذي يحتوي على الثغرة. هنا اخترت الإصدار 5.6.3.

الخطوة 5: تشغيل التطبيق باستخدام الأمر gradlew bootRun، البرنامج يستخدم Apache Tomcat افتراضيًا للاستماع على المنفذ 8080. نصل إلى المسار /admin/xyz (أي مسار طالما يبدأ بـ /admin/).

النتيجة تعيد رمز 403 Forbidden مما يعني أنني لا أستطيع الوصول بسبب عدم المصادقة.

في هذه المرحلة، استغلال ثغرة دالة regexMatchers في Spring Security (الإصدار 5.6.3) عندما لا تتطابق مع أحرف السطر الجديد مثل \r(%0d) و \n(%0a) → يمكنني الوصول إلى المسار أعلاه دون مصادقة باستخدام الحمولة /admin/%0dxyz

وبالمثل مع الحمولة /admin/%0axyz

وهكذا تمكنا من استغلال ثغرة CVE-2022-22978 بنجاح باستخدام حمولة بسيطة للغاية.

طريقة الإصلاح

• تحديث إصدار Spring Security إلى:
  • 5.5.7+
  • 5.6.4+
  • 5.7+
• عرض توضيحي: استخدام الإصدار المُصحح، وتحديدًا 5.7.1

محاولة مهاجمة الويب بنفس الحمولة السابقة: /admin/%0dxyz

في هذه المرحلة، لم يعد التطبيق يعيد استجابة كما يتوقع المهاجم.

الاستخدام

git clone https://github.com/ducluongtran9121/CVE-2022-22978-PoC.git
cd CVE-2022-22978-PoC
gradlew bootRun

المتطلبات

Java 18
Gradle 7.4.1