Windows DWM कोर लाइब्रेरी विशेषाधिकार वृद्धि भेद्यता (CVE-2024-30051) (15 अगस्त, 2024 को प्रकाशित)

इस ब्लॉग पोस्ट में, मैं Microsoft Windows DWM कोर लाइब्रेरी में एक भेद्यता के बारे में बताऊंगा जिसका मैंने विश्लेषण तब किया जब Core Impact के लिए एक्सप्लॉइट विकसित किया जा रहा था। यह एक अन-प्रिविलेज्ड हमलावर को इंटीग्रिटी सिस्टम विशेषाधिकारों के साथ DWM उपयोगकर्ता के रूप में कोड निष्पादित करने की अनुमति देता है (CVE-2024-30051)।

चूँकि उस समय एक्सप्लॉइट विकसित करने के लिए पर्याप्त सार्वजनिक जानकारी नहीं थी, मुझे बहुत अधिक रिवर्स करना पड़ा, इसलिए यहाँ मैं दिखाऊंगा कि IDA PRO का उपयोग करके Windows 23H2 के लिए KB5037771 पैच को कैसे रिवर्स किया जाए। मैं dwmcore.dll संस्करण 10.0.22621.3447 और संस्करण 10.0.22621.3593 के बीच बाइनरी डिफिंग करने के लिए BINDIFF का उपयोग करूंगा, दिखाऊंगा कि हीप ओवरफ्लो कैसे उत्पन्न होता है, और फिर विशेषाधिकारों को बढ़ाकर इसका शोषण करूंगा, अंत में एक कार्यशील PoC बनाऊंगा।

अनुक्रमणिका:

[Windows DWM कोर लाइब्रेरी विशेषाधिकार वृद्धि भेद्यता (CVE-2024-30051) 1](#windows-dwm-core-library-elevation-of-privilege-vulnerability-cve-2024-30051)

[भेद्यता विवरण: 2](#vulnerability-details)

[बग खोजने के लिए डिफिंग: 3](#diffing-to-find-the-bug)

[CVE-2024-30051 का शोषण करने वाले PoC का विश्लेषण: 8](#analysis-of-the-poc-exploiting-cve-2024-30051)

[1)प्रारंभिकरण 8](#initialization)

[2)हुकिंग 8](#hooking)

[3)विंडो बनाना 16](#creating-the-window)

[4)डिवाइस बनाएं 16](#create-device)

[5) फैक्ट्री बनाएं 22](#create-factory)

[6) डिवाइस कॉन्टेक्स्ट बनाएं 28](#create-a-device-context)

[7) कंपोज़िशन डिवाइस बनाएं 29](#create-a-composition-device)

[8) hook3 फ़ंक्शन को कॉल करना 31](#calling-dcompositioncreatedevice-function)

[9) HWND के लिए टार्गेट बनाना 32](#creating-a-target-for-handle-hwnd)

[10)सतह बनाना 33](#creating-surface)

[11)BeginDraw, EndDraw, और CreateVisual को कॉल करना 34](#calling-begindraw-enddraw-and-createvisual)

[11)Visual SetContent को कॉल करना 36](#calling-visual-setcontent)

[12)ऑब्जेक्ट रिलीज़ करें 38](#release-objects)

[13)कंपोज़िशन डिवाइस को कमिट करें 38](#commit-composition-device)

[14)hook2 को कॉल करना 39](#calling-hook2)

[15)hook को कॉल करना 39](#remember-that-the-vulnerable-function-can-be-reached-using-some-methods-of-the-cprimitivegroup-class.-at-this-point-it-creates-a-heap-then-hook2-captures-and-saves-the-corresponding-heaphandle.)

[16)hook4 को कॉल करना 41](#calling-the-function-hook4)

[17)हीप स्प्रे करना 49](#performing-heap-spray)

[18)भेजने से पहले बेस चंक को संशोधित करना 51](#modifying-the-base-chunk-before-send)

[19)DWM प्रक्रिया को डीबग करना 52](#debugging-the-dwm-process)

[20)इंटीग्रिटी सिस्टम स्तर तक विशेषाधिकार बढ़ाना 62](#elevating-privileges-to-integrity-system-level)

भेद्यता विवरण:

Windows DWM कोर लाइब्रेरी विशेषाधिकार वृद्धि भेद्यता CVE-2024-30051

जारी: 14 मई, 2024

CNA निर्दिष्ट करना: Microsoft CVE-2024-30051

प्रभाव: विशेषाधिकार वृद्धि

अधिकतम गंभीरता: महत्वपूर्ण

कमजोरी:

CWE-122: हीप-आधारित बफर ओवरफ्लो

CVSS: 3.1 7.8 / 7.2

यह भेद्यता dwmcore.dll नामक मुख्य Windows DWM लाइब्रेरी में पूर्णांक विभाजन के भीतर आकार की गणना में त्रुटि के कारण मौजूद है। एक स्थानीय उपयोगकर्ता dwmcore.dll में CCommandBuffer::Initialize विधि में हीप पर बफर ओवरफ्लो उत्पन्न कर सकता है और इंटीग्रिटी सिस्टम विशेषाधिकारों के साथ DWM उपयोगकर्ता के रूप में मनमाना कोड निष्पादित कर सकता है। एक्सप्लॉइट मेमोरी तैयार करने के लिए DWM प्रक्रिया में हीप स्प्रे करेगा और अंततः dwmcore.dll में एक हीप ओवरफ्लो उत्पन्न करेगा, जो हीप स्प्रे के कुछ हिस्सों को रिलीज़ करने पर ट्रिगर होगा।

एक्सप्लॉइट सफल होने के बाद, DWM प्रक्रिया हमारे तैयार किए गए DLL को लोड करेगी जो हमारे कोड या हमारे निष्पादन योग्य (हमारे मामले में एक CMD) को DWM उपयोगकर्ता के रूप में निष्पादित करेगा, जिसके पास इंटीग्रिटी सिस्टम विशेषाधिकार हैं।

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

बग खोजने के लिए डिफिंग:

Windows 11 23H2 के लिए पैच यहाँ से डाउनलोड किया जा सकता है:

https://www.catalog.update.microsoft.com/Search.aspx?q=KB5037771

windows11.0-kb5037771-x64_19a3f100fb8437d059d7ee2b879fe8e48a1bae42.msu

dwmcore.dll का कमजोर संस्करण है: 10.0.22621.3447

dwmcore.dll का पैच किया गया संस्करण है: 10.0.22621.3593

परिवर्तित फ़ंक्शनों का विश्लेषण करने पर, यह स्पष्ट है कि CCommandBuffer::Initialize के पैच किए गए संस्करण में कई ब्लॉक जोड़े गए हैं, जिससे यह अपैच किए गए संस्करण से काफी अलग दिखता है।

उस फ़ंक्शन को स्थैतिक रूप से रिवर्स करने के बाद, CD2DSharedBuffer::GetBufferSize के दो कॉल हैं।

पहला कॉल new में आवंटित करने के लिए size प्राप्त करता है और दूसरा कॉल memcpy के लिए समान आकार प्राप्त करता है।

शुरुआत में सब कुछ सही लगता है। हालाँकि, आवंटन से पहले, यह आकार के साथ कुछ ऑपरेशन करता है।

यह समान CD2DSharedBuffer::GetBufferSize फ़ंक्शन को कॉल करके buffer_size और buffer_size2 प्राप्त करता है, दोनों समान मान लौटाते हैं। लेकिन new में यह एक पूर्व-ऑपरेशन करता है, buffer_size का 0x90 से पूर्णांक विभाजन और फिर 0x90 से गुणा, जबकि memcpy में यह लौटाए गए buffer_size2 का उपयोग बिना उस पर ऑपरेशन किए करता है।

इन ऑपरेशनों के साथ, मैंने पाया कि new और memcpy में अंततः उपयोग किया गया आकार भिन्न हो सकता है।

buffer_size = buffer_size2 (लौटाए गए आकार)

size_new= buffer_size/0x90 x 0x90

size_memcpy=buffer_size2

उदाहरण के लिए, यदि buffer_size 0x91 है

buffer_size = buffer_size2=0x91

size_new= buffer_size/0x90 x 0x90 =0x90

size_memcpy= buffer_size2= 0x91

यह उदाहरण साबित करता है कि एक हीप ओवरफ्लो है। यह आवंटित बाइट्स से अधिक बाइट्स कॉपी कर रहा है, और आकार नियंत्रणीय है।

उदाहरण के लिए, यदि buffer_size 0x23f है जैसा कि POC में उपयोग किया गया है।

buffer_size = buffer_size2=0x23F

size_new= buffer_size/0x90 x 0x90 =0x1b0

size_memcpy== buffer_size2=0x23f