
CVE-2024-6768 के लिए प्रूफ-ऑफ-कॉन्सेप्ट एक्सप्लॉइट, यह विंडोज CLFS.sys ड्राइवर में एक कमजोरी है जो निर्मित .BLF फ़ाइल के माध्यम से BSoD उत्पन्न करती है। इसमें स्रोत कोड और तकनीकी विश्लेषण शामिल है।
CVE-2024-6768 विंडोज के कॉमन लॉग फ़ाइल सिस्टम (CLFS.sys) ड्राइवर में एक भेद्यता है, जो इनपुट डेटा में निर्दिष्ट मात्राओं के अनुचित सत्यापन के कारण होती है। यह दोष एक अपुनर्प्राप्ति योग्य असंगति की ओर ले जाता है, जो KeBugCheckEx फ़ंक्शन को ट्रिगर करता है और ब्लू स्क्रीन ऑफ डेथ (BSoD) में परिणत होता है। यह समस्या विंडोज 10 और विंडोज 11, विंडोज सर्वर 2016, सर्वर 2019 और सर्वर 2022 के सभी संस्करणों को प्रभावित करती है, भले ही सभी अपडेट लागू किए गए हों। एक प्रूफ ऑफ कॉन्सेप्ट (PoC) दर्शाता है कि .BLF फ़ाइल के भीतर विशिष्ट मानों को तैयार करके, एक अविशेषाधिकार प्राप्त उपयोगकर्ता सिस्टम क्रैश को प्रेरित कर सकता है। संभावित समस्याओं में सिस्टम अस्थिरता और सेवा से इनकार शामिल हैं, क्योंकि दुर्भावनापूर्ण उपयोगकर्ता प्रभावित सिस्टम को बार-बार क्रैश करने, संचालन को बाधित करने और संभावित रूप से डेटा हानि का कारण बनने के लिए इस भेद्यता का शोषण कर सकते हैं।
कॉमन लॉग फ़ाइल सिस्टम (CLFS) पर पिछले दो शोध प्रयासों में, मैं दोनों मामलों में RCE प्राप्त करने में सक्षम था। (यदि आप रुचि रखते हैं तो यहां वह है जो मैंने CLFS CVE-2023-28252 और CLFS CVE-2022-37969 के लिए किया था)। हालांकि, जब मैंने PoC में कुछ मानों को संशोधित किया, जिस पर मैं काम कर रहा था, तो मैंने देखा कि इसने लक्ष्य प्रणाली पर BSoD ट्रिगर किया। परिणामस्वरूप, मैंने इस मुद्दे को रिपोर्ट करने का निर्णय लिया। यह दस्तावेज़ BSoD को समझने में मदद करता है और इसे पुन: उत्पन्न करने के तरीके पर मार्गदर्शन प्रदान करता है।
यह भेद्यता इनपुट में निर्दिष्ट मात्रा के अनुचित सत्यापन (CWE-1284) के कारण उत्पन्न होती है
जो CLFS.sys ड्राइवर में एक अपुनर्प्राप्ति योग्य असंगति का कारण बनती है, जो KeBugCheckEx फ़ंक्शन को कॉल करने के लिए मजबूर करती है, जो एक अविशेषाधिकार प्राप्त उपयोगकर्ता को विंडोज में BSoD उत्पन्न करने की अनुमति देती है। इस दस्तावेज़ में, मैं CLFS.sys संस्करण 10.0.19041.3324 को एक उदाहरण के रूप में उपयोग कर रहा हूं, लेकिन यह समस्या सभी अपडेट लागू होने के साथ विंडोज 10 और विंडोज 11 के नवीनतम संस्करण तक के सभी संस्करणों को प्रभावित कर रही है।
बेस स्कोर: CVSS 4.0: 6.8 मध्यम
वेक्टर स्ट्रिंग CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
अटैक वेक्टर (AV): स्थानीय
अटैक कॉम्प्लेक्सिटी (AC): कम
अटैक आवश्यकताएँ (AT): कोई नहीं
आवश्यक विशेषाधिकार (PR): कम
उपयोगकर्ता सहभागिता (UI): कोई नहीं
गोपनीयता (VC): कोई नहीं
अखंडता (VI): कोई नहीं
उपलब्धता (VA): उच्च
गोपनीयता (SC): कोई नहीं
अखंडता (SI): कोई नहीं
उपलब्धता (SA): कोई नहीं
सिस्टम द्वारा अपुनर्प्राप्ति योग्य स्थिति का पता लगाने के बाद, यह KeBugCheckEx फ़ंक्शन को कॉल करता है जो माइक्रोसॉफ्ट द्वारा इस लेख में वर्णित BSoD की ओर ले जाता है: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-kebugcheckex।

CClfsLogFcbPhysical::FlushLog+6F2 CLFS.sys संस्करण 10.0.19041.3324 में वह पता है जहां KeBugCheckEx का कॉल उत्पन्न होता है:
CClfsLogFcbPhysical::FlushLog+6D5
CClfsLogFcbPhysical::FlushLog+6D5 loc_FFFFF8062EED4F35: ; BugCheckParameter2
CClfsLogFcbPhysical::FlushLog+6D5 mov r8d, eax
CClfsLogFcbPhysical::FlushLog+6D8 and [rsp+0A8h+Timeout], 0
CClfsLogFcbPhysical::FlushLog+6DE mov r9, rbx ; BugCheckParameter3
CClfsLogFcbPhysical::FlushLog+6E1 mov edx, 3Ah ; ':' ; BugCheckParameter1
CClfsLogFcbPhysical::FlushLog+6E6 mov ecx, 0C1F5h ; BugCheckCode
CClfsLogFcbPhysical::FlushLog+6EB mov r10, cs:__imp_KeBugCheckEx
CClfsLogFcbPhysical::FlushLog+6F2 call near ptr nt_KeBugCheckEx
विश्लेषण शुरू करने के लिए, .BLF फ़ाइल स्वरूप को जानना आवश्यक है, जो फ़ोल्डर %windir%\system32 में स्थित कमजोर कॉमन लॉग फ़ाइल सिस्टम ड्राइवर CLFS.sys द्वारा संभाला जाता है। इसके बारे में अधिक जानने के लिए, इस लेख के अंत में संदर्भ अनुभाग देखें।
हमारे प्रूफ ऑफ कॉन्सेप्ट रिपॉजिटरी में, 54.blf फ़ाइल में ऑफसेट 0x1c10 पर एक तैयार मान (0xffffffff00ff01) है।

यह तैयार मान _CLFS_CLIENT_CONTEXT संरचना के ऑफसेट 0x38 में है, इसे CClfsLogFcbPhysical::Initialize में CClfsLogFcbPhysical संरचना के 0x538 ऑफसेट में कॉपी किया गया है।

नीचे नीले रंग से चिह्नित क्षेत्र cidNode = 0xC1FDF006 से शुरू होता है, यह CLFSHASHSYM संरचना है

उसके बाद cidNode == 0xC1FDF007 से शुरू होकर _CLFS_CLIENT_CONTEXT संरचना स्थित है
ऑफसेट 0x38 में फ़ील्ड lsnOwnerPage है जो तैयार मान 0xffffffff00ff01 से भरा जाएगा:
struct _CLFS_CLIENT_CONTEXT
{
CLFS_NODE_ID cidNode;
CLFS_CLIENT_ID cidClient;
USHORT fAttributes;
ULONG cbFlushThreshold;
ULONG cShadowSectors;
ULONGLONG cbUndoCommitment;
LARGE_INTEGER llCreateTime;
LARGE_INTEGER llAccessTime;
LARGE_INTEGER llWriteTime;
*CLFS_LSN **lsnOwnerPage; ***// ऑफसेट 0x38
CLFS_LSN lsnArchiveTail;
CLFS_LSN lsnBase;
CLFS_LSN lsnLast;
CLFS_LSN lsnRestart;
CLFS_LSN lsnPhysicalBase;
CLFS_LSN lsnUnused1;
CLFS_LSN lsnUnused2;
CLFS_LOG_STATE eState;
union
{
HANDLE hSecurityContext;
ULONGLONG ullAlignment;
};
};
जब PoC निष्पादित किया जाता है, तो यह lsnOwnerPage के मान को तैयार करता है, CreateLogFile को कॉल करता है और उल्लिखित मान का उपयोग UpdateCachedOwnerPage में किया जाता है जैसा कि नीचे कॉल स्टैक में देखा गया है:

यह वह पता है जहां PoC CreateLogFile को कॉल करता है और तैयार मान का उपयोग शुरू होता है:



AddLsnOffset के अंदर इस तैयार मान से गणना किया गया ulloffset लौटाता है:

लौटाया गया ulloffset 0xFFFFFFFF00000000 है

उसके बाद, इस मान की तुलना की जाती है और यह फ़ंक्शन CClfsLogFcbPhysical::UpdateCachedOwnerPage से बाहर निकलता है

उसके बाद, यह यूजर मोड में PoC पर लौटता है, और जब यह बाहर निकलता है तो यह CClfsLogFcbPhysical::FlushLog को कॉल करता है जब मूल तैयार ullofset का उपयोग किया जाता है

इसकी तुलना एक लूप में की जाती है और, यदि किसी भी चक्र में समान नहीं है, तो सिस्टम अपुनर्प्राप्ति योग्य स्थिति में होने के कारण, यह KeBugCheck को कॉल करता है जो स्वयं को पुनरारंभ करने के लिए BSoD उत्पन्न करता है:


आप कार्यात्मक PoC स्रोतों और तैयार BLF के साथ Fortra के GitHub पर पा सकते हैं।
मुझे आशा है कि आपको यह उपयोगी लगेगा। कृपया किसी भी प्रश्न के लिए [email protected] से संपर्क करें।
कॉमन लॉग फ़ाइल सिस्टम (CLFS) संदर्भ: