CVE-2020-0753-and-CVE-2020-0754

CVE-2020-0753, CVE-2020-0754 और छह स्थिर विंडो DOS भेद्यताओं के लिए राइटअप और POC

फ़ाइलसिस्टम रेस कंडीशन बग का शोषण - CVE-2020-0753 और CVE-2020-0754 का विश्लेषण

विंडोज एरर रिपोर्टिंग सेवा ने पिछले पैच मंगलवार में विशेषाधिकार उन्नयन (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 स्वचालित रूप से फ़ाइल पर रखे गए हैंडल को बंद कर देती है, और फ़ाइल पर आगे के संचालन के लिए फ़ाइल नाम सेवा को लौटा देती है, यही वह स्थिति है जो बग का परिचय देती है। तीन शर्तें पूरी होती हैं:

1. सेवा द्वारा बनाई गई फ़ाइल सामान्य उपयोगकर्ता के नियंत्रण योग्य स्थान पर है।

2. सेवा फ़ाइल के सभी हैंडल बंद कर देती है

3. सेवा बाद में फ़ाइल का उपयोग करेगी (लिखना या हटाना)

यहां सेवा फ़ाइल में सामग्री लिखेगी और उसे हटा देगी। लिखना और हटाना दोनों ही फ़ाइलसिस्टम लिंक और कुछ शोषण तकनीकों का लाभ उठाकर विशेषाधिकार उन्नयन का कारण बनेंगे।

बग को मनमानी फ़ाइल हटाने में बदलने के लिए, हम रचनात्मक रूप से कई निर्देशिका जंक्शनों का लाभ उठाते हैं। हमारे शोषण में निम्नलिखित चरण शामिल हैं:

• हम सभी WER***.tmp को $pwd\1\ में रखते हैं, और जंक्शन $pwd\2\ -> $pwd\1\;
• हम इस फ़ंक्शन को लगातार पथ $pwd\2\ के साथ ट्रिगर करने के लिए एक प्रक्रिया बनाते हैं, और कमांड SetOplock $pwd\1\WERFFFF.tmp को लगातार निष्पादित करने के लिए दूसरी प्रक्रिया बनाते हैं;
• एक बार Oplock ट्रिगर हो जाने पर, हम जंक्शन $pwd\2\ -> \RPC CONTROL\ बनाते हैं, और फिर ऑब्जेक्ट सिंबॉलिक \RPC CONTROL\WERFFFF.tmp -> $target और \RPC CONTROL\WERFFFF.tmp.etl -> $target बनाते हैं
• Oplock जारी करें, लक्ष्य फ़ाइल सिस्टम विशेषाधिकार के साथ हटा दी जाएगी।

विस्तृत शोषण और poc WERReport-CVE-2020-0753 में प्रदान किए गए हैं।

GetTempFileNameW में दोष का शोषण करके, हम एक अनुमानित स्थान प्राप्त करते हैं जहां सेवा काम करेगी; बहु-स्तरीय फ़ाइलसिस्टम जंक्शन का उपयोग करके, हम रेस कंडीशन को विश्वसनीय रूप से शोषण योग्य बनाते हैं।

इस बीच, हमने देखा कि इस प्रकार का रेस बग संभावित फ़ाइल अधिलेखन समस्या भी पैदा कर सकता है, तो यह कुछ परिस्थितियों में विशेषाधिकार उन्नयन बग की ओर ले जाने की संभावना है।

आंशिक नियंत्रण के साथ मनमानी फ़ाइल भ्रष्टाचार से विशेषाधिकार उन्नयन तक

यह समझाने के लिए कि मनमानी फ़ाइल भ्रष्टाचार (यदि आप फ़ाइल सामग्री के एक बहुत छोटे हिस्से को नियंत्रित कर सकते हैं: 63 बाइट्स से कम) को EoP में कैसे बदला जा सकता है, हमें विंडोज डिफेंडर के कार्य तंत्र पर ध्यान देने की आवश्यकता है।

विंडोज डिफेंडर के पास मैलवेयर हस्ताक्षर डेटाबेस है। यदि किसी फ़ाइल में कुछ मैलवेयर हस्ताक्षर हैं, तो डिफेंडर इसे मैलवेयर मानेगा और उन्हें हटा देगा। हालांकि, यह सुविधा अतिरिक्त हमले की सतह का परिणाम देगी। उदाहरण के लिए, WCTF2019 में टोक्योवेस्टर्न्स के @icchy ने "Gyotaku The Flag" नामक एक विंडोज सीटीएफ चुनौती डिजाइन की, जो इस सुविधा का उपयोग जानकारी लीक करने के लिए एक oracle के रूप में करती है।

यहां हम विंडोज डिफेंडर की इस सुविधा का लाभ उठाते हैं ताकि मनमानी फ़ाइल को हटाया जा सके यदि हमारे पास फ़ाइल सामग्री के आंशिक नियंत्रण के साथ मनमानी फ़ाइल भ्रष्टाचार है। हम बस एक फ़ाइल में मैलवेयर हस्ताक्षर लिख सकते हैं और विंडोज डिफेंडर द्वारा डिफ़ॉल्ट स्कैन को ट्रिगर कर सकते हैं, फ़ाइल डिफेंडर के अलगाव क्षेत्र में डाल दी जाएगी, जिसे एक सामान्य उपयोगकर्ता (अर्थात एक मध्यम-IL गैर-व्यवस्थापक उपयोगकर्ता) केवल स्कैन ऑपरेशन को 2 बार ट्रिगर करके हटा सकता है।

इसलिए एक मनमानी फ़ाइल भ्रष्टाचार बग को मनमानी फ़ाइल हटाने में बदला जा सकता है जब तक कि बग का उपयोग करके लक्ष्य फ़ाइल में मैलवेयर हस्ताक्षर स्ट्रिंग डाली जा सके।

• चरण1: बग के साथ लक्ष्य फ़ाइल को भ्रष्ट करें, इसमें विंडोज डिफेंडर द्वारा पहचाने जाने योग्य एक फीचर स्ट्रिंग डालें।

• चरण2: लक्ष्य फ़ाइल को स्कैन करने के लिए विंडोज डिफेंडर को ट्रिगर करें, जिससे फ़ाइल अलग हो जाए।

• चरण3: फिर से स्कैन ट्रिगर करें, लक्ष्य फ़ाइल हटा दी गई।

तकनीक का लाभ उठाकर हम डिफेंडर की मदद से मनमानी फ़ाइल हटाने की क्षमता प्राप्त करते हैं।

मनमानी फ़ाइल हटाने का शोषण आगे विशेषाधिकार प्राप्त करने के लिए बहुत आसानी से किया जा सकता है।

Microsoft OneDrive में छह स्थिर फ़ाइलसिस्टम DOS भेद्यताएं

Microsoft OneDrive एक एप्लिकेशन बंडल है जो व्यक्तिगत क्लाउड स्टोरेज सेवा प्रदान करता है, यह एप्लिकेशन विंडोज 8 से विंडोज में डिफ़ॉल्ट इंस्टॉलेशन विकल्प के रूप में एकीकृत किया गया है। हमारे शोध के दौरान, OneDrive की सर्विसिंग शेड्यूल किए गए कार्यों में 6 भेद्यताएं पाई गईं और MSRC को प्रस्तुत की गईं।

---

यहां Microsoft OneDrive संबंधित शेड्यूल किए गए कार्यों में उजागर होने वाली भेद्यताओं की एक तालिका है:

सभी 6 बग सेवा द्वारा हार्डलिंक और सिमलिंक को अनुचित रूप से संभालने के कारण होते हैं, जबकि ऐसे स्थानों पर काम करते हैं जो सामान्य उपयोगकर्ता के नियंत्रण में हैं। इन बगों के शोषण के दौरान, एक कठिनाई यह आती है कि फ़ाइल नाम में आमतौर पर वर्तमान प्रक्रिया का pid या एक टाइमस्टैम्प होता है जो यह चिह्नित करता है कि फ़ाइल कब संचालित की गई थी। दोनों को एक अद्वितीय dll फ़ाइल पर oplock सेट करके हल किया जा सकता है जिसे सेवा चलने पर लोड करने का प्रयास करेगी, जहां हमारे पास वह सब कुछ प्राप्त करने की क्षमता है जो बाद में सेवा द्वारा संचालित किए जाने वाले फ़ाइल नाम की भविष्यवाणी करने के लिए आवश्यक है। FileSyncConfigTemp_hardlink निर्देशिका में एक उदाहरण POC प्रदान किया गया है।

भेद्यता प्रभाव

ऊपर बताई गई सभी 6 भेद्यताएं पूर्ण रिपोर्ट और poc कार्यक्रम के साथ प्रदान की गई हैं, हालांकि अधिकांश बग पहली बार में मनमानी फ़ाइल भ्रष्टाचार का कारण बनते हैं, फिर भी इस प्रकार का बग सिस्टम क्रैश (महत्वपूर्ण सिस्टम कॉन्फ़िगरेशन फ़ाइल को अधिलेखित करके) का कारण बनता है, और उन सभी के लिए विंडोज को पुनर्स्थापित करने की आवश्यकता होगी। इस प्रकार यह विंडोज सिस्टम डिनायल ऑफ सर्विस बग प्रकार के मानक को पूरा करता है।

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

भेद्यता श्रेय

Fangming Gu

Zhiniang Peng of Qihoo 360 Core Security

समयरेखा

फरवरी 02 2020: भेद्यताएं रिपोर्ट की गईं

फरवरी 08 2020: MSRC ने जांच की और OneDrive में हमारे द्वारा प्रस्तुत 6 बगों के बारे में उत्तर दिया, उनका निष्कर्ष है कि बहुत अधिक उपयोगकर्ता सहभागिता आवश्यक/विश्वसनीय शोषण बनाना बहुत कठिन होने के कारण ठीक नहीं किया जाएगा।

फरवरी 08 2020: हमने उत्तर दिया: उपयोगकर्ता सहभागिता की कोई आवश्यकता नहीं है। आपको बस कार्य अनुसूची के चलने की प्रतीक्षा करनी होगी। तो, यह परिदृश्य सामान्य है।

फरवरी 11 2020: MSRC ने उत्तर दिया: आप उपयोगकर्ता की मशीन पर विशिष्ट फ़ाइल कैसे प्राप्त करते हैं? और क्या आप उस फ़ाइल के हर क्रमपरिवर्तन को उस फ़ोल्डर में रख रहे हैं? क्या इसे Date/Hour/PID से बिल्कुल मेल खाना होगा? इन्हीं कारणों से ऐसा लगता है कि इसमें बहुत अधिक उपयोगकर्ता प्रयास लगता है।

फरवरी 11 2020: हमने उत्तर दिया: हमारा poc एक सरलीकृत संस्करण है। फ़ाइल नाम का अनुमान लगाने के प्रयास को कम करने के लिए। वास्तव में, आपको बस एक oplock सेट करना होगा। फिर आप {pid},{hour},{data} सभी प्राप्त कर सकते हैं। तो, उपयोगकर्ता सहभागिता की कोई आवश्यकता नहीं है।

फरवरी 12 2020: पूछा कि क्या हम उन 6 भेद्यताओं के लिए राइटअप प्रकाशित कर सकते हैं।

फरवरी 13 2020: MSRC ने उत्तर दिया: आप राइटअप पोस्ट कर सकते हैं।

फरवरी 22 2020: विवरण प्रकाशित

स्थिति उन्नयन: सभी 6 भेद्यताओं को मार्च 2020 के पैच मंगलवार में एक फिक्स प्राप्त हुआ है।