पूरी तरह से हथियारबंद CVE-2021-40444

CVE-2021-40444 (माइक्रोसॉफ्ट ऑफिस वर्ड रिमोट कोड एक्जीक्यूशन) का शोषण करने के लिए दुर्भावनापूर्ण docx जनरेटर, मनमाने DLL फ़ाइलों के साथ काम करता है।

पृष्ठभूमि

हालाँकि इंटरनेट पर पहले से ही कई PoC मौजूद हैं, मैंने सोचा कि इस कमजोरी को हथियार बनाने का एक प्रयास करूँ, क्योंकि मुझे जो उपलब्ध मिला उसमें साझा करने योग्य मूल्यवान जानकारी का अभाव था, और यह भी ध्यान में रखते हुए कि माइक्रोसॉफ्ट ने पहले ही इस कमजोरी के लिए एक पैच जारी कर दिया है।

अब तक, पूरी तरह से काम करने वाला जनरेटर बनाने के लिए मैंने जो एकमात्र मूल्यवान संसाधन देखे हैं वे हैं:

• Ret2Pwn द्वारा ब्लॉग
• j00sean द्वारा ट्वीट

उपरोक्त संसाधन एक पूरी श्रृंखला बनाने के लिए आवश्यक कई आवश्यकताओं की रूपरेखा प्रस्तुत करते हैं। बहुत अधिक अनावश्यक जानकारी दोहराने से बचने के लिए, मैं केवल प्रासंगिक विवरणों का सारांश प्रस्तुत करूँगा।

शोषण श्रृंखला

1. Docx खोला गया
2. document.xml.rels में संग्रहीत रिलेशनशिप दुर्भावनापूर्ण html की ओर इशारा करता है
3. HTML लिंक खोलने के लिए IE पूर्वावलोकन लॉन्च किया गया
4. HTML के अंदर JScript में एक ऑब्जेक्ट होता है जो CAB फ़ाइल की ओर इशारा करता है, और एक iframe जो ".cpl:" निर्देश से उपसर्गित INF फ़ाइल की ओर इशारा करता है
5. कैब फ़ाइल खोली जाती है, INF फ़ाइल %TEMP%\Low निर्देशिका में संग्रहीत होती है
6. CAB में पथ ट्रैवर्सल (ZipSlip) कमजोरी के कारण, INF को %TEMP% में संग्रहीत करना संभव है
7. फिर, INF फ़ाइल को ".cpl:" निर्देश के साथ खोला जाता है, जिससे rundll32 के माध्यम से INF फ़ाइल का साइड-लोडिंग होता है (यदि यह DLL है)

अनदेखी आवश्यकताएँ

इस शोषण के काम करने के लिए काफी कुछ अनदेखी आवश्यकताएँ हैं, जिसके कारण lockedbyte द्वारा बनाए गए अच्छे PoC जैसे भी ठीक से काम करने में विफल रहे।

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

HTML फ़ाइल

जैसा कि Will Dormann के इस ट्वीट में कहा गया है, MS Word के अंदर "पूर्वावलोकन" ट्रिगर करने के लिए HTML का आकार कम से कम 4096 बाइट्स होना चाहिए।

CAB फ़ाइल

CAB फ़ाइल को निष्कर्षण त्रुटियों से बचने और ZipSlip प्राप्त करने के लिए बाइट-पैच किया जाना चाहिए:

• filename.inf को ../filename.inf बनना चाहिए
• filename.inf बिल्कुल <12-char>.inf होना चाहिए वास्तव में सच नहीं है, महत्वपूर्ण बात coffCabStart को संशोधित करना है
• CFFOLDER.typeCompress 0 होना चाहिए (संपीड़ित नहीं)
• CFFOLDER.coffCabStart को 3 बढ़ाया जाना चाहिए (जोड़े गए '../' के कारण)
• CFFOLDER.cCfData 2 होना चाहिए
• CFFILE.cbFile पूरे CFHEADER.cbCabinet से अधिक होना चाहिए
• CFDATA.csum पुनर्गणना की जानी चाहिए (या शून्य किया जाना चाहिए) [वैकल्पिक]

इन बाधाओं के कई कारण हैं, और मैंने उन सभी को गहराई से समझने में पर्याप्त समय नहीं बिताया, लेकिन आइए सबसे महत्वपूर्ण देखें:

• TypeCompress: यदि CAB संपीड़ित है, तो इसे ऑब्जेक्ट फ़ाइल के अंदर खोलने की चाल INF लेखन को ट्रिगर करने में विफल हो जाएगी गलत, मैं MSZIP संपीड़ित नमूने के साथ समान परिणाम प्राप्त करने में सफल रहा
• CoffCabStart: CoffCabStart पहली CFDATA संरचना की निरपेक्ष स्थिति देता है, चूंकि हमने '../' जोड़ा है, हमें फ़ाइल की ओर इशारा करने के लिए इसे 3 बढ़ाने की आवश्यकता होगी (यह एक अनुमान जैसा है)
• cCfData: चूंकि केवल 1 फ़ाइल है, हमारे पास केवल 1 CFDATA होना चाहिए, मुझे यकीन नहीं है कि इसे 2 क्यों सेट करना पड़ता है वास्तव में, हम इसे 1 के रूप में छोड़ सकते हैं
• cbFile: दिलचस्प बात यह है कि यदि CAB निष्कर्षण बिना किसी त्रुटि के समाप्त होता है, तो INF फ़ाइल WORD द्वारा हटाने के लिए चिह्नित की जाएगी, जिससे शोषण बर्बाद हो जाएगा। इसे रोकने का एकमात्र तरीका WORD को यह विश्वास दिलाना है कि निष्कर्षण विफल हो गया। यदि cbFile मान कैबिनेट फ़ाइल से बड़ा परिभाषित किया गया है, तो एक्सट्रैक्टर cbFile में परिभाषित सभी बाइट्स पढ़ने से पहले EOF तक पहुंच जाएगा, जिससे निष्कर्षण त्रुटि उत्पन्न होगी।
• [वैकल्पिक] यह मान MS Word द्वारा जांचा नहीं जाता है। वैसे भी, सही CAB के लिए, csum मान की पुनर्गणना की जानी चाहिए। सौभाग्य से, जैसा कि j00sean ने नोट किया है और MS दस्तावेज़ीकरण के अनुसार, यह मान 0 हो सकता है

नोट1: डिफेंडर अब _IMAGE_DOS_HEADER.e_magic मान को एक हस्ताक्षर के रूप में उपयोग करके यह पता लगाता है कि CAB फ़ाइल में PE है या नहीं, संभावित रूप से PE फ़ाइलों को CAB में एम्बेड होने से रोकता है। क्या इस हस्ताक्षर को बायपास किया जा सकता है? मुझे यकीन नहीं है, लेकिन जैसा कि पहले देखा गया, यह एक पैच की गई कमजोरी है, इसलिए मैं इस पर और अधिक समय बिताने की योजना नहीं बना रहा हूँ। जिज्ञासु पाठक इसे आगे विकसित कर सकता है।

नोट2: माइक्रोसॉफ्ट पैच मनमाने URI स्कीम को ब्लॉक करता है, जाहिरा तौर पर एक ब्लैकलिस्ट दृष्टिकोण का उपयोग करके (यह सिर्फ एक अनुमान है)

DLL हमला

CVE-2021-40444 से जुड़ी मुख्य हमला श्रृंखला .cpl URI स्कीम के माध्यम से लोड किया गया DLL हमला है। इसका शोषण करने के लिए, एक हमलावर को एक विशेष रूप से तैयार किया गया DLL उत्पन्न करने की आवश्यकता होती है। यदि आप इसका परीक्षण करना चाहते हैं, तो मेरा evildll-gen स्क्रिप्ट आज़माएँ।

जेस्क्रिप्ट, वीबीस्क्रिप्ट, जावा, MSIexec, ...

जैसा कि Max Maluin ने नोट किया है, IE और संबंधित फ़ाइल एक्सटेंशन आधारित URI का दुरुपयोग करके कई फ़ाइल प्रकारों के साथ बातचीत करना संभव है। हालांकि यह IE का शोषण करने का एक अच्छा तरीका हो सकता है, लेकिन इसकी सीमाएँ हैं।

वास्तव में, यह ध्यान दिया जाना चाहिए कि शोषण में फ़ाइलों को डाउनलोड करने के लिए उपयोग की जाने वाली विधि ActiveX नियंत्रण अपडेट पर आधारित है, और इसका उपयोग मनमानी फ़ाइलों को डाउनलोड करने के लिए नहीं किया जा सकता है। माइक्रोसॉफ्ट दस्तावेज़ीकरण के अनुसार, codebase टैग केवल कुछ फ़ाइल प्रकारों की ओर इशारा कर सकता है: OCX, INF और CAB।

भले ही हम सीधे OCX या INF फ़ाइल डाउनलोड कर सकते हैं, फिर भी हम सिस्टम के भीतर सही स्थान पर फ़ाइल डाउनलोड करने के बारे में सुनिश्चित नहीं हो सकते। कैब शोषण के साथ, पथ ट्रैवर्सल का उपयोग करके .inf फ़ाइल को एक ज्ञात पथ पर ले जाना संभव है, लेकिन किसी भी अन्य मामले में फ़ाइल एक यादृच्छिक निर्देशिका में संग्रहीत की जाएगी, जिससे इसे संदर्भित करना लगभग असंभव हो जाता है।

आज तक, मुझे CAB फ़ाइल के बिना डाउनलोड और निष्पादन को श्रृंखलित करने का कोई तरीका नहीं मिला।

नोट: केवल IE की बात करें तो, कमजोरी का शोषण करने के लिए HTML स्मगलिंग एक संभावित परिदृश्य हो सकता है।

हाइब्रिड RAR फ़ाइल का उपयोग करके CAB-रहित फ़ाइल हमला

यह तकनीक सबसे पहले Eduardo Braun द्वारा ट्विटर पर प्रकट की गई थी और इस पेपर में आगे समझाया गया है।

कृपया ध्यान दें कि इस तकनीक का उपयोग करने पर, हमला श्रृंखला थोड़ी अलग है। इस हमले के लिए उपयोगकर्ता को एक विशेष रूप से तैयार की गई RAR फ़ाइल डाउनलोड करनी होती है, जो एक मान्य WSF स्क्रिप्ट और एक मान्य RAR फ़ाइल को श्रृंखलित करके प्राप्त की जाती है। एक बार खोलने पर, RAR में एक DOCX होगा जिसमें एक HTML का संदर्भ होगा, जो बदले में RAR फ़ाइल को WSF स्क्रिप्ट के रूप में लोड करने का प्रयास करेगा।

संक्षेप में:

1. विशेष रूप से तैयार की गई RAR फ़ाइल डाउनलोड की जाती है (संभवतः डाउनलोड फ़ोल्डर में)
2. DOCX निकाला और खोला गया
3. document.xml.rels में संग्रहीत रिलेशनशिप दुर्भावनापूर्ण html की ओर इशारा करता है
4. HTML लिंक खोलने के लिए IE पूर्वावलोकन लॉन्च किया गया
5. HTML के अंदर JScript में एक स्क्रिप्ट/iframe होता है जो ".wsf:" URI स्कीम से उपसर्गित RAR फ़ाइल की ओर इशारा करता है
6. चूंकि RAR को एक साथ एक मान्य RAR और एक मान्य WSF स्क्रिप्ट होने के लिए डिज़ाइन किया गया था, स्क्रिप्ट निष्पादित की जाती है

टूल द्वारा कार्यान्वित शोषण PoC क्या हैं

जनरेटर उपयोगिता वर्तमान में निम्नलिखित हमलों को पुन: उत्पन्न कर सकती है: