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 प्रवेश बिंदु द्वारा स्वीकार किया जा सकता है?

यदि होस्टनाम पार्सिंग विफल होती है, तो PoC लक्ष्य IP पर वापस आ सकता है, लेकिन इससे सफलता दर काफी कम हो जाएगी। वास्तविक वातावरण में, होस्टनाम पार्सिंग विफलता के सामान्य कारणों में WebDialer सक्षम न होना, इंटरफ़ेस का पहुँच नियंत्रण द्वारा सीमित होना, प्रतिक्रिया का रिवर्स प्रॉक्सी द्वारा पुनर्लेखन, या प्रमाणपत्र / सेवा कॉन्फ़िगरेशन का अधूरा होना शामिल है।

5. SSRF ट्रिगर चरण

SSRF ट्रिगर बिंदु cmplatform संबंधित स्थापना स्थिति क्वेरी तर्क में स्थित है। यह कार्यक्षमता मूल रूप से क्लस्टर नोड स्थापना स्थिति की जाँच करने के लिए है, और सर्वर उपयोगकर्ता द्वारा प्रस्तुत नोड पहचान या होस्टनाम के आधार पर आंतरिक अनुरोध बनाता है।

भेद्यता की मुख्य समस्या यह है कि हमलावर-नियंत्रित होस्टनाम पैरामीटर को वैध नोड नाम या विश्वसनीय होस्ट तक सख्ती से सीमित नहीं किया गया है, जिससे इस पैरामीटर को अधिक जटिल आंतरिक पहुँच पथ के रूप में बनाया जा सकता है। फिर सर्वर हमलावर की ओर से आंतरिक इंटरफ़ेस पर अनुरोध शुरू करेगा।

इस चरण का मुख्य बिंदु "बाह्य URL तक पहुँचने की क्षमता" नहीं है, बल्कि "CUCM उपकरण को स्वयं अपने आंतरिक रूप से सुलभ WebDialer / Axis प्रबंधन इंटरफ़ेस तक पहुँचने देना" है। इसलिए, SSRF का मूल्य दो पहलुओं से आता है:

1. बाह्य नेटवर्क पहुँच प्रतिबंधों को बायपास करना और केवल स्थानीय मशीन या आंतरिक घटकों द्वारा सुलभ सेवा पथों तक पहुँचना।
2. आंतरिक सेवा विश्वास सीमा का उपयोग करके सामान्य HTTP पैरामीटर को आंतरिक घटक संचालन में बदलना।

अधिकृत सत्यापन में, केवल HTTP स्थिति कोड के आधार पर SSRF की सफलता का निर्णय नहीं किया जाना चाहिए। अधिक विश्वसनीय साक्ष्य में शामिल हैं:

1. सर्वर-साइड लॉग में आंतरिक पथ तक पहुँच के रिकॉर्ड दिखाई देना।
2. अनुरोध प्रतिक्रिया सामग्री में आंतरिक इंटरफ़ेस विशेषताएँ दिखाई देना।
3. बाद के WebDialer services पृष्ठ पर नई या असामान्य सेवा के निशान दिखाई देना।
4. फ़ाइल सिस्टम में सर्वर-साइड प्रक्रिया द्वारा बनाई गई असामान्य फ़ाइलें दिखाई देना।
5. सुरक्षा उपकरणों द्वारा रिकॉर्ड किया जाना कि होस्टनाम पैरामीटर में असामान्य पथ, एन्कोडेड सामग्री या आंतरिक सेवा पथ शामिल हैं।

6. Axis सेवा लेखन और मनमानी फ़ाइल लेखन विचार

सार्वजनिक श्रृंखला में, SSRF का उपयोग Axis सेवा इंटरफ़ेस तक पहुँचने और सेवा तैनाती विवरण सामग्री लिखने का प्रयास करने के लिए किया जाता है। हमलावर विशेष XML/WSDD संरचना बनाकर सर्वर-साइड घटक को प्रसंस्करण के दौरान नियंत्रित सामग्री को निर्दिष्ट पथ पर लिखने के लिए प्रेरित करता है।

इस चरण का सार पारंपरिक फ़ाइल अपलोड नहीं है, बल्कि सर्वर-साइड घटक के प्रसंस्करण तर्क का दुरुपयोग है:

उपयोगकर्ता-नियंत्रित पैरामीटर
    ↓
SSRF आंतरिक अनुरोध
    ↓
Axis / Web सेवा प्रसंस्करण
    ↓
नियंत्रित तैनाती विवरण या लॉग लेखन
    ↓
निर्दिष्ट पथ फ़ाइल निर्माण

सुरक्षा विश्लेषण के दृष्टिकोण से, यहाँ कई महत्वपूर्ण बिंदु हैं:

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

इसलिए, CVE-2026-20230 का उच्च जोखिम बिंदु केवल SSRF नहीं है, बल्कि यह है कि SSRF विश्वास सीमा को पार करके आंतरिक प्रबंधन/सेवा तैनाती श्रृंखला में प्रवेश कर सकता है, और अंततः नियंत्रित फ़ाइल लेखन को ट्रिगर कर सकता है।

7. दो-चरणीय WebShell लेखन तर्क

PoC डिज़ाइन में आमतौर पर दो-चरणीय लेखन का उपयोग किया जाता है, न कि एक ही चरण में कमांड निष्पादन।

पहला चरण एक सरल फ़ाइल लेखन क्षमता बनाने के लिए होता है। इस चरण का लक्ष्य हमलावर को एक Web-सुलभ पथ के माध्यम से सर्वर पर निर्दिष्ट स्थान पर सामग्री लिखने में सक्षम बनाना है।

दूसरा चरण पहले चरण की लेखन क्षमता का उपयोग करके कमांड निष्पादन स्क्रिप्ट को Web-सुलभ निर्देशिका में लिखने के लिए होता है। फिर हमलावर HTTP पैरामीटर के माध्यम से सिस्टम कमांड निष्पादन को ट्रिगर कर सकता है।

दो-चरणीय डिज़ाइन के लाभ हैं:

1. एकल SSRF अनुरोध में पेलोड जटिलता को कम करना।
2. XML, URL एन्कोडिंग, विशेष वर्ण एस्केपिंग के कारण पेलोड क्षति से बचना।
3. "सेवा तैनाती" और "अंतिम निष्पादन फ़ाइल लेखन" को अलग करना, जिससे डिबगिंग आसान हो जाती है।
4. विभिन्न लक्ष्य पथों पर लैंडिंग को समायोजित करना आसान हो जाता है।
5. बाद के कमांड निष्पादन चरण को SSRF चरण से अलग करना।

लेकिन सुरक्षा के दृष्टिकोण से, दो-चरणीय लेखन अधिक स्पष्ट जाँच सतह भी लाता है:

1. पहला असामान्य अनुरोध आमतौर पर नई सेवा बनाने या मध्यवर्ती JSP लिखने का प्रयास करेगा।
2. दूसरा असामान्य अनुरोध आमतौर पर मध्यवर्ती JSP तक पहुँचेगा और फ़ाइल नाम, फ़ाइल सामग्री जैसे पैरामीटर ले जाएगा।
3. तीसरा चरण अंतिम कमांड निष्पादन JSP तक पहुँचेगा और प्रमाणीकरण पासवर्ड या कमांड पैरामीटर ले जाएगा।
4. Web एक्सेस लॉग में थोड़े समय में लगातार WebDialer, services, axis2-web, platform-services जैसे पथों तक पहुँच दिखाई देगी।
5. फ़ाइल सिस्टम में असामान्य JSP, असामान्य सेवा नाम, असामान्य लॉग फ़ाइलें या नए Web संसाधन दिखाई दे सकते हैं।

8. वर्तमान PoC का पूर्ण निष्पादन प्रवाह

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

1. लक्ष्य पता पार्स करें।
2. WebDialer WSDL तक पहुँचें, वास्तविक होस्टनाम निकालने का प्रयास करें।
3. SSRF अनुरोध बनाएँ, लक्ष्य आंतरिक WebDialer / Axis प्रबंधन पथ।
4. आंतरिक अनुरोध के माध्यम से Axis सेवा संबंधित सामग्री लिखें।
5. services पृष्ठ तक पहुँचें, जाँचें कि असामान्य सेवा सफलतापूर्वक तैनात हुई या नहीं।
6. नई सेवा को कॉल करें, पहले चरण की फ़ाइल लेखन स्क्रिप्ट लिखें।
7. पहले चरण की स्क्रिप्ट तक पहुँचें, दूसरे चरण की कमांड निष्पादन स्क्रिप्ट लिखें।
8. दूसरे चरण की स्क्रिप्ट तक पहुँचें, परीक्षण कमांड निष्पादित करें।
9. HTTP प्रतिक्रिया, फ़ाइल लैंडिंग परिणाम और कमांड आउटपुट के आधार पर शोषण की सफलता का निर्धारण करें।

शोषण सफलता दर के संदर्भ में, सबसे महत्वपूर्ण विफलता बिंदु आमतौर पर निम्नलिखित पर केंद्रित होते हैं:

1. WebDialer सक्षम नहीं है।
2. होस्टनाम पार्सिंग विफल या फ़िल्टर हो गया।
3. SSRF अनुरोध वास्तव में आंतरिक सेवा में प्रवेश नहीं कर पाया।
4. Axis सेवा तैनाती विफल।
5. पथ ट्रैवर्सल लैंडिंग लक्ष्य संस्करण के अनुकूल नहीं है।
6. Web निर्देशिका लिखने योग्य नहीं है या स्क्रिप्ट निष्पादित नहीं की जाती है।
7. लक्ष्य पर पैच लगा हुआ है या Cisco का अस्थायी फिक्स पैक उपयोग किया गया है।
8. प्रॉक्सी, WAF, EDR या फ़ाइल अखंडता निगरानी ने मध्यवर्ती चरण को अवरुद्ध कर दिया।

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

9. सफलता निर्णय तर्क

CVE-2026-20230 की सफलता का निर्णय केवल स्क्रिप्ट के चलने के आधार पर नहीं किया जाना चाहिए। अधिक उचित निर्णय चार स्तरों में किया जाना चाहिए।

पहला स्तर: लक्ष्य संदिग्ध रूप से उजागर

शर्तें हैं:

WebDialer WSDL सुलभ है
या services पृष्ठ सुलभ है
या cmplatform संबंधित इंटरफ़ेस सुलभ है

यह केवल यह दर्शाता है कि लक्ष्य में संबंधित हमला सतह मौजूद है, यह साबित नहीं करता कि भेद्यता शोषण योग्य है।

दूसरा स्तर: भेद्यता संदिग्ध रूप से मौजूद

शर्तें हैं:

लक्ष्य संस्करण प्रभावित सीमा में है
WebDialer सक्षम है
होस्टनाम पार्स किया जा सकता है
SSRF प्रवेश बिंदु असामान्य लेकिन उचित सर्वर प्रतिक्रिया लौटाता है

इस स्थिति में, सर्वर-साइड लॉग या अधिकृत परीक्षण वातावरण के साथ सत्यापन जारी रखना चाहिए।

तीसरा स्तर: फ़ाइल लेखन पुष्टि

शर्तें हैं:

SSRF के बाद सर्वर-साइड पर नियंत्रित फ़ाइल दिखाई देती है
या Web निर्देशिका में सर्वर-साइड प्रक्रिया द्वारा बनाई गई असामान्य फ़ाइल दिखाई देती है
या services पृष्ठ पर असामान्य नई सेवा दिखाई देती है
या लॉग में नियंत्रित तैनाती विवरण सामग्री दिखाई देती है

इस स्तर पर, यह पुष्टि की जा सकती है कि भेद्यता श्रृंखला सामान्य SSRF चरण को पार कर मनमानी फ़ाइल लेखन जोखिम में प्रवेश कर गई है।

चौथा स्तर: RCE पुष्टि

शर्तें हैं:

लिखी गई Web-सुलभ स्क्रिप्ट सफलतापूर्वक पार्स और निष्पादित होती है
और अधिकृत परीक्षण कमांड के माध्यम से सर्वर-साइड निष्पादन परिणाम देखा जा सकता है

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

10. उपयोग उदाहरण

यह लेख सीधे आक्रमण के लिए उपयोग किए जा सकने वाले exploit निष्पादन उदाहरण प्रदान नहीं करता है।

अधिकृत वातावरण में, "केवल-पढ़ने की जाँच" या "गैर-विनाशकारी सत्यापन" विधियों का उपयोग करने की अनुशंसा की जाती है, उदाहरण के लिए:

python3 CVE-2026-20230-check.py https://127.0.0.1 --check

अनुशंसित जाँच मदों में शामिल हैं:

1. क्या लक्ष्य Cisco Unified CM / Unified CM SME है।
2. क्या WebDialer सेवा सक्षम है।
3. क्या WSDL सुलभ है।
4. क्या services पृष्ठ उजागर है।
5. क्या लक्ष्य संस्करण फिक्स संस्करण से नीचे है।
6. क्या कोई असामान्य नई JSP, असामान्य Axis सेवा या असामान्य लॉग लेखन के निशान मौजूद हैं।

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

11. PoC डिज़ाइन में सुरक्षा सीमाएँ

ऐसे PoC की सुरक्षा सीमाएँ स्पष्ट होनी चाहिए।

पहला, डिफ़ॉल्ट रूप से कमांड निष्पादित नहीं करना चाहिए। कमांड निष्पादन चरण एक उच्च जोखिम वाला सत्यापन है, जिससे सिस्टम स्थिति में परिवर्तन, लॉग प्रदूषण, सेवा असामान्यता या सुरक्षा उपकरणों की चेन प्रतिक्रिया हो सकती है।

दूसरा, डिफ़ॉल्ट रूप से WebShell नहीं लिखना चाहिए। भले ही परीक्षण फ़ाइल लिखी जा रही हो, इसे EDR, WebShell स्कैनिंग, फ़ाइल अखंडता निगरानी या अनुपालन ऑडिट सिस्टम द्वारा वास्तविक घुसपैठ व्यवहार के रूप में माना जा सकता है।

तीसरा, सार्वजनिक नेटवर्क लक्ष्यों का बैच स्कैन नहीं करना चाहिए। इस भेद्यता के लिए प्रमाणीकरण की आवश्यकता नहीं है, और लक्ष्य अधिकतर उद्यम संचार बुनियादी ढाँचा हैं, अनधिकृत स्कैन और शोषण का जोखिम बहुत अधिक है।

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

पाँचवाँ, लक्ष्य सीमा को प्रतिबंधित किया जाना चाहिए। PoC में स्थानीय पते, निजी नेटवर्क खंड, श्वेतसूची डोमेन नाम, प्राधिकरण पुष्टि पैरामीटर जैसे सुरक्षा तंत्र जोड़े जा सकते हैं, ताकि तीसरे पक्ष के सिस्टम पर गलत हमले से बचा जा सके।

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

12. सुरक्षा नियम लेखन के लिए प्रेरणा

ट्रैफ़िक जाँच के दृष्टिकोण से, केवल किसी एक फ़ाइल नाम, एक सेवा नाम या एक JSP नाम से मेल नहीं खाना चाहिए। सार्वजनिक PoC में सेवा नाम, फ़ाइल नाम और पथ को संशोधित किया जा सकता है, एकल स्ट्रिंग नियम आसानी से चूक सकते हैं।

अधिक उचित जाँच विचार हमला श्रृंखला चरणों के आसपास विशेषताएँ निकालना है।

पहली श्रेणी: जानकारी प्राप्ति चरण

ध्यान केंद्रित करें:

/webdialer/Version.jws?wsdl
/webdialer/services
WebDialer WSDL
Axis services listing

यदि थोड़े समय में बाह्य क्लाइंट WSDL तक पहुँचता है और फिर cmplatform स्थापना स्थिति इंटरफ़ेस तक पहुँचता है, तो जोखिम स्तर बढ़ाया जाना चाहिए।

दूसरी श्रेणी: SSRF ट्रिगर चरण

ध्यान केंद्रित करें:

/cmplatform/installClusterStatusExecute
action=clusterNodeInstallStatus
होस्टनाम पैरामीटर में असामान्य वृद्धि
होस्टनाम पैरामीटर में URL-एन्कोडेड पथ विभाजक दिखाई देना
होस्टनाम पैरामीटर में webdialer, services, AdminService, platformcom, installstages जैसी आंतरिक पथ विशेषताएँ शामिल होना

इस चरण की कुंजी यह है कि होस्टनाम पैरामीटर सामान्य होस्टनाम जैसा नहीं दिखता, बल्कि पथीकृत, URLीकृत, एन्कोडेड और XMLीकृत विशेषताएँ दिखाता है।

तीसरी श्रेणी: Axis / WSDD इंजेक्शन चरण

ध्यान केंद्रित करें:

deployment
wsdd
java:RPC
requestFlow
LogHandler
allowedMethods
className
fileName
writeToConsole

जब ये फ़ील्ड एक साथ दिखाई दें, तो अत्यधिक संदेह होना चाहिए कि हमलावर Axis सेवा तैनाती विवरण फ़ाइल के माध्यम से नियंत्रित सामग्री लिखने का प्रयास कर रहा है।

चौथी श्रेणी: फ़ाइल लेखन चरण

ध्यान केंद्रित करें:

axis2-web
platform-services
JSP फ़ाइल लेखन
पैरामीटर में फ़ाइल नाम और फ़ाइल सामग्री का संयोजन दिखाई देना
Web निर्देशिका पथ ट्रैवर्सल
common/log/taos-log-a
tomcat/webapps

यदि हमला ट्रैफ़िक में बहुत सारे ../, URL-एन्कोडेड पथ ट्रैवर्सल, JSP एक्सटेंशन और Tomcat WebApp पथ दिखाई दें, तो उच्च जोखिम माना जाना चाहिए।

पाँचवीं श्रेणी: कमांड निष्पादन चरण

ध्यान केंद्रित करें:

नई JSP तक पहुँच
अनुरोध पैरामीटर में pwd, cmd, command, exec, i जैसे कमांड पैरामीटर दिखाई देना
प्रतिक्रिया में सिस्टम कमांड आउटपुट प्रारूप दिखाई देना
एक ही स्रोत IP द्वारा थोड़े समय में WSDL प्राप्ति, SSRF, लेखन, निष्पादन के लगातार कार्य पूरे होना

नियम डिज़ाइन के दृष्टिकोण से, चरण-दर-चरण जाँच अपनाने की अनुशंसा की जाती है:

1. WebDialer जानकारी प्राप्ति: निम्न या मध्यम जोखिम अलर्ट।
2. cmplatform SSRF असामान्य होस्टनाम: उच्च जोखिम अलर्ट।
3. Axis/WSDD/LogHandler संयोजन विशेषताएँ: गंभीर अलर्ट।
4. JSP फ़ाइल लेखन या कमांड निष्पादन पैरामीटर: गंभीर अलर्ट।
5. बहु-चरण सहसंबंध हिट: सीधे घुसपैठ घटना में अपग्रेड करें।

13. जाँच और फोरेंसिक सुझाव

आपातकालीन जाँच के दौरान, निम्नलिखित स्थानों और घटनाओं की जाँच पर ध्यान केंद्रित करने की अनुशंसा की जाती है:

1. WebDialer एक्सेस लॉग में असामान्य WSDL और services गणना मौजूद है या नहीं।
2. cmplatform एक्सेस लॉग में installClusterStatusExecute असामान्य अनुरोध मौजूद है या नहीं।
3. होस्टनाम पैरामीटर में URL एन्कोडिंग, पथ ट्रैवर्सल, Axis, WSDD, LogHandler आदि सामग्री शामिल है या नहीं।
4. Web निर्देशिका में असामान्य JSP फ़ाइल दिखाई देती है या नहीं।
5. Axis services पृष्ठ या कॉन्फ़िगरेशन में असामान्य सेवा नाम दिखाई देता है या नहीं।
6. Tomcat लॉग, प्लेटफ़ॉर्म सेवा लॉग में असामान्य तैनाती विवरण, XML पार्सिंग त्रुटि या पथ लेखन रिकॉर्ड दिखाई देता है या नहीं।
7. /tmp, WebApp निर्देशिका, लॉग निर्देशिका में परीक्षण फ़ाइलें या अज्ञात फ़ाइलें दिखाई देती हैं या नहीं।
8. क्या थोड़े समय में एक ही स्रोत IP द्वारा बहु-चरण लगातार पहुँच मौजूद है।
9. क्या असामान्य सिस्टम कमांड निष्पादन के निशान, प्रक्रिया निर्माण रिकॉर्ड या शेल संबंधित व्यवहार दिखाई देते हैं।
10. क्या root अनुमति से संबंधित असामान्य फ़ाइलें, शेड्यूल किए गए कार्य, स्टार्टअप आइटम या स्थायित्व के निशान मौजूद हैं।

यदि शोषण का संदेह है, तो प्रबंधन पहुँच को पृथक करना, लॉग और फ़ाइल सिस्टम साक्ष्य को संरक्षित करना प्राथमिकता होनी चाहिए, और फिर पैच अपग्रेड, WebShell सफाई, असामान्य सेवा सफाई और खाता/क्रेडेंशियल रोटेशन करना चाहिए।

14. सुधार और शमन सुझाव

मूलभूत सुधार विधि Cisco के आधिकारिक फिक्स संस्करण में अपग्रेड करना या आधिकारिक अस्थायी फिक्स पैक लागू करना है।

सामान्य निपटान सुझाव इस प्रकार हैं:

1. तुरंत Unified CM / Unified CM SME संस्करण की पुष्टि करें।
2. जाँचें कि WebDialer सेवा सक्षम है या नहीं।
3. यदि व्यवसाय को WebDialer की आवश्यकता नहीं है, तो तुरंत इस सेवा को अक्षम करें।
4. Cisco के आधिकारिक फिक्स संस्करण में अपग्रेड करें।
5. Release 15 वातावरण में, यदि अस्थायी रूप से अपग्रेड संभव नहीं है, तो Cisco निर्देशों के अनुसार संबंधित COP फ़ाइल लागू करें।
6. प्रबंधन पहुँच और WebDialer से संबंधित सेवाओं के स्रोतों को प्रतिबंधित करें।
7. सीमा उपकरणों, WAF, IDS/IPS पर cmplatform, WebDialer, Axis/WSDD असामान्य अनुरोधों के लिए जाँच जोड़ें।
8. जाँचें कि क्या पहले से ही असामान्य JSP, असामान्य Axis सेवा या अज्ञात फ़ाइलें मौजूद हैं।
9. पहले से उजागर सिस्टम के लिए लॉग बैकट्रैक करें, विशेष रूप से 3 जून 2026 के बाद के एक्सेस रिकॉर्ड पर ध्यान दें।
10. यदि फ़ाइल लेखन या कमांड निष्पादन के साक्ष्य मिलते हैं, तो केवल पैच अपग्रेड न करें, बल्कि होस्ट-समझौता प्रक्रिया के अनुसार कार्रवाई करें।

15. सारांश

CVE-2026-20230 की कुंजी किसी एक इंटरफ़ेस के उजागर होने में नहीं है, बल्कि CUCM WebDialer, cmplatform स्थापना स्थिति क्वेरी तर्क, आंतरिक Axis सेवा प्रसंस्करण और फ़ाइल लेखन क्षमता के बीच एक श्रृंखला बनाने वाली विश्वास सीमा विफलता में है।

इस श्रृंखला को इस प्रकार संक्षेपित किया जा सकता है:

अप्रमाणित बाह्य अनुरोध
    ↓
WebDialer उजागर सतह पुष्टि
    ↓
वास्तविक होस्टनाम प्राप्ति
    ↓
cmplatform SSRF
    ↓
आंतरिक Axis सेवा पहुँच
    ↓
नियंत्रित सेवा विवरण या लॉग लेखन
    ↓
Web-सुलभ फ़ाइल अवतरण
    ↓
कमांड निष्पादन और root अनुमति वृद्धि जोखिम

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

रक्षा के दृष्टिकोण से, केवल "किसी JSP फ़ाइल के अस्तित्व" पर निर्भर रहकर हमले का निर्णय नहीं करना चाहिए। अधिक सुरक्षित तरीका बहु-चरण श्रृंखला के आसपास सहसंबंध जाँच करना है: WSDL जानकारी प्राप्ति, cmplatform असामान्य होस्टनाम, Axis/WSDD विशेषताएँ, पथ ट्रैवर्सल लेखन, JSP लैंडिंग पहुँच और कमांड पैरामीटर पहुँच। जब तक इनमें से कई चरण थोड़े समय में एक ही स्रोत से लगातार दिखाई देते हैं, इसे उच्च जोखिम वाली घुसपैठ घटना के रूप में माना जाना चाहिए।

References

• Cisco Security Advisory: Cisco Unified Communications Manager Server-Side Request Forgery Vulnerability
• NVD: CVE-2026-20230
• SSD Secure Disclosure: Cisco Unified Communications Manager Arbitrary File Write to RCE
• Cisco Unified CM / Unified CM SME आधिकारिक अपग्रेड और COP फिक्स निर्देश