
(1) IQVW32.sys 1.3.1.0 से पहले और (2) IQVW64.sys 1.3.1.0 से पहले, विंडोज के लिए इंटेल ईथरनेट डायग्नोस्टिक्स ड्राइवर में, स्थानीय उपयोगकर्ताओं को एक निर्मित (a) 0x80862013, (b) 0x8086200B, (c) 0x8086200F, या (d) 0x80862007 IOCTL कॉल के माध्यम से सेवा अस्वीकार या संभवतः कर्नेल विशेषाधिकारों के साथ मनमाना कोड निष्पादित करने की अनुमति देता है।
(1) IQVW32.sys 1.3.1.0 से पहले और (2) IQVW64.sys 1.3.1.0 से पहले इंटेल ईथरनेट डायग्नोस्टिक्स ड्राइवर विंडोज के लिए स्थानीय उपयोगकर्ताओं को (a) 0x80862013, (b) 0x8086200B, (c) 0x8086200F, या (d) 0x80862007 IOCTL कॉल के माध्यम से सेवा से इनकार या कर्नेल विशेषाधिकारों के साथ मनमाना कोड निष्पादित करने की अनुमति देता है।
इस रिपॉजिटरी में प्रश्न में भेद्यता का एक विवरण शामिल है, साथ ही 64-बिट विंडोज 7 SP1 और विंडोज 10 20H2 पर कार्यात्मक प्रूफ-ऑफ-कॉन्सेप्ट एक्सप्लॉइट्स शामिल हैं। ड्राइवर फ़ाइल Driver Files निर्देशिका में स्थित की जा सकती है। यदि आप विवरण/पेपर में कोई टाइपो खोजते हैं, या यदि आप अधिक विस्तृत विवरण के साथ कुछ विवरण देखना चाहते हैं, तो कृपया रिपॉजिटरी पर एक मुद्दा बनाएं! मैं उन्हें जल्द से जल्द ठीक कर दूंगा।
विशेष रूप से इस डिवाइस ड्राइवर के लिए एक एक्सप्लॉइट लिखने के पीछे प्रेरणा केवल यह है कि वर्तमान में इसका दुरुपयोग जंगल में हमलावर के अहस्ताक्षरित रूट-किट को लोड करने के लिए किया जा रहा है। BYOVD (अपना स्वयं का कमजोर ड्राइवर लाओ) विधि का उपयोग करके, मैलवेयर जांच सकता है कि क्या यह उन्नत विशेषाधिकारों के साथ चल रहा है, कमजोर डिवाइस ड्राइवर की एक प्रति छोड़ता है, ड्राइवर को लोड करता है, और बाद में रूट-किट को लोड करने के लिए कर्नेल कोड निष्पादन प्राप्त करने के लिए इसका शोषण करता है। मैं मैलवेयर नमूने को सफलतापूर्वक रिवर्स इंजीनियर करने में असमर्थ था, इसलिए मैंने एक्सप्लॉइट बनाने का बीड़ा उठाया।
जंगल में देखे गए नमूने: https://bazaar.abuse.ch/sample/84ed7fec67de5621806dbb43af5167a5fc60ab7f2403448519dc0eca2b8f9022/ https://bazaar.abuse.ch/sample/0925b8985b19d7925d68186d666b0050a4cb3f2a577d64765d770a57a2eab9ae/ https://bazaar.abuse.ch/sample/e8b7f42d544fe8b954c4021315cff2fdd44d67d11704009cdf3037d34e0c0a93/
डिवाइस ड्राइवर, जिसका नाम iqvw64e.sys है, एक ड्राइवर है जो नेटवर्क एडेप्टर डायग्नोस्टिक्स करने के लिए डिज़ाइन किया गया है। यह उपयोगकर्ता-मोड घटक को कुछ IO नियंत्रण कोड (जिन्हें IOCTLs भी कहा जाता है) को उजागर करके डिवाइस ड्राइवर के साथ बातचीत करने की अनुमति देता है, जिसमें बातचीत के दौरान उपयोगकर्ता के इनपुट बफर में एक "उप" IO नियंत्रण कोड प्रदान किया जाता है। कमजोर कोड-पथ को हिट करने के लिए उपयोग किया जाने वाला IO नियंत्रण कोड 0x80862007 है। प्राथमिक नियंत्रण कोड के अलावा, इस विश्लेषण में शामिल किए जाने वाले उल्लिखित "उप" IO नियंत्रण कोड 0x33 कोड होंगे जो memmove फ़ंक्शन कॉल को हिट करने के लिए, और 0x30 कोड जो memset फ़ंक्शन कॉल कोड-पथ को हिट करने के लिए होंगे। यह विवरण DriverEntry रूटीन के बारे में कोई विवरण शामिल नहीं करेगा, क्योंकि Microsoft के दस्तावेज़ीकरण पृष्ठ पर पर्याप्त दस्तावेज़ीकरण है जो आपको एक विस्तृत स्पष्टीकरण देता है।
शुरू करने के लिए, हम जानना चाहते हैं कि हम पहले स्थान पर इस विशेष डिवाइस ड्राइवर के साथ कैसे बातचीत कर सकते हैं। डिवाइस ड्राइवर के साथ संचार करने का सबसे सामान्य तरीका DeviceIoControl नामक फ़ंक्शन के उपयोग के माध्यम से है। इस फ़ंक्शन के पीछे सामान्य विचार यह है कि हम CreateFileA द्वारा बनाए गए एक वैध ड्राइवर हैंडल को पास कर सकते हैं, एक IO नियंत्रण कोड पास कर सकते हैं जो उस कर्नेल रूटीन से मेल खाता है जिसे हम चाहते हैं, एक संरचना (या बफर) पास कर सकते हैं जिसकी वह अपेक्षा करता है, और यह हमारे आउटपुट बफर में डेटा लौटाएगा। जबकि इस तरह की रूटीन कभी-कभी आवश्यक हो सकती हैं (जैसे ओवरक्लॉकिंग उद्देश्यों के लिए मॉडल-विशिष्ट रजिस्टरों तक पहुंचना), वे सुरक्षा के लिए एक गंभीर जोखिम भी पैदा करते हैं। लेकिन... कैसे?
CVE-2015-2291 के मामले में, भेद्यता एक अनप्रिविलेज्ड उपयोगकर्ता द्वारा ट्रिगर की जा सकती है। क्योंकि कोई सैनिटाइजेशन जांच मौजूद नहीं है, और भेद्यता का शोषण करने के लिए प्रशासक विशेषाधिकारों की आवश्यकता नहीं है, यह एक सुरक्षा जोखिम पैदा करता है। इन दो खामियों के नीचे जो निहित है, वह है IO नियंत्रण कोड इंटरफ़ेस द्वारा उजागर memset और memmove फ़ंक्शन कॉल को पूरी तरह से नियंत्रित करने की क्षमता। पहले से उल्लिखित फ़ंक्शन DeviceIoControl को याद रखें, हम एक संरचना कैसे पास कर सकते हैं जिसका उपयोग कर्नेल रूटीन में किया जाएगा? इस तरह यह सब एक साथ आता है।