l3cr0f/dccwbypassuacWindows 8.1 और 10 में "dccw.exe" में WinSxS का दुरुपयोग करके UAC बाईपास।
यह एक्सप्लॉइट लियो डेविडसन के "Bypass UAC" विधि के व्युत्पन्न के माध्यम से "dccw.exe" द्वारा "WinSxS" के प्रबंधन के तरीके का दुरुपयोग करता है, ताकि सहमति के लिए संकेत दिए बिना एक प्रशासक शेल प्राप्त किया जा सके। यह "x86" और "x64" आर्किटेक्चर का समर्थन करता है। इसके अलावा, इसका परीक्षण Windows 8.1 9600, Windows 10 14393, Windows 10 15031 और Windows 10 15062 पर सफलतापूर्वक किया गया है।
यदि आप देखना चाहते हैं कि स्क्रिप्ट को कैसे निष्पादित किया जाए, तो उपयोग अनुभाग देखें। साथ ही, आप इसे Metasploit में निष्पादित कर सकते हैं और प्रशासक अधिकारों के साथ एक Meterpreter सत्र प्राप्त कर सकते हैं।
एक नया bypass UAC विकसित करने के लिए, पहले हमें सिस्टम पर एक भेद्यता खोजनी होती है और, अधिक सटीक होने के लिए, एक auto-elevate प्रक्रिया में भेद्यता। ऐसी प्रक्रियाओं की सूची प्राप्त करने के लिए हमने Sysinternals का Strings नामक टूल उपयोग किया। उसके बाद, हम कुछ auto-elevate प्रक्रियाओं जैसे "sysprep.exe", "cliconfig.exe", "inetmgr.exe", "consent.exe" या "CompMgmtLauncher.exe" को देख सकते थे, जिनमें (कुछ में अभी भी हैं) ऐसी भेद्यताएँ थीं जो "bypass UAC" के निष्पादन की अनुमति देती हैं। इसलिए, हमने अध्ययन करना शुरू किया कि अन्य auto-elevate प्रक्रियाएँ Sysinternals के Process Monitor (ProcMon) नामक एप्लिकेशन के साथ कैसे काम करती हैं, लेकिन "dccw.exe" प्रक्रिया पर ध्यान केंद्रित करते हुए।
हालाँकि, ProcMon के साथ शुरू करने से पहले, हमने पहले Sigcheck नामक Sysinternals के एक अन्य एप्लिकेशन के साथ ऐसे अनुप्रयोगों के मैनिफेस्ट की जाँच की, और निश्चित रूप से, हमारे मामले में "dccw.exe" एक auto-elevate प्रक्रिया है।
फिर, हम ProcMon के साथ "dccw.exe" के निष्पादन प्रवाह का अनुसरण करना शुरू कर सकते थे, यह देखने के लिए कि क्या कुछ अजीब घटित होता है, कुछ ऐसा जिसे हमने तुरंत जाँचा। किसी बिंदु पर, यदि हमने 64 बिट Windows मशीन पर "dccw.exe" को 64 बिट प्रक्रिया के रूप में निष्पादित किया है, तो यह "GdiPlus.dll" नामक एक विशिष्ट DLL लोड करने के लिए निर्देशिका "C:\Windows\System32\dccw.exe.Local\" की खोज करता है, वैसे ही जैसे यह 32 बिट Windows मशीन पर निष्पादित किया गया हो, जबकि यदि हम उसी मशीन पर इसे 32 बिट के रूप में निष्पादित करते हैं, तो प्रक्रिया निर्देशिका "C:\Windows\SysWOW64\dccw.exe.Local\" की खोज करेगी। फिर, इस तथ्य के कारण कि यह मौजूद नहीं है, प्रक्रिया वांछित DLL प्राप्त करने के लिए हमेशा पथ "C:\Windows\WinSxS\" में एक फ़ोल्डर की खोज करती है, इस फ़ोल्डर का नाम निम्नलिखित संरचना के साथ होता है:
[architecture]_microsoft.windows.gdiplus_[sequencial_code]_[Windows_version]_none_[sequencial_number]
यदि हम "WinSxS" निर्देशिका पर एक नज़र डालें, तो हम इस संरचना से मेल खाने वाले एक से अधिक फ़ोल्डर देख सकते हैं, इसका मतलब है कि "dccw.exe" इनमें से किसी भी फ़ोल्डर से वांछित DLL लोड कर सकता है। केवल एक चीज जिसके बारे में हमें यकीन है वह यह है कि यदि एप्लिकेशन को x86 प्रक्रिया के रूप में आमंत्रित किया जाता है, तो फ़ोल्डर का नाम स्ट्रिंग "x86" से शुरू होगा, जबकि यदि हम इसे x64 प्रक्रिया के रूप में निष्पादित करते हैं, तो इसका नाम स्ट्रिंग "amd64" से शुरू होगा।
इस स्थिति का दुरुपयोग DLL अपहरण करने और फिर सहमति के लिए संकेत दिए बिना उच्च अखंडता के साथ कोड निष्पादित करने के लिए किया जा सकता है।
जब हमें एक auto-elevate प्रक्रिया के निष्पादन के दौरान एक त्रुटि मिल जाती है, तो हमें यह सत्यापित करने की आवश्यकता होती है कि क्या इसका दुरुपयोग किया जा सकता है या नहीं। ऐसा करने के लिए, हमने केवल वांछित पथ में "dccw.exe.Local" फ़ोल्डर बनाया और, उस फ़ोल्डर के अंदर, हमने "WinSxS" में स्थित उन फ़ोल्डरों को बनाया जिन्हें "GdiPlus.dll" लोड करने के लिए प्रक्रिया द्वारा आमंत्रित किया जा सकता था, लेकिन उस DLL के बिना।
अब, यदि हम "dccw.exe" निष्पादित करते हैं, तो हम देखेंगे कि प्रक्रिया ने "dccw.exe.Local" फ़ोल्डर और "WinSxS" फ़ोल्डरों में से एक को ढूंढ लिया है, लेकिन वांछित DLL नहीं, जो एक त्रुटि उत्पन्न करता है। यह वही है जिसकी हमें उम्मीद थी, क्योंकि उस स्थिति का दुरुपयोग एक हमलावर द्वारा किया जा सकता है जैसा कि हमने पहले उल्लेख किया था।
इस बिंदु पर, हम पहले से ही जानते हैं कि हम "dccw.exe" का दुरुपयोग करके Windows 10 पर एक bypass UAC कर सकते हैं, लेकिन कैसे?
UAC को बायपास करने के लिए सबसे अधिक उपयोग की जाने वाली विधि वह है जिसे लियो डेविडसन द्वारा विकसित किया गया है। हालाँकि, यह IFileOperation COM ऑब्जेक्ट को आमंत्रित करने के लिए एक प्रक्रिया इंजेक्शन करता है, जिसे कुछ एंटीवायरस सॉफ़्टवेयर द्वारा पहचाना जा सकता है, इसलिए इसे उपयोग करने के लिए एक बेहतर तरीका वह है जिसे Masquerade PEB कहा जाता है, जिसे Cn33liz ने अपने स्वयं के bypass UAC में उपयोग किया है।
साथ ही, हमें नए Windows 10 संस्करणों में IFileOperation को आमंत्रित करने के तरीके को संशोधित करना होगा, क्योंकि लियो डेविडसन विधि build 15002 से UAC को ट्रिगर करती है। इसलिए, ऐसे ऑपरेशन को आमंत्रित करने का हमारा तरीका मूल के समान है, लेकिन ऑपरेशन फ्लैग "FOF_SILENT", "FOFX_SHOWELEVATIONPROMPT" और "FOF_NOERRORUI" के बिना।
एक्सप्लॉइट को निष्पादित करने से पहले, कुछ पहलुओं की जाँच करना महत्वपूर्ण है ताकि इसे असफल रूप से निष्पादित न किया जाए और इसलिए कुछ अलार्म ट्रिगर न हों। पहली चीज जो हम जाँचते हैं वह Windows build संस्करण है, क्योंकि कुछ संस्करण हमारे एक्सप्लॉइट के लिए असुरक्षित नहीं हैं (जिनका build संस्करण 7600 से कम है)। उसके बाद, हम सत्यापित करते हैं कि हमारे पास अभी तक प्रशासक अधिकार नहीं हैं, यदि ऐसा नहीं है, तो स्क्रिप्ट को निष्पादित करने का कोई कारण नहीं है। फिर, हम UAC सेटिंग्स की जाँच करते हैं ताकि यह पुष्टि हो सके कि यह "Always notify" पर सेट नहीं है, क्योंकि यदि यह उस मान पर सेट होता, तो हमारा एक्सप्लॉइट बेकार हो जाता। अंत में, हम सत्यापित करते हैं कि क्या उपयोगकर्ता प्रशासकों समूह से संबंधित है, क्योंकि यदि नहीं, तो एक्सप्लॉइट असफल हो जाएगा।
जब एक एक्सप्लॉइट विकसित किया जाता है, तो यह महत्वपूर्ण है कि यह जितने संभव हो उतने सिस्टमों पर काम कर सके, इसमें 32 बिट Windows सिस्टम शामिल हैं। इसे प्राप्त करने के लिए, हमें अपने एक्सप्लॉइट को ऐसे सिस्टमों के लिए संकलित करने की आवश्यकता है, क्योंकि हम इसे 64 बिट सिस्टमों में भी निष्पादित कर सकते हैं।
जब हमारा 32 बिट एक्सप्लॉइट 64 बिट Windows मशीन पर निष्पादित होता है, तो "dccw.exe" जिस तरह से संचालित होता है वह WOW64 (Windows सबसिस्टम जो 64 बिट मशीनों को 32 बिट एप्लिकेशन चलाने की अनुमति देता है) के आमंत्रण के कारण थोड़ा अलग होता है। इसका मतलब है कि "dccw.exe.Local" फ़ोल्डर "C:\Windows\SysWOW64\" निर्देशिका में खोजा जाएगा, न कि "C:\Windows\System32\" में, बल्कि लक्षित "GdiPlus.dll" भी एक 32 बिट DLL होगा, जिसका अर्थ है कि इसे उस नाम पैटर्न "C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_*" से मेल खाने वाले फ़ोल्डर में खोजा जाएगा। हालाँकि, यदि इसे 32 बिट Windows सिस्टम पर निष्पादित किया जाता है, तो एक्सप्लॉइट उम्मीद के अनुसार काम करेगा।
अंत में, यह ध्यान देने योग्य है कि हमें DLL अपहरण करते समय पैटर्न "C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_*" से मेल खाने वाले सभी पथों पर विचार करने की आवश्यकता है ताकि 100% प्रभावशीलता सुनिश्चित हो सके।
उच्च अखंडता के साथ एक प्रक्रिया निष्पादित करने के लिए हमें एक DLL विकसित करने की आवश्यकता है जिसे DLL अपहरण के माध्यम से आमंत्रित किया जाएगा। हालाँकि, यह उतना सरल नहीं है जितना दिखता है, क्योंकि यदि हम केवल ऐसा करते हैं, तो न तो "dccw.exe" और न ही हमारा कोड निष्पादित होगा। ऐसा इसलिए है क्योंकि "dccw.exe" "GdiPlus.dll" के कुछ कार्यों पर निर्भर करता है, इसलिए हमें ऐसे कार्यों के निष्पादन को वैध DLL पर लागू या अग्रेषित करने की आवश्यकता है।
सबसे अच्छा विकल्प निष्पादन को वैध DLL पर अग्रेषित करना है, क्योंकि इस तरह हमारे DLL का आकार कम होगा। ऐसा करने के लिए, हमने "GdiPlus.dll" के सभी एक्सपोर्ट्स को C++ भाषा में पोर्ट करने के लिए ExportsToC++ प्रोग्राम का उपयोग किया। अब, समस्या "GdiPlus.dll" के एक्सपोर्ट्स की विशाल संख्या है, सटीक होने के लिए 631, फिर भी, "dccw.exe" उन सभी को आयात नहीं करता है, बल्कि कुछ को। यह जानने के लिए कि "dccw.exe" द्वारा "GdiPlus.dll" से कौन से कार्य आयात किए जाते हैं, हमने "IDA Pro" के साथ इसका रिवर्स इंजीनियरिंग किया। अंत में, "GdiPlus.dll" से केवल 15 कार्य आयात किए जाते हैं, इसलिए हमें केवल उन्हें अपने DLL में शामिल करने की आवश्यकता है।
अब, ऐसा लगता है कि समस्या हल हो गई है, लेकिन यदि हम C:\Windows\WinSxS\" में एक विशिष्ट "GdiPlus.dll" पर निष्पादन अग्रेषित करते हैं, तो DLL केवल कुछ सिस्टमों पर काम करेगा, क्योंकि "WinSxS" के आंतरिक फ़ोल्डरों का नाम हर Windows build के साथ बदलता है। इस समस्या को दूर करने के लिए, हमने निष्पादन को "C:\Windows\System32\GdiPlus.dll" पर अग्रेषित करने का विचार किया, इस तथ्य के कारण कि पथ सभी Windows 10 सिस्टमों में समान है।
आखिरी चीज जो हमें करनी है वह है अपने दुर्भावनापूर्ण कोड को निष्पादित करने के बाद "dccw.exe" के निष्पादन को रोकना ताकि उस प्रक्रिया की विंडो खुलने से बचा जा सके।
अब, एक बार जब हम अपना दुर्भावनापूर्ण DLL विकसित कर लेते हैं, तो हमें इसे लक्षित मशीन पर डालने की आवश्यकता होती है। ऐसा करने के लिए, हमारे DLL को संपीड़ित किया गया है और "base64" में एक्सप्लॉइट में एन्कोड किया गया है, ताकि इसे उम्मीद के अनुसार डालने के लिए रनटाइम पर डिकोड और डीकंप्रेस किया जा सके।
अंत में, हमारा निर्मित "GdiPlus.dll" पहले बताए अनुसार IFileOperation COM ऑब्जेक्ट का उपयोग करके लक्षित स्थान पर कॉपी किया जाता है।
जब कोई हमलावर किसी सिस्टम से समझौता करता है, तो वह जितना संभव हो उतने समय तक अज्ञात रहना चाहता है, इसका मतलब है कि वह जो कार्य करता है उसके हर निशान को हटाना। इसके कारण, एक्सप्लॉइट के निष्पादन के दौरान बनाई गई सभी अस्थायी फ़ाइलें हटा दी जाती हैं जब उनकी आवश्यकता नहीं रह जाती।
अंत में, हमें यह निर्धारित करने की आवश्यकता है कि हम किस प्रक्रिया को उच्च अखंडता पर निष्पादित करना चाहते हैं। हमारे मामले में, हमने "cmd.exe" एप्लिकेशन को चुना क्योंकि यह हमें एक बार प्रशासक अधिकार प्राप्त होने के बाद उच्च अखंडता पर जितनी चाहें उतनी कार्रवाई करने की अनुमति देता है, लेकिन, वास्तव में, हम जो भी एप्लिकेशन चाहें निष्पादित कर सकते हैं।
एक्सप्लॉइट को निष्पादित करने के लिए आपको यह सुनिश्चित करना होगा कि लक्षित मशीन आवश्यकताओं को पूरा करती है। फिर, आपको केवल किसी अन्य कमांड-लाइन स्क्रिप्ट की तरह एक्सप्लॉइट को निष्पादित करना है:
C:\Users\L3cr0f> DccwBypassUAC.exe
इस PoC का Metasploit मॉड्यूल Masquerading PEB के बजाय DLL इंजेक्शन का उपयोग करता है और यह निम्न में उपलब्ध है:
- Metasploit Framework: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/local/bypassuac_injection_winsxs.rbयह एक्सप्लॉइट यह दिखाने के लिए विकसित किया गया है कि एक हमलावर सिस्टम में विशेषाधिकार कैसे प्राप्त कर सकता है, न कि इसे दुर्भावनापूर्ण उद्देश्यों के लिए उपयोग करने के लिए। इसका मतलब है कि अगर कोई इसे आपराधिक गतिविधियों को करने के लिए उपयोग करता है तो मैं कोई जिम्मेदारी नहीं लेता।
यूज़र एक्सेस कंट्रोल (UAC) एक तकनीक है जिसे Windows Vista के साथ पेश किया गया था जो मानक उपयोगकर्ता विशेषाधिकारों और कार्यों को उन लोगों से अलग करने की एक विधि प्रदान करती है जिन्हें प्रशासक पहुंच की आवश्यकता होती है। यदि एक मानक उपयोगकर्ता सिस्टम का उपयोग कर रहा है और एक ऐसी कार्रवाई करने का प्रयास करता है जिसके लिए उपयोगकर्ता के पास अधिकार नहीं है, तो Windows से एक संकेत प्रकट होता है और प्रशासक खाते का पासवर्ड मांगता है। यदि कोई प्रशासक सिस्टम का उपयोग कर रहा है और उसी कार्य को करने का प्रयास करता है, तो केवल एक चेतावनी संकेत होता है। वह संकेत "Consent Prompt" के रूप में जाना जाता है क्योंकि प्रशासक से केवल आगे बढ़ने से पहले कार्रवाई के लिए सहमत होने के लिए कहा जाता है। एक कमजोरी जो "Consent Prompt" को बायपास करने की अनुमति देगी, उसे सुरक्षा भेद्यता नहीं माना जाता है, क्योंकि इसे सुरक्षा सीमा नहीं माना जाता है।
हालाँकि, Microsoft यह भी कहता है कि "User Account Control (UAC) Microsoft की समग्र सुरक्षा दृष्टि का एक मूलभूत घटक है"।
स्रोत:
- सुरक्षा भेद्यता की परिभाषा।
- User Account Control कैसे काम करता है।