विंडोज 8 - इसे SMEP होने दें!

आइवी ब्रिज वास्तुकला पर आधारित इंटेल प्रोसेसर की एक नई पीढ़ी के आगमन के साथ, एक नया सुरक्षा हार्डवेयर पेश किया गया है। इसे Intel SMEP कहा जाता है। NX बिट की तरह, जो कोड को मेमोरी पेज पर क्रियान्वित करने से रोकता है, यह कर्नेल-मोड कमजोरियों का शोषण करने के लिए एक सिरदर्द जोड़ता है।

बदले में, माइक्रोसॉफ्ट ने विंडोज 8 में एसएमईपी सपोर्ट लागू किया, इस तरह यह ओएस और भी सुरक्षित हो गया। हालांकि, एसएमईपी समर्थन "हेड-ऑन" का पहला कार्यान्वयन एक मामूली दोष निकला, जिसकी बदौलत हमलावर को अभी भी कमजोरियों का शोषण करने की संभावना है जो उसके लिए अपेक्षाकृत दर्द रहित है।

SMEP क्या है?

SMEP का अर्थ "पर्यवेक्षक मोड निष्पादन रोकथाम" है - पर्यवेक्षक मोड में कोड निष्पादन को रोकना। सुपरवाइजर मोड एक पसंदीदा प्रोसेसर मोड है जिसमें विंडोज 8 का कर्नेल चलता है। OS के संदर्भ में, इस मोड को कर्नेल मोड भी कहा जाता है। इसके विपरीत उपयोगकर्ता मोड है - इस मोड में, उपयोगकर्ता एप्लिकेशन निष्पादित होते हैं।

ओएस सुरक्षा इस तथ्य पर आधारित है कि उपयोगकर्ता अनुप्रयोग विशेषाधिकारित संचालन नहीं कर सकते हैं, उदाहरण के लिए, I / O बंदरगाहों, प्रोसेसर नियंत्रण रजिस्टर आदि का उपयोग करना। इसके अलावा, कर्नेल मोड में उपयोग की जाने वाली मेमोरी उपयोगकर्ता मोड एक्सेस से सुरक्षित है। एक उपयोगकर्ता एप्लिकेशन कर्नेल मेमोरी में कोड को सीधे पढ़, संशोधित या निष्पादित नहीं कर सकता है। ओएस कर्नेल के साथ बातचीत अप्रत्यक्ष रूप से सिस्टम कॉल इंटरफ़ेस के माध्यम से होती है।

विशेषाधिकार मोड, बदले में, कोई प्रतिबंध नहीं है, यदि एसएमईपी के लिए नहीं। यदि इसे चालू किया जाता है, तो उपयोगकर्ता एप्लिकेशन की मेमोरी में स्थित कोड को निष्पादित करने के किसी भी प्रयास का परिणाम पृष्ठ दोष होगा। विशेष रूप से, विंडोज 8 पर पृष्ठ त्रुटि हैंडलर में, यह स्थिति बगचेक का कारण बनेगी।
सीधे शब्दों में कहें, अगर कर्नेल का कोई भी ड्राइवर या सिस्टम मॉड्यूल उपयोगकर्ता एप्लिकेशन की मेमोरी में स्थित कोड को निष्पादित करने की कोशिश करता है, तो यह सब दुख की बात है एक उदास इमोटिकॉन के साथ मौत की नीली स्क्रीन के साथ समाप्त होगा।

क्या बात है?

कर्नेल मोड में कमजोरियां एक हमलावर के लिए सबसे "स्वादिष्ट" हैं, क्योंकि सफल ऑपरेशन के बाद वह लक्ष्य प्रणाली पर पूर्ण नियंत्रण हासिल करता है। मुद्दा यह है कि कर्नेल मोड में कमजोरियों का शोषण करते समय, एक हमलावर, एक नियम के रूप में, शेल कोड को संग्रहीत करने के लिए उपयोगकर्ता मोड में मेमोरी आवंटित करता है।

“लेकिन कर्नेल मोड में, आप उपयोगकर्ता मेमोरी के पृष्ठों से कोड निष्पादित नहीं कर सकते हैं! और शेल कोड को कहाँ स्टोर करना है? आपके स्वयं के शेलकोड के बिना हमले का क्या मतलब है? या हो सकता है कि आपको तब हमला करने की आवश्यकता न हो?

इस तरह की हमलावर ट्रेन के विचार की उम्मीद के साथ, यह तकनीक बनाई गई थी। यदि आप इसके कार्यान्वयन को ध्यान में रखते हैं और अन्य रक्षा तंत्रों के साथ "रियर" को कवर करते हैं, तो यह अंतिम उपयोगकर्ता को हमलों की एक पूरी श्रेणी से बचाने में सक्षम है।

पहला पैनकेक गांठदार है

इसे खत्म करने की सोचते हैं। आप उपयोगकर्ता स्थान में शेलकोड संग्रहीत नहीं कर सकते। इसका मतलब यह है कि यह कर्नेल मेमोरी में स्थित होना चाहिए (पसंद केवल महान नहीं है - केवल दो मोड), इस मेमोरी अनुभाग की सामग्री को हमारे द्वारा नियंत्रित किया जाना चाहिए (हम उपयोगकर्ता मोड से सीधे नहीं लिख सकते हैं), और उपयोगकर्ता मोड से इस मेमोरी अनुभाग का पता लगाना संभव हो सकता है (आप नहीं कर सकते) और सीधे उपयोगकर्ता मोड से पढ़ें)। कर्नेल को शेलकोड देने के लिए क्या उपयोग किया जा सकता है?

सबसे स्पष्ट समाधान विंडोज ऑब्जेक्ट्स का उपयोग करना है। जिन अनुप्रयोगों के साथ वर्णनकर्ता (हैंडल) के माध्यम से काम किया जाता है। ये सभी प्रकार की टाइमर, घटनाएँ, म्यूटेक्स, I / O समापन पोर्ट, ग्राफिक ऑब्जेक्ट्स आदि हैं। ऐसी वस्तु का शरीर कर्नेल मेमोरी में स्थित होता है, और उपयोगकर्ता मोड से सामग्री को बदला जा सकता है, और हम पता लगा सकते हैं कि कर्नेल स्थान में वे किस पते पर स्थित हैं!

उदाहरण के लिए, जब हम CreateFile () फ़ंक्शन के साथ एक फ़ाइल खोलते हैं, तो हमें खुली फ़ाइल के लिए एक हैंडल मिलता है। यदि एप्लिकेशन को इस फ़ाइल के कुछ बाइट्स को बफ़र में पढ़ने की आवश्यकता है, तो हम ReadFile () फ़ंक्शन को कॉल करते हैं, जो सिस्टम कॉल का उपयोग करते हुए, ओएस कर्नेल पर नियंत्रण स्थानांतरित करता है, जहां यह विवरण तालिका से वांछित फ़ाइल ऑब्जेक्ट पाता है। इस स्थिति में, ऑब्जेक्ट _FILE_OBJECT का प्रकार है, और इसमें चर क्षेत्र फ़ाइल नाम है। यानी सैद्धांतिक रूप से, आप "\ 0xBAADC0DE" नामक एक फ़ाइल बना सकते हैं जिसमें हमारा शेलकोड होगा। फिर हम एक निश्चित कर्नेल मोड भेद्यता का उपयोग करते हैं और हमारे शेल कोड पर नियंत्रण स्थानांतरित करते हैं।

0: kd> dt nt! _FILE_OBJECT
+ 0x000 प्रकार: Int2B
+ 0x002 आकार: Int2B
...
+ 0x050 फ्लैग: Uint4B
+ 0x058 फ़ाइल का नाम: _UNICODE_STRING
+ 0x068 CurrentByteOffset: _LARGE_INTEGER
...
+ 0x0c0 IrpList: _LIST_ENTRY
+ 0x0d0 FileObjectExtension: Ptr64 शून्य

सफलता? अभी काफी नहीं है। तथ्य यह है कि विंडोज 8 पर एसएमईपी एक अन्य सुरक्षा तंत्र द्वारा पूरक है। इस तथ्य के बावजूद कि कोड कर्नेल मोड पृष्ठ पर स्थित है, इस पृष्ठ पर एक चिह्न (बिट NX) है जो यह निष्पादन योग्य नहीं है, अर्थात। इस पृष्ठ पर कोड निष्पादित नहीं किया जा सकता है! यह पता चला है कि विंडोज ऑब्जेक्ट्स निष्पादन से सुरक्षित हैं, इसलिए, शेल कोड को संग्रहीत करने के लिए भी उपयुक्त नहीं हैं। यह कथन Windows 8 के x64 संस्करण के लिए सही है। हालाँकि, x86 संस्करण में ग्राफ़िक ऑब्जेक्ट्स का मुख्य भाग निष्पादन योग्य मेमोरी में स्थित है!

पैलेट एक शेलकोड देने के लिए सबसे उपयुक्त वस्तु निकला। यह CreatePalette () फ़ंक्शन और LOGPALETTE संरचना का उपयोग करके बनाया गया है, जिनमें से सामग्री शेल कोड से भरी हुई है। फिर भी, पैलेट में रंगों को कैसे मान्य किया जाए? वास्तव में, हमारे पैलेट में बिल्कुल वही रंग होंगे जो हम चाहते हैं! और हम NOP (0x90) के कई बाइट्स, और शेलकोड के कई बाइट्स चाहते हैं। यहाँ एक "दुष्ट" पैलेट है ...



कुल हमारे पास विंडोज 8 x86 पर SMEP बाईपास योजना है:
1. "बुराई" LOGPALETTE संरचना बनाएँ, इसे शेलकोड के साथ भरना।
2. CreatePalette () के माध्यम से एक पैलेट बनाएं।
3. साझा GDI तालिका के माध्यम से कर्नेल में पैलेट ऑब्जेक्ट का पता लगाएं।
4. हम पैलेट ऑब्जेक्ट से एक निश्चित ऑफसेट पर नियंत्रण स्थानांतरित करते हैं।
5. ???????
6. लाभ !!!

और x64 के साथ क्या करना है?

विंडोज 8 x64 पर SMEP वर्कअराउंड चाहते हैं? मेरे पास है! शायद यह तरीका इतना दिलचस्प नहीं है, लेकिन यह काम कर रहा है। X64 पर SMEP को रिटर्न ओरिएंटेड प्रोग्रामिंग (ROP) का उपयोग करके बाईपास किया जाता है। संक्षेप में, ROP अन्य मॉड्यूल से कोड के वर्गों का उपयोग करता है जो पहले से ही मेमोरी में मौजूद हैं। इस प्रकार, आपको कर्नेल के लिए अपना शेल कोड अग्रेषित करने की आवश्यकता नहीं है।

बेशक, इस मामले में पेलोड की तैयारी में हमलावर की क्षमताएं बहुत सीमित हैं। लेकिन हमलावर की जरूरत है कि सभी SMEP को निष्क्रिय करना है, और इसके लिए, ntoskrnl मॉड्यूल को HvlEndSystemInterrupt () और KiConfigureDynamDProProcessor () फ़ंक्शन के रूप में "प्रस्तुत" करता है। इन फ़ंक्शन के अंतिम बाइट्स आपको दिए गए प्रोसेसर पर SMEP को अक्षम करने की अनुमति देते हैं।

HvlEndSystemInterrupt(): … pop rax pop rcx retn 

 KiConfigureDynamicProcessor(): … mov cr4, rax add rsp, 28h retn 

 // ROP chain to refresh cr4 value // vTrash vROPChain DWORD_PTR dwRopStack[7 + 10] = {0}; // HvlEndSystemInterrupt gadget dwRopStack[7 + 0] = dwKernelBase + HvlGadgetOffset; // New CR4 value dwRopStack[7 + 1] = 0x00000000000506F8; // KiConfigureDynamicProcessor dwRopStack[7 + 3] = dwKernelBase + Cr4GadgetOffset; // Out address (shellcode) dwRopStack[7 + 9] = (DWORD_PTR)pTestBuf; 

प्रतिबंध नीचे

एसएमईपी अक्षम होने के बाद, हमलावर उपयोगकर्ता बफर से कोड निष्पादित करने में सक्षम है, अर्थात। शेलकोड के आकार पर कोई अधिक प्रतिबंध नहीं हैं। आप कर्नेल भेद्यता का उपयोग कर सकते हैं जो SMEP को "बुराई" शेल कोड में पहले से ही स्थानांतरित करने के लिए अक्षम करने के लिए उपयोग किया गया था।

निष्कर्ष

बेशक, दोनों विधियां सार्वभौमिक नहीं हैं। प्रत्येक भेद्यता की अपनी शोषण की विशेषताएं हैं। कुछ मामलों में, वर्कआर्ड को पूरा करना होगा, जबकि अन्य में वे आम तौर पर लागू नहीं होते हैं।

यह समझना भी महत्वपूर्ण है कि यह अपने आप में एक शोषक भेद्यता नहीं है। यह सुरक्षा तंत्रों में से एक को दरकिनार करने की एक विधि है, और इसका उपयोग केवल कुछ अन्य शोषक भेद्यता के साथ किया जा सकता है।

PS SMEP कोड के 13 बाइट्स द्वारा अक्षम है। जानकारी के लिए, कृपया नीचे दिए गए लिंक का पालन करें।
विंडोज 8 x86 पर SMEP को कैसे हराया जाए
विंडोज 8 x64 पर एसएमईपी को कैसे हराया जाए

लेखक: अर्टोम शिशकिन और इलिया स्मिथ