afang5472/cve-2020-0753-and-cve-2020-0754CVE-2020-0753, CVE-2020-0754 और छः सुधारित Window DOS Vulnerabilities के लिए लेख और POC.
विंडोज एरर रिपोर्टिंग सेवा ने पिछले पैच मंगलवार में विशेषाधिकार उन्नयन (Elevation of Privilege) के 2 बग ठीक किए हैं, दोनों बगों को CVE-2020-0753 और CVE-2020-0754 निर्दिष्ट किया गया है। दोनों बग सेवा के फ़ाइलसिस्टम संचालन में रेस कंडीशन बग का लाभ उठाते हैं। हालांकि, छोटे रेस विंडो और अनिश्चित फ़ाइल ड्रॉप स्थानों के कारण इन दोनों बगों का शोषण करना इतना आसान नहीं है। यहां हम उनका शोषण करने की अपनी तकनीक साझा करते हैं।
दो रेस बगों का मूल कारण हमारी रिपोर्ट में दिया गया है, वास्तविक कारण को अनुमानित कमजोर है (Predictable is Vulnerable) के रूप में व्यक्त किया जा सकता है। जब WER सेवा अस्थायी फ़ाइलों को संसाधित करती है, तो यह फ़ाइल स्थान C:\ProgramData\Microsoft\Windows\WER\Temp में हेरफेर करती है, जो प्रमाणित उपयोगकर्ताओं के लिए R/W सक्षम निर्देशिका है। इसका मतलब है कि एक मध्यम-IL सामान्य उपयोगकर्ता WER सेवा द्वारा बनाई गई फ़ाइल को अधिलेखित कर सकता है, और इसे फ़ाइलसिस्टम लिंक में भी बदल सकता है ताकि अन्य फ़ाइलों को नुकसान/हटा सके जिन्हें वे छूने में असमर्थ थे।
फ़ाइल संचालन को सुरक्षित रखने के लिए, WER सेवा GetTempFileNameW नामक एक मानक api पर निर्भर करती है और इसे 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 बनाते हैंविस्तृत शोषण और poc WERReport-CVE-2020-0753 में प्रदान किए गए हैं।
GetTempFileNameW में दोष का शोषण करके, हम एक अनुमानित स्थान प्राप्त करते हैं जहां सेवा काम करेगी; बहु-स्तरीय फ़ाइलसिस्टम जंक्शन का उपयोग करके, हम रेस कंडीशन को विश्वसनीय रूप से शोषण योग्य बनाते हैं।
इस बीच, हमने देखा कि इस प्रकार का रेस बग संभावित फ़ाइल अधिलेखन समस्या भी पैदा कर सकता है, तो यह कुछ परिस्थितियों में विशेषाधिकार उन्नयन बग की ओर ले जाने की संभावना है।
यह समझाने के लिए कि मनमानी फ़ाइल भ्रष्टाचार (यदि आप फ़ाइल सामग्री के एक बहुत छोटे हिस्से को नियंत्रित कर सकते हैं: 63 बाइट्स से कम) को EoP में कैसे बदला जा सकता है, हमें विंडोज डिफेंडर के कार्य तंत्र पर ध्यान देने की आवश्यकता है।
विंडोज डिफेंडर के पास मैलवेयर हस्ताक्षर डेटाबेस है। यदि किसी फ़ाइल में कुछ मैलवेयर हस्ताक्षर हैं, तो डिफेंडर इसे मैलवेयर मानेगा और उन्हें हटा देगा। हालांकि, यह सुविधा अतिरिक्त हमले की सतह का परिणाम देगी। उदाहरण के लिए, WCTF2019 में टोक्योवेस्टर्न्स के @icchy ने "Gyotaku The Flag" नामक एक विंडोज सीटीएफ चुनौती डिजाइन की, जो इस सुविधा का उपयोग जानकारी लीक करने के लिए एक oracle के रूप में करती है।
यहां हम विंडोज डिफेंडर की इस सुविधा का लाभ उठाते हैं ताकि मनमानी फ़ाइल को हटाया जा सके यदि हमारे पास फ़ाइल सामग्री के आंशिक नियंत्रण के साथ मनमानी फ़ाइल भ्रष्टाचार है। हम बस एक फ़ाइल में मैलवेयर हस्ताक्षर लिख सकते हैं और विंडोज डिफेंडर द्वारा डिफ़ॉल्ट स्कैन को ट्रिगर कर सकते हैं, फ़ाइल डिफेंडर के अलगाव क्षेत्र में डाल दी जाएगी, जिसे एक सामान्य उपयोगकर्ता (अर्थात एक मध्यम-IL गैर-व्यवस्थापक उपयोगकर्ता) केवल स्कैन ऑपरेशन को 2 बार ट्रिगर करके हटा सकता है।
इसलिए एक मनमानी फ़ाइल भ्रष्टाचार बग को मनमानी फ़ाइल हटाने में बदला जा सकता है जब तक कि बग का उपयोग करके लक्ष्य फ़ाइल में मैलवेयर हस्ताक्षर स्ट्रिंग डाली जा सके।
चरण1: बग के साथ लक्ष्य फ़ाइल को भ्रष्ट करें, इसमें विंडोज डिफेंडर द्वारा पहचाने जाने योग्य एक फीचर स्ट्रिंग डालें।
चरण2: लक्ष्य फ़ाइल को स्कैन करने के लिए विंडोज डिफेंडर को ट्रिगर करें, जिससे फ़ाइल अलग हो जाए।
चरण3: फिर से स्कैन ट्रिगर करें, लक्ष्य फ़ाइल हटा दी गई।
तकनीक का लाभ उठाकर हम डिफेंडर की मदद से मनमानी फ़ाइल हटाने की क्षमता प्राप्त करते हैं।
मनमानी फ़ाइल हटाने का शोषण आगे विशेषाधिकार प्राप्त करने के लिए बहुत आसानी से किया जा सकता है।
Microsoft OneDrive एक एप्लिकेशन बंडल है जो व्यक्तिगत क्लाउड स्टोरेज सेवा प्रदान करता है, यह एप्लिकेशन विंडोज 8 से विंडोज में डिफ़ॉल्ट इंस्टॉलेशन विकल्प के रूप में एकीकृत किया गया है। हमारे शोध के दौरान, OneDrive की सर्विसिंग शेड्यूल किए गए कार्यों में 6 भेद्यताएं पाई गईं और MSRC को प्रस्तुत की गईं।
यहां Microsoft OneDrive संबंधित शेड्यूल किए गए कार्यों में उजागर होने वाली भेद्यताओं की एक तालिका है:
| भेद्य कार्यक्रम | प्रकार | POC प्रदान किया गया |
|---|---|---|
| FileSyncConfig.exe | HardLink | हाँ |
| FileSyncHelper.exe | HardLink | हाँ |
| OneDriveFileSyncConfig.exe | SymLink | हाँ |
| OneDriveSetup.exe | HardLink | हाँ |
| OneDriveSetup.exe | HardLink | हाँ |
| OneDriveStandaloneUpdater.exe | HardLink | हाँ |
सभी 6 बग सेवा द्वारा हार्डलिंक और सिमलिंक को अनुचित रूप से संभालने के कारण होते हैं, जबकि ऐसे स्थानों पर काम करते हैं जो सामान्य उपयोगकर्ता के नियंत्रण में हैं। इन बगों के शोषण के दौरान, एक कठिनाई यह आती है कि फ़ाइल नाम में आमतौर पर वर्तमान प्रक्रिया का pid या एक टाइमस्टैम्प होता है जो यह चिह्नित करता है कि फ़ाइल कब संचालित की गई थी। दोनों को एक अद्वितीय dll फ़ाइल पर oplock सेट करके हल किया जा सकता है जिसे सेवा चलने पर लोड करने का प्रयास करेगी, जहां हमारे पास वह सब कुछ प्राप्त करने की क्षमता है जो बाद में सेवा द्वारा संचालित किए जाने वाले फ़ाइल नाम की भविष्यवाणी करने के लिए आवश्यक है। FileSyncConfigTemp_hardlink निर्देशिका में एक उदाहरण POC प्रदान किया गया है।