CVE-2026-20230 Cisco Unified Communications Manager SSRF मनमानी फ़ाइल लेखन से RCE PoC व्युत्पत्ति प्रक्रिया और विचार

उपयोग का दायरा: केवल स्थानीय परीक्षण वातावरण, अधिकृत पुनरुत्पादन वातावरण, भेद्यता सत्यापन और सुरक्षा नियम विश्लेषण के लिए। अनधिकृत लक्ष्यों पर उपयोग न करें। यह लेख मुख्य रूप से CVE-2026-20230 के शोषण श्रृंखला, सत्यापन योग्य घटनाओं, निर्णय तर्क और सुरक्षा रणनीतियों का विश्लेषण करता है, और सीधे कॉपी-पेस्ट करने योग्य आक्रमण संदेश, WebShell सामग्री या कमांड निष्पादन पेलोड प्रदान नहीं करता है।

1. भेद्यता पृष्ठभूमि

CVE-2026-20230 Cisco Unified Communications Manager (Unified CM / CUCM) और Cisco Unified Communications Manager Session Management Edition (Unified CM SME) में एक सर्वर-साइड रिक्वेस्ट फोर्जरी (SSRF) भेद्यता है। यह भेद्यता विशिष्ट HTTP अनुरोध प्रसंस्करण प्रवाह में अपर्याप्त इनपुट सत्यापन के कारण उत्पन्न होती है, जिससे हमलावर बिना प्रमाणीकरण के अनुरोध बना सकता है, जिससे प्रभावित उपकरण हमलावर की ओर से आंतरिक इंटरफेस या स्थानीय संसाधनों तक पहुँच सकता है।

इस भेद्यता का प्रभाव सामान्य SSRF जांच से कहीं अधिक है। सार्वजनिक तकनीकी विश्लेषण से पता चलता है कि विशिष्ट संस्करणों और सेवा सक्षम होने की स्थितियों में, SSRF को आगे चलकर मनमानी फ़ाइल लेखन क्षमता में जोड़ा जा सकता है। हमलावर नियंत्रित सामग्री को अंतर्निहित ऑपरेटिंग सिस्टम पथों में लिख सकता है, और फिर Web कंटेनर के सुलभ निर्देशिका या सर्वर-साइड घटक लोडिंग तंत्र का उपयोग करके फ़ाइल लेखन को कोड निष्पादन में बदल सकता है।

Cisco ने इस भेद्यता को CVSS v3.1 स्कोर 8.6 दिया है, वेक्टर इस प्रकार है:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N

हालाँकि CVSS स्कोर High दिखाता है, Cisco ने इस भेद्यता के लिए Security Impact Rating को Critical चिह्नित किया है। इसका कारण यह है कि सफल शोषण के बाद अंतर्निहित ऑपरेटिंग सिस्टम फ़ाइलों में लिखा जा सकता है और इसे root अनुमतियों तक बढ़ाया जा सकता है।

विशेष रूप से ध्यान देने योग्य बात यह है कि इस भेद्यता की महत्वपूर्ण पूर्व शर्त यह है कि WebDialer सेवा सक्षम होनी चाहिए। WebDialer डिफ़ॉल्ट रूप से बंद है, इसलिए केवल CUCM संपत्ति देखकर सीधे यह निर्णय नहीं लेना चाहिए कि भेद्यता शोषण योग्य है। वास्तविक जोखिम निर्णय के लिए उत्पाद संस्करण, पैच स्थिति, WebDialer सेवा स्थिति और संबंधित इंटरफेस की पहुँच क्षमता की पुष्टि करनी होगी।

2. केवल एक इंटरफ़ेस के 200 रिटर्न करने पर निर्णय क्यों नहीं लेना चाहिए?

यह भेद्यता कोई सामान्य Web भेद्यता नहीं है जहाँ "किसी निश्चित URL पर जाने पर 200 रिटर्न होता है तो भेद्यता मौजूद है"। इसके शोषण श्रृंखला में कम से कम तीन स्तर शामिल हैं:

1. बाह्य रूप से सुलभ WebDialer या cmplatform संबंधित इंटरफ़ेस।
2. SSRF द्वारा प्रभावित आंतरिक पहुँच तर्क।
3. आंतरिक अनुरोधों द्वारा और अधिक ट्रिगर की जा सकने वाली फ़ाइल लेखन या सेवा तैनाती व्यवहार।

इसलिए, किसी इंटरफ़ेस पर अकेले HTTP 200, 302, 401, 404 या 500 प्राप्त करना सीधे भेद्यता के अस्तित्व या अनुपस्थिति को साबित नहीं करता है।

उदाहरण के लिए, WebDialer WSDL इंटरफ़ेस तक पहुँच केवल यह दर्शाती है कि लक्ष्य ने WebDialer से संबंधित कार्यक्षमता को उजागर किया है, यह साबित नहीं करता कि आगे SSRF फ़िल्टर को बायपास कर सकता है। installClusterStatusExecute इंटरफ़ेस तक पहुँच केवल यह दर्शाती है कि संबंधित प्रवेश बिंदु मौजूद है, यह अकेले मनमानी फ़ाइल लेखन स्थापित नहीं करता। इसके विपरीत, यदि कोई चरण असामान्य परिणाम देता है, तो यह लक्ष्य संस्करण, पैच, होस्टनाम रिज़ॉल्यूशन, पथ अनुमतियाँ, प्रॉक्सी उपकरण या सेवा स्थिति के कारण हो सकता है, और जरूरी नहीं कि पूरी भेद्यता श्रृंखला मौजूद न हो।

अधिक सुरक्षित निर्णय बहु-चरण साक्ष्य संयोजन का उपयोग करना चाहिए:

1. पुष्टि करें कि लक्ष्य Cisco Unified CM / Unified CM SME है।
2. पुष्टि करें कि WebDialer सेवा सक्षम स्थिति में है।
3. पुष्टि करें कि लक्ष्य का वास्तविक होस्टनाम या आंतरिक सेवा पहचान प्राप्त की जा सकती है।
4. पुष्टि करें कि SSRF प्रवेश बिंदु सुलभ है, और सर्वर-साइड द्वारा आंतरिक अनुरोध शुरू करने के संकेत मौजूद हैं।
5. अधिकृत परीक्षण वातावरण में पुष्टि करें कि नियंत्रित फ़ाइल लेखन साक्ष्य उत्पन्न किया जा सकता है या नहीं।
6. सर्वर-साइड लॉग, फ़ाइल सिस्टम परिवर्तन, Web कंटेनर लॉग और अलर्ट डेटा के संयोजन से निर्णय लें कि वास्तविक ट्रिगर हुआ या नहीं।

केवल जब "WebDialer सक्षम + प्रभावित संस्करण + SSRF व्यवहार स्थापित + नियंत्रित फ़ाइल लेखन स्थापित" एक साथ दिखाई दें, तभी इसे उच्च विश्वसनीयता वाला शोषण योग्य माना जाना चाहिए।

3. PoC निर्माण विचार

वर्तमान सार्वजनिक शोषण श्रृंखला का मूल केवल SSRF नहीं है, बल्कि SSRF और Axis/Java Web सेवा तंत्र, लॉग लेखन या तैनाती विवरण फ़ाइल प्रसंस्करण तर्क के बीच संयुक्त शोषण है।

समग्र विचार को इस प्रकार संक्षेपित किया जा सकता है:

WebDialer जानकारी प्राप्ति
    ↓
लक्ष्य का वास्तविक होस्टनाम प्राप्त करना
    ↓
cmplatform संबंधित इंटरफ़ेस के माध्यम से SSRF ट्रिगर करना
    ↓
आंतरिक WebDialer / Axis प्रबंधन पथ तक पहुँच
    ↓
नियंत्रित सेवा विवरण सामग्री लिखना या तैनात करना
    ↓
नई कॉल करने योग्य सेवा या फ़ाइल लेखन क्षमता बनाना
    ↓
फ़ाइल लेखन क्षमता को Web-सुलभ स्क्रिप्ट में बदलना
    ↓
विशिष्ट वातावरण में आगे कमांड निष्पादन प्राप्त करना

श्रृंखला डिज़ाइन से देखें तो, होस्टनाम एक महत्वपूर्ण बिंदु है। कुछ फ़िल्टर तर्क 127.0.0.1, localhost जैसे सामान्य स्थानीय पतों को रोक सकते हैं, लेकिन लक्ष्य का वास्तविक होस्टनाम बाद के अनुरोध प्रवाह में प्रवेश की अनुमति दे सकता है। इसलिए, PoC पहले WebDialer के WSDL जानकारी से वास्तविक होस्टनाम निकालेगा, और फिर इसे SSRF श्रृंखला में आंतरिक पहुँच उपसर्ग के रूप में उपयोग करेगा।

दूसरा महत्वपूर्ण बिंदु Axis सेवा संबंधित तर्क है। PoC सीधे Web निर्देशिका में फ़ाइल अपलोड नहीं करता है, बल्कि आंतरिक सेवा प्रसंस्करण श्रृंखला के माध्यम से सर्वर-साइड घटक को हमलावर-नियंत्रित सामग्री को विशिष्ट पथ पर लिखने के लिए प्रेरित करता है। यह प्रक्रिया मूल रूप से "सर्वर-साइड आंतरिक अनुरोध + घटक कॉन्फ़िगरेशन/लॉग लेखन व्यवहार + पथ ट्रैवर्सल/पथ नियंत्रण" का संयोजन है।

तीसरा महत्वपूर्ण बिंदु दो-चरणीय लेखन है। पहला चरण आमतौर पर अधिक स्थिर फ़ाइल लेखन प्रवेश बिंदु स्थापित करने के लिए होता है, और दूसरा चरण कमांड निष्पादन स्क्रिप्ट को Web-सुलभ निर्देशिका में लिखता है। ऐसा करने का कारण यह है कि SSRF के माध्यम से एक ही चरण में पूर्ण कमांड निष्पादन तर्क लिखना एन्कोडिंग, लंबाई, XML संरचना, पथ अनुमतियों और सर्वर-साइड पार्सिंग व्यवहार से प्रभावित हो सकता है, जबकि दो-चरणीय विधि जटिल पेलोड को विभाजित करना आसान बनाती है।

यह लेख पूर्ण शोषण संदेश और WebShell सामग्री प्रदान नहीं करता है। सुरक्षा और सत्यापन के लिए केवल निम्नलिखित मुख्य विशेषताओं को समझना आवश्यक है:

बाह्य अनुरोध प्रवेश बिंदु: cmplatform स्थापना स्थिति संबंधित इंटरफ़ेस
जानकारी प्राप्ति प्रवेश बिंदु: WebDialer WSDL / services संबंधित इंटरफ़ेस
आंतरिक अग्रेषण लक्ष्य: WebDialer / Axis / AdminService संबंधित पथ
मुख्य व्यवहार: SSRF, सर्वर-साइड आंतरिक अनुरोध, नियंत्रित फ़ाइल लेखन, Web-सुलभ फ़ाइल अवतरण
अंतिम जोखिम: मनमानी फ़ाइल लेखन, WebShell अवतरण, कमांड निष्पादन, root अनुमति वृद्धि पथ

4. होस्टनाम प्राप्ति तर्क

PoC को पहले लक्ष्य का वास्तविक होस्टनाम प्राप्त करना होता है, न कि केवल IP पता या बाह्य डोमेन नाम का उपयोग करना।

इसका कारण यह है कि SSRF फ़िल्टर तर्क केवल अंतिम कनेक्शन लक्ष्य का ही निर्णय नहीं कर सकता, बल्कि होस्टनाम फ़ील्ड, URL स्ट्रिंग, स्थानीय पता कीवर्ड आदि की भी जाँच कर सकता है। सामान्य स्थानीय पते जैसे 127.0.0.1, localhost को अवरुद्ध किया जा सकता है, जबकि उपकरण का वास्तविक होस्टनाम कुछ परिदृश्यों में वैध नोड नाम माना जा सकता है।

सहायक निर्णय के लिए उपयोग किए जा सकने वाले इंटरफ़ेस आमतौर पर WebDialer WSDL जानकारी से संबंधित होते हैं। ऐसे WSDL तक पहुँचने के बाद, प्रतिक्रिया में सेवा पता, location फ़ील्ड या अन्य पार्स करने योग्य होस्ट पहचान शामिल हो सकती है। PoC प्रतिक्रिया टेक्स्ट से URL में होस्टनाम निकालेगा और इसे अगले चरण के SSRF के आंतरिक पहुँच लक्ष्य के रूप में उपयोग करेगा।

इस चरण का निर्णय मानदंड होना चाहिए:

1. क्या WSDL इंटरफ़ेस सुलभ है?
2. क्या प्रतिक्रिया सामग्री WebDialer / Axis सेवा विशेषताओं से मेल खाती है?
3. क्या प्रतिक्रिया से वास्तविक होस्टनाम पार्स किया जा सकता है?
4. क्या पार्स किया गया होस्टनाम बाह्य पहुँच IP या डोमेन से भिन्न है?
5. क्या यह होस्टनाम बाद के SSRF प्रवेश बिंदु द्वारा स्वीकार किया जा सकता है?