CVE-2021-43229 वॉकथ्रू

सार्वजनिक जानकारी

Windows NTFS विशेषाधिकार वृद्धि भेद्यता

से अलग:

• CVE-2021-43230
• CVE-2021-43231

पैच: 14 दिसंबर, 2021

Twitter पर @AravGarg3 के अनुसार, CVE-2021-43229 शोषण योग्य प्रतीत होता है और एक integer overflow से संबंधित है।

स्रोत: https://twitter.com/AravGarg3/status/1479447843458863104

Windows 10 संस्करण

पहला भाग - डिफिंग

BinDiff और IDA Pro का उपयोग करके, पैच डिफिंग परिणाम निम्नलिखित परिवर्तनों के साथ:

तीन उम्मीदवार शीर्ष पर आते हैं:

• NtfsRenameToPrivateDir
• TxfAllocateAndStoreNameForTxLogging
• TxfAllocateFullFilePathForChangeNotify

Microsoft के दिसंबर के सुरक्षा अद्यतन गाइड के अनुसार, चार CVE NTFS से संबंधित हैं:

• CVE-2021-43229: Windows NTFS विशेषाधिकार वृद्धि भेद्यता
• CVE-2021-43230: Windows NTFS विशेषाधिकार वृद्धि भेद्यता
• CVE-2021-43231: Windows NTFS विशेषाधिकार वृद्धि भेद्यता
• CVE-2021-43240: NTFS सेट शॉर्ट नेम विशेषाधिकार वृद्धि भेद्यता

CVE-2021-43240, NtSetShortNameInfo से संबंधित प्रतीत होता है।

NtfsRenameToPrivateDir, TxfAllocateAndStoreNameForTxLogging और TxfAllocateFullFilePathForChangeNotify में तीनों एक ही नई लंबाई जाँच है, और ये CVE-2021-43229, CVE-2021-43230 और CVE-2021-43231 से संबंधित प्रतीत होते हैं, जरूरी नहीं कि इसी क्रम में हों। वर्तमान में, यह जानना संभव नहीं है कि कौन सा कौन सा है, Microsoft इस जानकारी के बारे में थोड़ा कंजूस है।

विश्लेषण

तीनों CVEs में, आवंटन आकार की गणना (निर्देशिका पथ लंबाई + फ़ाइल नाम लंबाई) के दौरान एक integer overflow होता है, जिससे निर्देशिका पथ और फ़ाइल नाम के अगले दो memmove के साथ एक पूल-आधारित बफर अतिप्रवाह होता है।

दूसरा भाग - पथ

पहला प्रयास: NtfsRenameToPrivateDir

NtfsRenameToPrivateDir का पथ नीचे दिखाया गया है:

NtfsCommonSetInformation
       |__________________
       |                  |
       v                  v
NtfsSetLinkInfo   NtfsSetRenameInfo
       |__________________|
       |
       v
NtfsRemoveSupersededTarget
       |
       v
NtfsRenameToPrivateDir

सबसे पहले, NtfsCommonSetInformation को कॉल करने के लिए, बस NtSetInformationFile को कॉल करें। फिर, NtfsSetLinkInfo और NtfsSetRenameInfo के माध्यम से जाने के लिए, NtSetInformationFile में फ़ाइल सूचना वर्ग के रूप में क्रमशः FileLinkInformationEx और FileRenameInformationEx का उपयोग करें।

NtfsSetRenameInfo के माध्यम से NtfsRemoveSupersededTarget तक पहुँचने के लिए, FILE_RENAME_REPLACE_IF_EXISTS और FILE_RENAME_POSIX_SEMANTICS फ़्लैग सेट करना आवश्यक है। किसी मौजूदा फ़ाइल के नाम से किसी फ़ाइल का नाम बदलें ताकि NtfsRemoveSupersededTarget तक पहुँचा जा सके। NtfsRenameToPrivateDir के लिए, यह थोड़ा मुश्किल है, क्योंकि प्रतिस्थापित फ़ाइल को किसी भी प्रक्रिया द्वारा खोला जाना चाहिए।

दुर्भाग्य से, NtfsRemoveSupersededTarget को कॉल करने से पहले एक लंबाई जाँच की जाती है।

NtfsSetLinkInfo के साथ विधि NtfsSetRenameInfo के समान है, केवल फ़्लैग के नाम भिन्न हैं, उनके अर्थ अभी भी समान हैं। लेकिन NtfsSetRenameInfo की तरह ही, NtfsRemoveSupersededTarget को कॉल करने से पहले एक और जाँच की जाती है।

दूसरा प्रयास: TxfAllocateAndStoreNameForTxLogging

TxfAllocateAndStoreNameForTxLogging का पथ नीचे दिखाया गया है:

NtfsCommonCreate
      |
      v
NtfsCreateNewFile
      |
      v
TxfNewFileCreate
      |
      v
TxfAllocateAndStoreNameForTxfLogging

सबसे पहले, NtfsCommonCreate को कॉल करने के लिए, बस CreateFile को कॉल करें।

TxfNewFileCreate फ़ंक्शन का उपसर्ग Txf है जिसका अर्थ है "Transactional NTFS" और इसे तब कॉल किया जाता है जब एक लेन-देन फ़ाइल (transacted file) बनाई जाती है। TxfAllocateAndStoreNameForTxfLogging को प्रक्रिया के दौरान लेन-देन फ़ाइल का पथ संग्रहीत करने के लिए कॉल किया जाता है।

केवल दो कॉल आवश्यक हैं:

• CreateTransaction
• CreateFileTransacted

तीसरा भाग - PoC इसे

TxfAllocateAndStoreNameForTxLogging का भेद्य कोड नीचे दिखाया गया है:

...
and     di, 2
add     di, [rsi+UNICODE_STRING.Length]                      ; File name
add     di, [rsp+68h+RelativeNormalizedDirectoryPath.Length] ; OVERFLOW HERE
cmp     [rsp+68h+arg_20], r12b
jnz     loc_16592C

movzx   edx, di
add     rdx, size UNICODE_STRING ; NumberOfBytes
mov     ecx, cs:PoolType
or      ecx, 10h        ; PoolType
mov     r8d, 'afxT'     ; Tag
call    cs:__imp_ExAllocatePooliWthTag
...

अतिप्रवाह को ट्रिगर करने के लिए, एक अत्यधिक लंबाई वाली फ़ाइल बनाना आवश्यक है, 0xFFFF बाइट्स (32767 वर्ण) से अधिक।

एक समस्या यह दिखाई देती है कि फ़ाइल या निर्देशिका का नाम 256 वर्णों से अधिक नहीं हो सकता - NULL वर्ण सहित। इसे हल करने के लिए, गहरे उप-फ़ोल्डरों का उपयोग आवश्यक होगा। अजीब बात है, यह इतना आसान नहीं है, भले ही उप-फ़ोल्डर सफलतापूर्वक बनाए गए हों, उप-फ़ाइल नहीं बनाई जा सकती, निश्चित रूप से पहले की गई कुछ जाँचों के कारण।

explorer बार का उपयोग करके निर्देशिका पथ दिखाने के लिए उपयोग किए जाने वाले प्रारूप को देखना संभव है। यह वह नहीं है जिसकी मुझे उम्मीद थी, एक "क्लासिक" पथ का उपयोग करने के बजाय, explorer DOS के पुराने प्रारूप, 8.3 शॉर्ट फॉर्मेट का उपयोग करता है।

उप-फ़ोल्डर निर्माण को पहले की तरह रखते हुए और फ़ाइल निर्माण के दौरान उप-निर्देशिकाओं के लिए शॉर्ट नाम का उपयोग करना काम करता है।

यह ध्यान रखना महत्वपूर्ण है, अतिप्रवाहित आकार में 16 बाइट्स जोड़े जाएंगे, जो उस UNICODE_STRING का आकार है जो अंतिम पथ का प्रतिनिधित्व करेगा। ऐसा इसलिए है क्योंकि अनुरोधित मेमोरी में UNICODE_STRING और उसके बाद इस UNICODE_STRING का बफर होगा।

विधि:

• लंबे नाम वाले उप-निर्देशिकाएँ बनाएँ
• निर्देशिका पथ के लिए लंबे नाम और शॉर्ट नामों वाली फ़ाइल बनाएँ

वर्तमान स्थितियाँ:

• अतिप्रवाह 64KB के बराबर ओवरराइट करता है
• आवंटित मेमोरी का आकार 0x20C बाइट्स तक है
• आवंटित मेमोरी पेज्ड पूल में है

चौथा भाग - सुराग

SSTIC 2020 में Synacktiv का एक दिलचस्प राइट-अप, VS Heap को लक्षित करके खोजने का एक विचार हो सकता है।

CVE-2020-17087, शोषण का एक समान मामला, PixiePoint Security द्वारा ऊपर उल्लिखित तकनीक का उपयोग करके प्रस्तुत किया गया है।