चरण-दर-चरण लैब गाइड CVE-2017-10271 (WebLogic XMLDecoder deserialization RCE) का शोषण करने के लिए, मैन्युअल पेलोड निर्माण, ब्लाइंड RCE बाईपास, और पोस्ट-एक्सप्लॉइटेशन तकनीकें जिसमें विशेषाधिकार सत्यापन और डेटा निष्कासन शामिल हैं।
AdminServer base_domain से संबंधित, Development Mode में चल रहा है)।7001।http, t3, iiop, ldap, snmp।7001 पर t3 प्रोटोकॉल को उजागर करती है। यह डिफ़ॉल्ट कॉन्फ़िगरेशन उच्च जोखिम वहन करता है यदि वेबलॉजिक संस्करण को RMI (रिमोट मेथड इनवोकेशन) के माध्यम से जावा ऑब्जेक्ट डिसीरियलाइज़ेशन से संबंधित कमजोरियों के विरुद्ध पैच नहीं किया गया है।7001 पर http प्रोटोकॉल पर चलता है, जो इसे /console/login/LoginForm.jsp जैसे संवेदनशील एंडपॉइंट के लिए निर्देशिका स्कैनिंग के प्रति संवेदनशील बनाता है।एक बार लक्ष्य के खुले पोर्ट की पहचान हो जाने के बाद, हम उसके चल रहे सेवा को निर्धारित करने के लिए पोर्ट को स्कैन करने के लिए nmap का उपयोग करेंगे।
इस प्रकार, लक्ष्य एक HTTP सेवा चला रहा है जिसका संस्करण Oracle WebLogic Server 10.3.6.0 है - एक प्रसिद्ध एंटरप्राइज़ जावा एप्लिकेशन सर्वर जो महत्वपूर्ण CVEs (जैसे डिसीरियलाइज़ेशन, प्रमाणीकरण बायपास) की एक श्रृंखला के लिए प्रसिद्ध है। हालाँकि, यह जानकारी अकेले यह निष्कर्ष निकालने के लिए पर्याप्त नहीं है कि सिस्टम किस विशिष्ट कमजोरी के प्रति संवेदनशील है। हमें साथ के वेब सेवा घटकों में गहराई से स्कैन करने की आवश्यकता है।
हम dirsearch टूल का उपयोग करके इसके संवेदनशील एंडपॉइंट की पहचान करने के लिए आगे बढ़ेंगे। चूँकि वेबलॉजिक जावा प्लेटफ़ॉर्म पर चलता है, .jsp और .xml फ़ाइलें सबसे संवेदनशील लक्ष्य हैं। हम 200 स्थिति कोड लौटाने वाले एंडपॉइंट पर ध्यान केंद्रित करेंगे।
dirsearch -u http://192.168.3.137:7001/ -e jsp,xml,html
/console/login/LoginForm.jsp: वेबलॉजिक एडमिन कंसोल वेब इंटरफ़ेस का लॉगिन पोर्टल। यह डिफ़ॉल्ट क्रेडेंशियल ब्रूट-फोर्सिंग परिदृश्यों या प्रमाणीकरण बायपास कमजोरियों (जैसे CVE-2020-14882) के लिए एक महत्वपूर्ण लक्ष्य है।/bea_wls_internal/: वेबलॉजिक सर्वर की डिफ़ॉल्ट आंतरिक वेब एप्लिकेशन निर्देशिका। यह घटक स्थिर सिस्टम फ़ाइलों तक पहुँच और इंटरैक्शन की अनुमति देता है।/wls-wsat/CoordinatorPortType: यह सबसे महत्वपूर्ण खोज है। 200 OK स्थिति कोड के साथ इस पथ की उपस्थिति पुष्टि करती है कि वेब सर्विसेज़ एटॉमिक ट्रांज़ैक्शंस (wls-wsat) घटक सक्षम है और डेटा प्राप्त करने के लिए तैयार है।/uddiexplorer और /uddi/uddilistener: यह UDDI एक्सप्लोरर (यूनिवर्सल डिस्क्रिप्शन, डिस्कवरी, एंड इंटीग्रेशन) घटक है जो वेबलॉजिक सर्वर में वेब सेवाओं के प्रबंधन और पंजीकरण के लिए डिफ़ॉल्ट रूप से एकीकृत होता है। यह घटक SSRF (सर्वर-साइड रिक्वेस्ट फोर्जरी) - CVE-2014-4210 कमजोरी के लिए अत्यंत प्रसिद्ध है। एक हमलावर एंडपॉइंट /uddiexplorer/SearchPublicRegistries.jsp पर UDDI के सार्वजनिक रजिस्ट्री खोज इंटरफ़ेस का लाभ उठाकर वेबलॉजिक सर्वर को बैकएंड आंतरिक नेटवर्क पर मनमाने HTTP अनुरोध भेजने के लिए मजबूर कर सकता है।⇒ सोच: /wls-wsat (XMLDecoder के माध्यम से RCE जोखिम) और /uddiexplorer (SSRF जोखिम) का सह-अस्तित्व इंगित करता है कि इस वेबलॉजिक सर्वर की आक्रमण सतह अत्यंत व्यापक है।
वेबलॉजिक 10.3.6.0 सर्वर पर दो स्वतंत्र आक्रमण सतहों के सह-अस्तित्व की पहचान करने के बाद, हम दो दिशाओं का विश्लेषण करते हैं:
/uddiexplorer पर:
/wls-wsat पर:
⇒ निर्णय: साइबर अटैक चेन मॉडल में, RCE हमेशा अंतिम लक्ष्य होता है क्योंकि यह सिस्टम का प्रत्यक्ष और पूर्ण नियंत्रण (Full System Compromise) प्रदान करता है। एक बार RCE क्षमता प्राप्त हो जाने के बाद, UDDI एप्लिकेशन के माध्यम से SSRF का शोषण करना अनावश्यक हो जाता है। ऐसा इसलिए है क्योंकि RCE शेल से, हम UDDI इंटरफ़ेस के मापदंडों द्वारा प्रतिबंधित हुए बिना, सीधे, लचीले और अधिक शक्तिशाली तरीके (सिस्टम कमांड जैसे curl, wget का उपयोग करके) आंतरिक नेटवर्क क्वेरी सक्रिय रूप से कर सकते हैं।
इसलिए, शोषण प्राथमिकता तर्क के संदर्भ में, हम द्वितीयक पथ (SSRF /uddiexplorer पर) को बाहर करने और पूरी तरह से शोध पर ध्यान केंद्रित करने का निर्णय लेते हैं: /wls-wsat/CoordinatorPortType पर XMLDecoder डिसीरियलाइज़ेशन कमजोरी के माध्यम से रिमोट कोड निष्पादन (RCE)।
CVE-2017-10271 की मूल कमजोरी इसलिए होती है क्योंकि वेबलॉजिक का WorkContextXmlInputAdapter वर्ग <work:WorkContext> टैग में डेटा को पार्स करने के लिए java.beans.XMLDecoder ऑब्जेक्ट का उपयोग करता है। डिफ़ॉल्ट रूप से, यह XMLDecoder वर्ग स्वचालित रूप से XML टैग फॉर्म में परिभाषित किसी भी जावा क्लास को इंस्टेंशिएट करेगा। यहाँ से, हम चरण-दर-चरण सिस्टम व्यवहारिक इंटरैक्शन के आधार पर सत्यापन करते हैं।
इस सर्वलेट की वास्तविक सक्रिय स्थिति को जल्दी से सत्यापित करने के लिए, एक नियमित HTTP GET जांच अनुरोध भेजें:
curl -i -s http://192.168.3.137:7001/wls-wsat/CoordinatorPortType
प्रतिक्रिया HTTP/1.1 200 OK के साथ-साथ कार्यान्वयन वर्ग CoordinatorPortTypePortImpl लौटाती है, यह पुष्टि करते हुए कि सर्वलेट को JVM मेमोरी में सफलतापूर्वक लोड किया गया है।
चूँकि वेब सेवाओं के सर्वलेट्स को POST विधि के माध्यम से SOAP XML डेटा को संसाधित करने के लिए डिज़ाइन किया गया है, हम सिस्टम के डेटा प्रोसेसिंग पाइपलाइन को प्रदर्शित करने के लिए दो POST अनुरोधों के साथ तुलनात्मक परीक्षण करते हैं:
1. मानक SOAP POST अनुरोध
हम पार्सर की सामान्य पार्सिंग क्षमता का परीक्षण करने के लिए एक मानक SOAP XML एनवलप (पूर्ण नामस्थानों के साथ लेकिन निष्पादन सामग्री के बिना) भेजते हैं।
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'>soapenv:Header/soapenv:Body/</soapenv:Envelope>"
Cannot find dispatch method)।विश्लेषण:
सर्वर के पास POST पोर्ट पर एक अच्छी तरह से काम करने वाला XML रीडर है, जो उपयोगकर्ता द्वारा भेजे गए पूरे XML ट्री स्ट्रक्चर को प्राप्त करने और डिकोड करने के लिए तैयार है। यह पुष्टि करता है कि क्लाइंट से वेबलॉजिक की मेमोरी में गहराई तक डेटा पाइपलाइन पूरी तरह से चालू है।
2. दूषित XML POST अनुरोध
इसके बाद, हम पार्सर के अपवाद हैंडलिंग तंत्र का निरीक्षण करने के लिए जानबूझकर XML संरचना को तोड़ते हैं (जैसे, नामस्थानों को छोड़ना)।
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "soapenv:Envelopesoapenv:Headerwork:WorkContextinvalid_xml_structure</work:WorkContext></soapenv:Header></soapenv:Envelope>"
com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "soapenv" लौटाता है।विश्लेषण: