vikasvarshney/cve-2020-0753-and-cve-2020-0754CVE-2020-0753, CVE-2020-0754 और छह अनफिक्स्ड विंडोज DOS कमजोरियों के लिए लेख और POC।
विंडोज एरर रिपोर्टिंग सेवा ने पिछले पैच ट्यूजडे में 2 एलिवेशन ऑफ प्रिविलेज बग्स को ठीक किया है, इन दोनों बग्स को CVE-2020-0753 और CVE-2020-0754 सौंपा गया है। दोनों बग्स सेवा के फाइलसिस्टम संचालन में एक रेस कंडीशन बग का लाभ उठाते हैं। हालांकि, छोटी रेस विंडो और अनिश्चित फ़ाइल ड्रॉप स्थानों के कारण इन दोनों बगों का शोषण करना इतना आसान नहीं है। यहाँ हम उनका शोषण करने की अपनी तकनीक साझा करते हैं।
दो रेस बगों का मूल कारण हमारी रिपोर्टों में दिया गया है, वास्तविक कारण को पूर्वानुमानित असुरक्षित है के रूप में व्यक्त किया जा सकता है। जब WER सेवा अस्थायी फ़ाइलों को संसाधित करती है, तो यह फ़ाइल स्थान C:\ProgramData\Microsoft\Windows\WER\Temp में हेरफेर करती है, जो प्रमाणित उपयोगकर्ताओं के लिए R/W सक्षम निर्देशिका है। इसका मतलब है कि एक मीडियम-IL सामान्य उपयोगकर्ता WER सेवा द्वारा बनाई गई फ़ाइल को ओवरराइट कर सकता है, और यहां तक कि इसे फाइलसिस्टम लिंक में बदल सकता है ताकि उन अन्य फ़ाइलों को नुकसान/हटा सके जिन्हें वे छूने में असमर्थ थे।
फ़ाइल संचालन को सुरक्षित रखने के लिए, WER सेवा एक मानक api GetTempFileNameW पर निर्भर करती है और इसे wersvc.dll->UtilGetTempFile के साथ लपेटती है, यह api WerSvc को "WER****.tmp" के रूप में अप्रयुक्त यादृच्छिक फ़ाइल नाम उत्पन्न करने में मदद करेगा,
फ़ाइल नाम का यादृच्छिक भाग एक 4-बाइट हेक्स संख्या के साथ उत्पन्न होता है, 0000-FFFF से, यदि कोई संख्या फ़ाइल बनाने के लिए ली गई है, तो api एक और यादृच्छिक फ़ाइल नाम लेगा।
रणनीति में स्पष्ट रूप से एक दोष है यदि कोई WER0000.tmp से
WERFFFE.tmp तक नामकरण करते हुए 65535 फ़ाइलें बनाता है, तो api एक यादृच्छिक संख्या चुनेगा और फ़ाइल नाम का परीक्षण करेगा कि क्या यह मौजूद है, जैसे WERA560.tmp, यह पाएगा कि फ़ाइल पहले से मौजूद है, इस प्रकार यह WERA560.tmp से WERFFFF.tmp तक परीक्षण जारी रखेगा, परीक्षण जारी रहने के दौरान, एक तैयारी विंडो दिखाई देती है क्योंकि हमें WerSvc को GetTempFileNameW कॉल पर 4-5 सेकंड के लिए अटका हुआ बनाने का एक तरीका मिल गया है, जो काफी बड़ा समय अंतराल है। इस बीच, हम सेवा को एक निश्चित फ़ाइल नाम के साथ एक अस्थायी फ़ाइल छोड़ने के लिए मजबूर करते हैं, वह है
WERFFFF.tmp।
सेवा द्वारा WERFFFF.tmp नामक अस्थायी फ़ाइल बनाने के बाद, api स्वचालित रूप से फ़ाइल पर अपने हैंडल को बंद कर देता है, और फ़ाइल पर आगे के संचालन के लिए फ़ाइल का नाम सेवा को लौटा देता है, यह वही स्थान है जो बग का परिचय देता है। तीन शर्तें पूरी होती हैं:
सेवा द्वारा बनाई गई फ़ाइल सामान्य उपयोगकर्ता नियंत्रणीय स्थान पर है।
सेवा फ़ाइल के सभी हैंडल बंद कर देती है
सेवा बाद में फ़ाइल का उपयोग करेगी (लिखना या हटाना)
यहाँ सेवा फ़ाइल में सामग्री लिखेगी और उसे हटा देगी। लिखना और हटाना दोनों ही फाइलसिस्टम लिंक और कुछ शोषण तकनीकों का लाभ उठाकर विशेषाधिकार वृद्धि का कारण बनेंगे।
बग को मनमानी फ़ाइल हटाने में बदलने के लिए, हम रचनात्मक रूप से शोषण को पूरा करने के लिए मल्टीपल डायरेक्टरी जंक्शन का लाभ उठाते हैं। हमारा शोषण निम्नलिखित चरण शामिल करता है:
WER***.tmp को $pwd\1\ में रखते हैं, और जंक्शन $pwd\2\ -> $pwd\1\;$pwd\2\ के साथ इस फ़ंक्शन को लगातार ट्रिगर करती है। और दूसरी प्रक्रिया बनाते हैं जो कमांड SetOplock $pwd\1\WERFFFF.tmp को लगातार निष्पादित करती है;$pwd\2\ -> \RPC CONTROL\ जंक्शन करते हैं, और फिर ऑब्जेक्ट सिंबॉलिक \RPC CONTROL\WERFFFF.tmp -> $target और \RPC CONTROL\WERFFFF.tmp.etl -> $target बनाते हैंविस्तृत शोषण और पीओसी WERReport-CVE-2020-0753 में प्रदान किए गए हैं।
GetTempFileNameW में दोष का शोषण करके, हम एक पूर्वानुमानित स्थान प्राप्त करते हैं जहाँ सेवा संचालित होगी; मल्टीपल लेवल फाइलसिस्टम जंक्शन का उपयोग करके, हम रेस कंडीशन को विश्वसनीय रूप से शोषणीय बनाते हैं।
इस बीच, हमने देखा कि इस प्रकार का रेस बग संभावित फ़ाइल ओवरराइटिंग समस्या भी पैदा कर सकता है, तो यह कुछ परिस्थितियों में विशेषाधिकार वृद्धि बग की ओर ले जाने की संभावना है।
यह समझाने के लिए कि मनमानी फ़ाइल भ्रष्टाचार (यदि आप फ़ाइल सामग्री के एक बहुत छोटे हिस्से को नियंत्रित कर सकते हैं: 63 बाइट्स से कम) को EoP में कैसे बदला जा सकता है, हमें विंडोज डिफेंडर के काम करने के तंत्र पर ध्यान देने की आवश्यकता है।
विंडोज डिफेंडर के पास मैलवेयर सिग्नेचर डेटाबेस है। यदि किसी फ़ाइल में कुछ मैलवेयर सिग्नेचर हैं, तो डिफेंडर इसे मैलवेयर मानेगा और उसे हटा देगा। हालांकि, यह सुविधा अतिरिक्त हमले की सतह का परिणाम देगी। उदाहरण के लिए, WCTF2019 में @icchy (tokyowesterns से) ने एक विंडोज CTF चैलेंज डिज़ाइन किया जिसका नाम "Gyotaku The Flag" है, जो इस सुविधा का उपयोग जानकारी लीक करने के लिए एक ऑरैकल के रूप में करता है।
यहाँ हम मनमानी फ़ाइल को हटाने के लिए विंडोज डिफेंडर की इस सुविधा का लाभ उठाते हैं यदि हमारे पास फ़ाइल सामग्री के आंशिक नियंत्रण के साथ मनमानी फ़ाइल भ्रष्टाचार है। हम बस एक फ़ाइल में एक मैलवेयर सिग्नेचर लिख सकते हैं और विंडोज डिफेंडर द्वारा डिफ़ॉल्ट स्कैन को ट्रिगर कर सकते हैं, फ़ाइल को डिफेंडर के अलगाव क्षेत्र में रखा जाएगा, जिसे एक सामान्य उपयोगकर्ता (यानी एक मीडियम-IL गैर-व्यवस्थापक उपयोगकर्ता) केवल स्कैन ऑपरेशन को 2 बार ट्रिगर करके हटा सकता है।
इसलिए एक मनमानी फ़ाइल भ्रष्टाचार बग को मनमानी फ़ाइल हटाने में बदला जा सकता है जब तक कि बग का उपयोग करके लक्ष्य फ़ाइल में एक मैलवेयर सिग्नेचर स्ट्रिंग डाली जा सके।
बग के साथ लक्ष्य फ़ाइल को दूषित करें, इसमें विंडोज डिफेंडर द्वारा पहचाने जाने योग्य एक फीचर स्ट्रिंग डालें।
लक्ष्य फ़ाइल को स्कैन करने के लिए विंडोज डिफेंडर को ट्रिगर करें, जिससे फ़ाइल अलग हो जाए।
फिर से स्कैन ट्रिगर करें, लक्ष्य फ़ाइल हटा दी जाए।
इस तकनीक का लाभ उठाकर हम डिफेंडर की मदद से मनमानी फ़ाइल हटाने प्राप्त करते हैं।
मनमानी फ़ाइल हटाने का शोषण आगे विशेषाधिकार प्राप्त करने के लिए बहुत आसानी से किया जा सकता है।
माइक्रोसॉफ्ट वनड्राइव एप्लिकेशन बंडल है जो पर्सनल क्लाउड स्टोरेज सेवा प्रदान करता है,
यह एप्लिकेशन विंडोज 8 के बाद से डिफ़ॉल्ट इंस्टॉलेशन विकल्प के रूप में विंडोज में एकीकृत किया गया है। हमारे शोध के दौरान, वनड्राइव की सर्विसिंग शेड्यूल्ड टास्क में 6 कमजोरियां पाई गईं और MSRC को प्रस्तुत की गईं।
यहाँ उन कमजोरियों की एक तालिका है जिन्हें हम माइक्रोसॉफ्ट वनड्राइव से संबंधित शेड्यूल्ड टास्क में उजागर करने वाले हैं:
| असुरक्षित प्रोग्राम | प्रकार | POC प्रदान किया गया |
|---|---|---|
| FileSyncConfig.exe | HardLink | हाँ |
| FileSyncHelper.exe | HardLink | हाँ |
| OneDriveFileSyncConfig.exe | SymLink | हाँ |
| OneDriveSetup.exe | HardLink | हाँ |
| OneDriveSetup.exe | HardLink | हाँ |
| OneDriveStandaloneUpdater.exe | HardLink | हाँ |
सभी 6 बग इस कारण होते हैं कि सेवा सामान्य उपयोगकर्ता द्वारा नियंत्रणीय स्थानों पर काम करते समय हार्डलिंक्स और सिमलिंक्स को अनुचित तरीके से संभालती है। इन बगों के शोषण के दौरान, एक कठिनाई इस बात से आती है कि फ़ाइल नाम में आमतौर पर वर्तमान प्रक्रिया का pid या एक टाइमस्टैम्प होता है जो फ़ाइल के संचालित होने के समय को चिह्नित करता है। दोनों को एक अद्वितीय dll फ़ाइल पर एक oplock सेट करके हल किया जा सकता है जिसे सेवा चलने पर लोड करने का प्रयास करेगी, जहाँ हमारे पास वह सब कुछ प्राप्त करने की क्षमता है जिसकी हमें बाद में सेवा द्वारा संचालित किए जाने वाले फ़ाइल नाम की भविष्यवाणी करने के लिए आवश्यकता है। एक उदाहरण POC FileSyncConfigTemp_hardlink निर्देशिका में प्रदान किया गया है।