dungsocool/cve-2017-5638Apache Struts2 OGNL इंजेक्शन (CVE-2017-5638) का प्रदर्शन करने वाली एक व्यावहारिक प्रयोगशाला, जिसमें चरण-दर-चरण सिस्टम विश्लेषण, शोषण, सैंडबॉक्स बाइपास, और पेनिट्रेशन टेस्टिंग शिक्षा के लिए पोस्ट-एक्सप्लॉइटेशन तकनीकें शामिल हैं।
कंटेनर शुरू करने के बाद, Struts2 लॉग दिखाते हैं कि एप्लिकेशन struts-default.xml, struts-plugin.xml, और struts.xml जैसी परिचित कॉन्फ़िगरेशन फ़ाइलों को लोड करता है। यह पुष्टि करता है कि उपयोग में आने वाला फ्रेमवर्क Apache Struts2 है।
एक उल्लेखनीय बिंदु इस पंक्ति में है:
Choosing bean (jakarta) for (org.apache.struts2.dispatcher.multipart.MultiPartRequest)
यह पंक्ति इंगित करती है कि Struts2 multipart/form-data प्रकार के अनुरोधों को संभालने के लिए Jakarta मल्टीपार्ट पार्सर (मल्टीपार्ट अपलोड डेटा विश्लेषक) चुन रहा है, जो आमतौर पर फ़ाइल अपलोड कार्यक्षमता में पाया जाता है।
S2-045 / CVE-2017-5638 के विश्लेषण के दौरान यह एक महत्वपूर्ण संकेत है, क्योंकि यह कमजोरी Struts2 द्वारा मल्टीपार्ट अनुरोधों को पार्स करते समय त्रुटियों को संभालने की प्रक्रिया से संबंधित है, विशेष रूप से अमान्य Content-Type हेडर के साथ।
हालाँकि, यह लॉग केवल यह साबित करता है कि एप्लिकेशन Struts2 और जकार्ता-शैली मल्टीपार्ट हैंडलर का उपयोग करता है। यह अभी तक यह निष्कर्ष निकालने के लिए पर्याप्त नहीं है कि एप्लिकेशन निश्चित रूप से कमजोर है। पुष्टि करने के लिए, हमें struts2-core के संस्करण का पता लगाना होगा और इसकी तुलना प्रभावित संस्करण श्रेणी से करनी होगी।
curl का उपयोग करके वेब सेवा तक पहुँचने पर, प्रतिक्रिया हेडर दिखाते हैं कि एप्लिकेशन Jetty 9.2.11.v20150529 पर चल रहा है। यह जानकारी एप्लिकेशन (सर्वलेट कंटेनर) चलाने वाले वातावरण की पहचान करने में मदद करती है, लेकिन सीधे Struts2 के संस्करण का खुलासा नहीं करती है।
वेब इंटरफ़ेस Struts2 Showcase - Fileupload sample पृष्ठ लौटाता है, जिसमें एक अपलोड फ़ॉर्म है:
method="POST" enctype="multipart/form-data" action="/upload.action"
यह पहले के लॉग से मेल खाता है जहाँ Struts2 ने MultiPartRequest के लिए jakarta चुना था: एप्लिकेशन में वास्तव में multipart/form-data के माध्यम से फ़ाइल अपलोड हैंडलिंग प्रवाह है।
⇒ सोच: एंडपॉइंट /upload.action multipart/form-data का उपयोग करता है, जो Struts2 द्वारा Jakarta MultiPartRequest के माध्यम से संसाधित तंत्र से मेल खाता है। यह S2-045/CVE-2017-5638 के संदेह को मजबूत करने वाला संकेत है, लेकिन यह निष्कर्ष निकालने से पहले हमें Struts2 संस्करण निर्धारित करना होगा। इसके बाद, struts2-core के संस्करण और एप्लिकेशन अमान्य Content-Type प्राप्त करने पर त्रुटियों को कैसे संभालता है, इसके बारे में गहन सत्यापन अभी भी आवश्यक है।
यह पहचानने के बाद कि एप्लिकेशन में multipart/form-data का उपयोग करने वाला अपलोड एंडपॉइंट है, अगला विश्लेषण चरण Struts2 का वास्तविक संस्करण खोजना है। यह महत्वपूर्ण है क्योंकि पिछले संकेतों ने केवल दर्शाया था कि एप्लिकेशन मल्टीपार्ट अपलोड से संबंधित तंत्र रखता है, जो अभी तक यह निष्कर्ष निकालने के लिए पर्याप्त नहीं है कि यह कमजोर है।
Endpoint 8001 की सेवा करने वाले सही कंटेनर की पहचान करने के बाद, लाइब्रेरीज़ की जाँच कंटेनर project1-lab01-1 के अंदर ही की जाती है।
परिणाम में struts2-core फ़ाइल मिली:
/root/.m2/repository/org/apache/struts/struts2-core/2.3.30/struts2-core-2.3.30.jar
इस पथ से, हम यह निर्धारित कर सकते हैं कि एप्लिकेशन Apache Struts2 2.3.30 का उपयोग कर रहा है।
प्रकाशित CVE-2017-5638 / S2-045 कमजोरी से इसकी तुलना करने पर, यह पैच से पहले कई पुराने Struts2 संस्करणों को प्रभावित करता है, जिसमें 2.3.x शाखा भी शामिल है। जब इसे निम्नलिखित के साथ जोड़ा जाता है:
Framework: Apache Struts2 Version: 2.3.30 Multipart parser: Jakarta Endpoint: /upload.action Content-Type: multipart/form-data
विश्लेषण स्थिति श्रृंखला स्पष्ट हो जाती है:
`Struts2 Version 2.3.30 < Version 2.3.32
हालाँकि, विश्लेषण के दृष्टिकोण से, एक कमजोर संस्करण केवल प्रभावित होने की संभावना का प्रमाण है। व्यवहार स्तर पर पुष्टि करने के लिए, हमें एक असामान्य मल्टीपार्ट अनुरोध भेजना होगा और प्रतिक्रिया/लॉग का निरीक्षण करना होगा कि क्या यह Struts2 मल्टीपार्ट पार्सर की त्रुटि हैंडलिंग शाखा में प्रवेश करता है।
⇒ सोच: इस बिंदु पर, यह अब केवल फ्रेमवर्क की पहचान करने के बारे में नहीं है; संस्करण 2.3.30 पुष्टि करता है कि एप्लिकेशन S2-045/CVE-2017-5638 की प्रभावित संस्करण श्रेणी के अंतर्गत आता है। साक्ष्य श्रृंखला को पूरा करने के लिए शेष चरण मल्टीपार्ट त्रुटि हैंडलिंग व्यवहार को सत्यापित करना है।
हमें यह जाँचने की आवश्यकता है कि क्या /upload.action को भेजे गए अनुरोध वास्तव में Struts2 मल्टीपार्ट प्रसंस्करण तंत्र से गुज़रते हैं। यहाँ, मैं हैंडलिंग तंत्र का परीक्षण करने के लिए -F विकल्प के साथ curl कमांड का उपयोग करता हूँ। और लौटाया गया परिणाम भागों में विभाजित है:
`
⇒ एक मान्य अनुरोध साबित करता है कि /upload.action वास्तव में मल्टीपार्ट अपलोड तंत्र से गुज़रता है क्योंकि curl -F multipart/form-data उत्पन्न करता है और सर्वर अनुरोध के प्रत्येक भाग को पार्स कर सकता है।
Content-Type को multipart/form-data घोषित करने वाला अनुरोध भेजने के बाद लेकिन ऐसे निकाय के साथ जो मल्टीपार्ट संरचना का पालन नहीं करता, सर्वर अभी भी HTTP 200 OK लौटाता है। हालाँकि, ContentType, FileName, File, और Caption फ़ील्ड सभी खाली हैं। Docker लॉग की जाँच करने पर, हम देखते हैं कि कोई बाउंड्री (मल्टीपार्ट में भागों के बीच विभाजक स्ट्रिंग) नहीं है, और क्लाइंट को अभी भी HTTP 200 OK प्राप्त होता है। हालाँकि, Struts2 वास्तव में अनुरोध को संसाधित करते समय एक त्रुटि का सामना किया।
यह साक्ष्य श्रृंखला साबित करता है:
दोषपूर्ण मल्टीपार्ट अनुरोध → Struts2 अनुरोध को लपेटता है → MultiPartRequestWrapper को कॉल किया जाता है → JakartaMultiPartRequest अनुरोध को पार्स करता है → गुम बाउंड्री के कारण FileUploadException
⇒ S2-045/CVE-2017-5638 से संबंधित घटकों से मेल खाता है। इस प्रकार, स्थिति श्रृंखला अधिक पूर्ण है: कमजोर संस्करण, जकार्ता पार्सर, अपलोड एंडपॉइंट, और दोषपूर्ण अनुरोध सही मल्टीपार्ट प्रसंस्करण शाखा में जाता है।
