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 (ठीक किया गया संस्करण) के बीच कमिट की तुलना कर रहा हूँ। निम्नलिखित लिंक देखें: 5.6.3...5.6.4 की तुलना करें · spring-projects/spring-security (github.com)

मैं RegexRequestMatcher वर्ग में परिवर्तनों की जाँच करता हूँ। देखा जा सकता है कि संस्करण 5.6.4 में, यह वर्ग डिफ़ॉल्ट . के बजाय Pattern.DOTALL का उपयोग करता है।

जहाँ:

• 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: जब उपयोगकर्ता /admin/<कोई भी> पथ पर जाए, तो हर बार प्रमाणीकरण तंत्र सेट करने के लिए regexMatchers("/admin/.*").authenticated() का उपयोग करें। यह वही कमजोरी है जिसका उपयोग हमलावर बिना प्रमाणीकरण के /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