पूर्ण रूप से हथियारबद्ध CVE-2021-40444

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

अपडेट 31/05/2022 - CVE-2022-30190 - Follina

अब जनरेटर "Follina" हमले (ms-msdt का लाभ उठाते हुए) का शोषण करने के लिए आवश्यक दस्तावेज़ भी उत्पन्न कर सकता है।

पृष्ठभूमि

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

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

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

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

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

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

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

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

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

HTML फ़ाइल

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

CAB फ़ाइल

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

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

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

DLL हमला

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

JScript, VBScript, Javaw, MSIexec, ...

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

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

Microsoft दस्तावेज़ीकरण के अनुसार, codebase टैग केवल कुछ फ़ाइल प्रकारों की ओर इशारा कर सकता है: OCX, INF और CAB।

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

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

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

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

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

कृपया ध्यान दें कि इस तकनीक का उपयोग करते समय, हमला श्रृंखला थोड़ी अलग है। इस हमले के लिए उपयोगकर्ता को एक विशेष रूप से तैयार की गई 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 कौन से हैं