dungsocool/cve-2017-11610सीवीई-2017-11610 (Supervisord XML-RPC RCE) के लिए चरण-दर-चरण एक्सप्लॉइट राइटअप, जिसमें आक्रमण सतह विश्लेषण, नेमस्पेस ट्रैवर्सल खोज और Docker लैब वातावरण में पोस्ट-एक्सप्लॉइटेशन तकनीकें शामिल हैं।
वातावरण में क्या चल रहा है, इससे शुरुआत करते हुए। मैं सभी सक्रिय कंटेनरों की सूची बनाता हूँ:``` docker ps-a
**पीड़ित केवल एक पोर्ट उजागर करता है: `9001`**।
पोर्ट 9001 एक मानक वेब ऐप नहीं है। **पोर्ट डेटाबेस** में खोजने पर पता चलता है कि यह पोर्ट **Supervisord** (IANA के अनुसार ETL Service Manager), Tor प्रॉक्सी, या किसी अन्य आंतरिक सेवा से जुड़ा हो सकता है। हालाँकि, हम केवल पोर्ट नंबर के आधार पर कोई निष्कर्ष नहीं निकाल सकते।
⇒ मैं प्रतिक्रिया पढ़ने के लिए सीधे curl करता हूँ और अधिक जानकारी जुटाने के लिए वेब GUI तक भी पहुँचता हूँ```
curl -i http://192.168.3.137:9001/
प्रतिक्रिया विश्लेषण:
Server: Medusa/1.12 और शीर्षक Supervisor Status प्रदर्शित करती है→ इसकी पुष्टि होती है कि यह Supervisord है, न कि Tor या कोई अन्य सेवा।
REFRESH, RESTART ALL, STOP ALLSupervisord Linux पर एक प्रोसेस मैनेजर है। यदि port 9001 बिना पासवर्ड के नेटवर्क पर उजागर है, तो यह एक खतरनाक कॉन्फ़िगरेशन है। एक हमलावर सेवाओं को देख सकता है, प्रोसेस को पुनः प्रारंभ/रोक सकता है, और कुछ कॉन्फ़िगरेशन में, यदि उनके पास प्रबंधित प्रोग्रामों को संशोधित या नियंत्रित करने के विशेषाधिकार हैं, तो कमांड निष्पादित करने के लिए इसका शोषण कर सकता है।
विश्लेषण निष्कर्ष: हम पुष्टि कर सकते हैं कि लक्ष्य Supervisord प्रशासन इंटरफ़ेस को पोर्ट 9001 पर नेटवर्क के लिए उजागर कर रहा है। यह एक मानक वेब सेवा नहीं है, बल्कि एक प्रबंधन इंटरफ़ेस है जिसका उपयोग प्रोसेस की निगरानी और नियंत्रण के लिए किया जाता है। इस इंटरफ़ेस को बिना प्रमाणीकरण के एक्सेस करने की क्षमता एक जोखिम पैदा करती है कि एक हमलावर प्रबंधित सेवाओं की स्थिति देख सकता है या उनसे इंटरैक्ट कर सकता है।
हालाँकि, हमें दृश्यमान UI और अंतर्निहित नियंत्रण तंत्र के बीच अंतर करना होगा। REFRESH, RESTART ALL, और STOP ALL जैसे बटन फ्रंटएंड पर अनुरोधों को स्वतंत्र रूप से संसाधित नहीं करते; इसके बजाय, उन्हें स्थिति प्राप्त करने या प्रोसेस नियंत्रण कमांड भेजने के लिए Supervisord के इंटरफ़ेस/बैकएंड को कॉल करना होता है। इसलिए, वेब UI के उजागर होने की पुष्टि करने के बाद, अगला विश्लेषण चरण यह निर्धारित करना है कि वेब UI के पीछे अंतर्निहित नियंत्रण इंटरफ़ेस मौजूद है या नहीं और क्या उसे प्रमाणीकरण की आवश्यकता है।
⇒ सोच: यह जाँचने की आवश्यकता है कि वेब UI के पीछे का नियंत्रण इंटरफ़ेस मौजूद है या नहीं और क्या उसे प्रमाणीकरण की आवश्यकता है।
Supervisor के दस्तावेज़ीकरण के अनुसार, [inet_http_server] एक HTTP सर्वर है जो TCP सॉकेट पर सुनता है। यह इंटरफ़ेस डिफ़ॉल्ट रूप से सक्षम नहीं है, केवल विश्वसनीय वातावरण में उपयोग किया जाना चाहिए, एन्क्रिप्शन का समर्थन नहीं करता, और जब तक username/password कॉन्फ़िगर न हो, कोई डिफ़ॉल्ट प्रमाणीकरण नहीं होता।
दस्तावेज़ीकरण यह भी इंगित करता है कि [inet_http_server] का पोर्ट HTTP/XML-RPC अनुरोधों को प्राप्त करने के लिए उपयोग किया जाता है; supervisorctl इस पोर्ट के माध्यम से supervisord के साथ संवाद करने के लिए XML-RPC का उपयोग करता है। यह प्रयोगशाला में हमारे अवलोकन से मेल खाता है: कंटेनर 0.0.0.0:9001->9001/tcp को उजागर करता है, वेब UI बिना प्रमाणीकरण के सुलभ है, और प्रदर्शित संस्करण Supervisor 3.3.2 है।
इस प्रकार, पोर्ट 9001 पर वेब UI की पुष्टि करने के बाद, अगला कदम XML-RPC एंडपॉइंट /RPC2 का निरीक्षण करना है। Supervisord के आधिकारिक तंत्र के आधार पर, हमें इन उद्देश्यों को सत्यापित करने की आवश्यकता है:
/RPC2 मौजूद है।supervisor.getState या system.listMethods जैसे गैर-विनाशकारी तरीकों को कॉल कर सकते हैं।जाँचें कि क्या एंडपॉइंट सक्रिय है:```
curl -i -s -X POST -H "Content-Type: text/xml"
-d 'supervisor.getState'
http://192.168.3.137:9001/RPC2
परिणाम `HTTP/1.1 200 OK` लौटाता है, न कि `401 Unauthorized` या `403 Forbidden`, जो दर्शाता है कि अनुरोध को सर्वर द्वारा बिना किसी क्रेडेंशियल के स्वीकार कर लिया गया। प्रतिक्रिया XML-RPC `<methodResponse>` प्रारूप में है और इसमें `statename=RUNNING` तथा `statecode=1` शामिल है, जो सिद्ध करता है कि `/RPC2` एंडपॉइंट सक्रिय है और `supervisor.getState` मेथड सफलतापूर्वक निष्पादित हुई।
**⇒ सोच:** अटैक सतह अब केवल Web UI तक सीमित नहीं है, बल्कि XML-RPC API तक विस्तारित हो गई है, जहाँ डेमॉन/प्रोसेस नियंत्रण कमांड संभाले जाते हैं। यहाँ से, अगली विश्लेषण दिशा यह है कि **Supervisor** XML-RPC में `methodName` को **कैसे हैंडल करता है**, ताकि यह निर्धारित किया जा सके कि वर्तमान लक्ष्य **CVE-2017-11610 का व्यवहार प्रदर्शित करता है या नहीं**, जो इस मेथड के dispatch/lookup तंत्र में स्थित है। यह सुनिश्चित करने के लिए हमें इसकी पुष्टि करनी होगी कि यह **CVE-2017-11610** है या नहीं।
### **XML-RPC में मेथड नाम प्रोसेसिंग का विश्लेषण**
पिछले चरण में, हमने `/RPC2` एंडपॉइंट के माध्यम से `supervisor.getState` मेथड को सफलतापूर्वक कॉल किया। इससे अगला प्रश्न उठता है: जब कोई स्ट्रिंग-आधारित `methodName` प्राप्त होता है, तो Supervisord उस स्ट्रिंग को आंतरिक Python फ़ंक्शन से कैसे मैप करता है?
XML-RPC में, मेथड्स आमतौर पर नेमस्पेस का उपयोग करती हैं, उदाहरण के लिए:
- `supervisor.getState`
- `supervisor.stopProcess`
- `supervisor.getAllProcessInfo`
तार्किक रूप से, सर्वर `methodName` स्ट्रिंग प्राप्त करता है, उसे डॉट `.` द्वारा विभाजित करता है, और पंजीकृत हैंडलर के अंदर संबंधित ऑब्जेक्ट/फ़ंक्शन खोजता है।
स्यूडो-कोड को इस प्रकार समझा जा सकता है:
```python
# Pseudo-code: how the server might handle the incoming methodName
method = get_string_from_request()
if "." in method:
namespace, func_name = method.split(".", 1)
handler = registry[namespace]
result = handler.call(func_name, *params)
else:
handler = registry[method]
result = handler.call(*params)
``````python
# Pseudo-code simulating the dispatch method concept in XML-RPC
def dispatch(method_name, params):
parts = method_name.split(".") # ["supervisor", "getState"]
obj = registered_handlers[parts[0]] # get namespace "supervisor"
for attr in parts[1:]:
obj = getattr(obj, attr) # lookup the next attribute
return obj(*params) # call the final function
मानक तरीकों जैसे supervisor.getState के लिए, यह तंत्र सामान्य रूप से कार्य करता है: सर्वर supervisor हैंडलर को प्राप्त करता है, फिर getState फ़ंक्शन को कॉल करता है। हालाँकि, CVE-2017-11610 की मुख्य समस्या यह है कि यह लुकअप तंत्र एक्सेस किए जा सकने वाले एट्रिब्यूट्स को पर्याप्त रूप से प्रतिबंधित नहीं करता। यदि कोई हमलावर methodName को नियंत्रित करता है, तो वे न केवल getState जैसी सार्वजनिक विधियों को कॉल कर सकते हैं, बल्कि supervisor हैंडलर से पहुंच योग्य आंतरिक ऑब्जेक्ट्स/मॉड्यूल्स में गहराई तक प्रवेश भी कर सकते हैं।
दूसरे शब्दों में, methodName में डॉट . केवल वैध विधियों को आमंत्रित करने के लिए उपयोग नहीं होता, बल्कि इसका दुरुपयोग ऑब्जेक्ट एट्रिब्यूट्स को ट्रैवर्स करने के लिए भी किया जा सकता है।
यह हमारा शोषण पथ स्थापित करता है:
supervisor → supervisord → options → warnings → linecache → os → system