CVE 2022-22978: RegexRequestMatcher में प्राधिकरण बाईपास 🥶

अवलोकन

मेरी जानकारी के अनुसार, यह Spring Security फ्रेमवर्क में RegexRequestMatcher वर्ग से संबंधित एक कमजोरी है। विशेष रूप से, जो एप्लिकेशन RegexRequestMatcher का उपयोग करते हैं और जिनके रेगुलर एक्सप्रेशन में डॉट (.) शामिल होता है, उन्हें \r(%0a) और \n(%0d) वर्णों का उपयोग करके बाईपास किया जा सकता है; जिससे हमलावर बिना प्रमाणीकरण के अनुमति रहित पथों तक पहुँच सकते हैं।

Spring Security फ्रेमवर्क के प्रभावित संस्करण:

• 5.5.x से पहले 5.5.7
• 5.6.x से पहले 5.6.4
• इससे पहले के असमर्थित संस्करण।

विश्लेषण

हमें इस कमजोरी का स्थैतिक विश्लेषण करने के लिए Spring Security के स्रोत कोड तक पहुँचना होगा। यहाँ, मैं Github पर दो संस्करणों 5.6.3 (कमजोर संस्करण) और 5.6.4 (सुधारित संस्करण) के बीच कमिट की तुलना करने की सुविधा का उपयोग करता हूँ। निम्न लिंक देखें: 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 फ्लैग का उपयोग किया जा सकता है।

हालाँकि, अगर कोई जानबूझकर \n के बजाय %0d या \r के बजाय %0a का उपयोग करता है, तब भी उपरोक्त regex मेल नहीं खाएगा। इसलिए, संस्करण 5.6.4 में, RegexRequestMatcherTests.java में इस मामले के लिए एक अतिरिक्त जाँच जोड़ी गई है। विशेष रूप से, यह %0d और %0a को क्रमशः \n और \r में परिवर्तित करता है और फिर regex से जाँच करता है।

प्रदर्शन

चरण 1: Spring Initializr का उपयोग करके Spring Security और Spring Web की दो निर्भरताओं के साथ एक Spring Boot वेब एप्लिकेशन बनाएँ।

चरण 2: एक कंट्रोलर बनाएँ जो /admin/* पथ पर अनुरोध आने पर This is a CVE-2022-22978 demo संदेश प्रिंट करता है।

चरण 3: regexMatchers("/admin/.*").authenticated() का उपयोग करके हर बार जब उपयोगकर्ता /admin/<कोई भी> पथ पर पहुँचता है तो प्रमाणीकरण तंत्र सेट करें। यह वह कमजोरी है जिसका हमलावर बिना प्रमाणीकरण के /admin/<कोई भी> पृष्ठों की सामग्री देखने के लिए फायदा उठाते हैं।

चरण 4: कॉन्फ़िगरेशन फ़ाइल में, कमजोरी वाले Spring Security संस्करण की घोषणा करें। यहाँ मैं संस्करण 5.6.3 चुनता हूँ।

चरण 5: आदेश gradlew bootRun के साथ एप्लिकेशन चलाएँ, प्रोग्राम डिफ़ॉल्ट रूप से Apache Tomcat का उपयोग करके पोर्ट 8080 पर सुनता है। हम /admin/xyz पथ पर पहुँचते हैं (कोई भी पथ जो /admin/ से शुरू होता है)।

परिणाम 403 Forbidden कोड लौटाता है, जिसका अर्थ है कि प्रमाणीकरण के अभाव में मैं पहुँच नहीं सकता।

अब, Spring Security (संस्करण 5.6.3) में regexMatchers फ़ंक्शन की कमजोरी का लाभ उठाते हुए, जब यह नई पंक्ति वर्णों जैसे \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