怎么淺析CVE-2021-1647的漏洞利用技巧

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)怎么淺析CVE-2021-1647的漏洞利用技巧，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

概要

近期爆出的 CVE-2021-1647 是 Windows Defender MpEngine 模塊中的一處 rce 漏洞，下面旨在從漏洞利用層面對(duì)相關(guān)樣本所使用的技巧進(jìn)行分析，筆者使用的樣本哈希為：6e1e9fa0334d8f1f5d0e3a160ba65441f0656d1f1c99f8a9f1ae4b1b1bf7d788。

漏洞原理

Windows Defender 采用模擬執(zhí)行的策略，對(duì)可執(zhí)行文件進(jìn)行黑白判定，模擬執(zhí)行分為以下兩個(gè)層面：指令模擬和運(yùn)行環(huán)境模擬。指令模擬部分負(fù)責(zé)將相應(yīng)平臺(tái)指令（包括 arm/x86/x64 等）轉(zhuǎn)為中間指令（IL），然后通過(guò) jit/ 解釋執(zhí)行的方式運(yùn)行相應(yīng)的中間指令；運(yùn)行環(huán)境模擬則包括內(nèi)存系統(tǒng)模擬/文件系統(tǒng)模擬/api 模擬/DLL 模擬（與 MpEngine.dll 同目錄的 vdm 文件是 dll 模擬文件的壓縮集/合），在指令模擬執(zhí)行的過(guò)程中，碰到壓縮殼的情況，defender 也會(huì)模擬解壓過(guò)程（詳見 UnpackerContext::Unpack 函數(shù))，當(dāng)前 defender 支持的壓縮方式有：Upxw64/Upxw/WExtract/NSPacker/Shrinker/PECompact2/Area51/Crypter1337/Aspack/PKLite/SfxCab/Asprotect 等。本次漏洞出現(xiàn)在 Asprotect 模擬解壓過(guò)程中（CAsprotectDLLAndVersion::RetrieveVersionInfoAndCreateObjects 函數(shù)）：

上圖中，v2+28 代表一個(gè) section 數(shù)組的開始，該數(shù)組包含四個(gè)元素，每個(gè) section 元素 8 字節(jié)，前 4 字節(jié)用于描述該 section 的虛擬地址，后四個(gè)字節(jié)用于描述該 section 的大小，上圖描述的是這樣一個(gè)過(guò)程：遍歷一個(gè)包含 4 項(xiàng)的 section 數(shù)組，最后獲得一個(gè) sectionva 和 sectionsize，申請(qǐng)一片大小為 sectionva+sectionsize 的內(nèi)存用于存儲(chǔ)解壓后的 section 內(nèi)容，但其在計(jì)算 sectionva 和 sectionsize 時(shí)存在錯(cuò)誤，代碼中只考慮了 section[i+1].va>section[i].va 的情況，但并沒(méi)有考慮兩者相等的情況，倘若 section 數(shù)組中四個(gè)元素的值如下：[0,0]，[0,0]，[0x2000,0]，[0x2000,0x3000]，按照上述代碼的邏輯最終 sectionva=0x2000，sectionsize=0，那最終申請(qǐng)的內(nèi)存大小為 0x2000+0=0x2000，因此在解壓最后一個(gè) section 時(shí)，由于其大小為 0x3000，這樣便會(huì)產(chǎn)生堆溢出問(wèn)題，這便是本漏洞的產(chǎn)生根源。

利用技巧

1. 確定版本偏移

在樣本開頭處調(diào)用了如下函數(shù)：

在剛開始分析該樣本時(shí)，筆者以為該處地址是 defender 中某個(gè)未開啟 ASLR 模塊的地址或是類似于利用異常處理進(jìn)行反調(diào)試的措施，但其實(shí)這時(shí)筆者犯了一個(gè)巨大的錯(cuò)誤，要明確的一點(diǎn)是，當(dāng)樣本在被 defender 模擬執(zhí)行時(shí)，一切內(nèi)存地址并不是真實(shí)的 host 上的地址，而是 defender 模擬內(nèi)存空間中的一個(gè)地址，也就是說(shuō) 0x7c96c654 其實(shí)是 defender 模擬內(nèi)存空間中的一段地址，該地址其實(shí)對(duì)應(yīng)于模擬 dll 模塊 --ntdll.dll（模擬的 ntdll.dll 可以通過(guò)解壓與 mpengine.dll 同目錄的 mpasbase.vdm 獲得）中的一段代碼：

注意看函數(shù)最后兩個(gè)字節(jié)：0xf 0xff，這兩個(gè)字節(jié)說(shuō)明這是一個(gè) native api 調(diào)用，其后的四個(gè)字節(jié) 0x9E9EFDF0 是用于標(biāo)識(shí)最終 native api 函數(shù)的一個(gè) crc 校驗(yàn)碼，所謂的 native api 即是有 mpengine.dll 提供的一系列功能 api，最終該函數(shù)會(huì)由 mpengine!NTDLL_DLL_NtControlChannel 實(shí)現(xiàn)，也就是說(shuō)樣本中 call 7C96C654 其實(shí)最終是調(diào)用 mpengine!NTDLL_DLL_NtControlChannel 完成功能，該函數(shù)第一個(gè)參數(shù)代表功能號(hào)，樣本中的 3 代表的是獲取 defender 版本信息，樣本就是通過(guò)該函數(shù)獲取版本信息，然后根據(jù)不同的版本信息硬編碼關(guān)鍵偏移。

2. 內(nèi)存占位/修改關(guān)鍵字段

在樣本中包含了大量的 SuspendThread 和 ResumeThread 的調(diào)用代碼，這部分代碼其實(shí)是用來(lái)進(jìn)行內(nèi)存布局和占位的，在堆溢出發(fā)生后，會(huì)修改布局在堆內(nèi)存后的 lfind 對(duì)象，lfind 對(duì)象中的兩個(gè)關(guān)鍵字段分別被修改為 2f9b 和 2f9c（原始值為 107e 和 107f），這兩個(gè)字段在 lfind_switch::switch_in（在模擬執(zhí)行 ResumeThread 函數(shù)時(shí)會(huì)觸發(fā)該函數(shù)調(diào)用）函數(shù)中被引用：

上圖中的 v20 即是會(huì)被引用的 2f9b 和 2f9c，很明顯由于被修改之后的值比正常的大，這會(huì)造成一個(gè)越界寫的行為，上圖中的 *(v20+*(v16+144))|=3 是漏洞利用過(guò)程的關(guān)鍵，該部分代碼修改的是 vmmcontrol 中的一個(gè)關(guān)鍵字段，我們將在第三部分說(shuō)明這個(gè)字段的用途。

3. 獲取任意讀寫能力

在 defender 進(jìn)行內(nèi)存空間模擬的過(guò)程中涉及到這樣幾個(gè)比較重要的結(jié)構(gòu)：

該結(jié)構(gòu)用于維持模擬內(nèi)存地址和真實(shí)內(nèi)存地址之間的映射關(guān)系，該結(jié)構(gòu)在內(nèi)存中以數(shù)組的形式存在。

為了實(shí)現(xiàn)高效的地址轉(zhuǎn)換，defender 還引入了一個(gè)索引數(shù)組（每個(gè)索引用 2 字節(jié)存儲(chǔ)），該數(shù)組中存儲(chǔ)的是 EmuVaddrNode 結(jié)構(gòu)數(shù)組的索引，并且是按照 EmuPagenum 從小到大進(jìn)行排序的，也就是說(shuō)假設(shè)此時(shí) EmuVaddrNode 數(shù)組中包含三個(gè)元素，且三個(gè)元素的 EmuPageNum 字段內(nèi)容為 0x2000，0x1000，0x5000，那么正常情況下此時(shí)索引數(shù)組內(nèi)容為1，0，3（1、0、3 都代表 EmuVaddrNode 數(shù)組的索引），并且 EmuVaddrNode 數(shù)組和索引數(shù)組在真實(shí)內(nèi)存中的布局如下（假設(shè)從左到右代表地址從低到高）：

也就是說(shuō)，索引數(shù)組后頭就是 EmuVaddrNode 數(shù)組，EmuVaddrNode 數(shù)組緊跟著的是 Page，Page 代表的是 defender 申請(qǐng)的用于映射模擬內(nèi)存空間的真實(shí)內(nèi)存，即 EmuVaddrNode 中的 Vaddr 都是從 page 中切割出來(lái)的。

最后，我們回顧一下第二部分中提到的修改了 vmmcontrol 中的關(guān)鍵字段，這個(gè)關(guān)鍵字段描述的是索引數(shù)組一共有多少個(gè)元素。如果我們將該數(shù)值改的盡可能的大，使得索引數(shù)組的起始地址+索引數(shù)組數(shù)目*2>Page 地址，而 Page 中的內(nèi)容是我們可控的，我們通過(guò)讓 defender 模擬執(zhí)行 *p=value 的方式，就能在 Page 中布置我們想要的內(nèi)容。首先，我們?cè)?Page 中偽造索引數(shù)組，并且該索引遠(yuǎn)大于 EmuVaddrNode 數(shù)組的項(xiàng)數(shù)，那么當(dāng) defender 模擬執(zhí)行 *p=value 這類指令時(shí)，先是從我們?cè)?Page 中偽造的索引數(shù)組中取到一個(gè)偽造的索引（該索引遠(yuǎn)大于 EmuVaddrNode 數(shù)組的項(xiàng)數(shù)）；接著，我們?cè)?Page 中繼續(xù)偽造一個(gè) EmuVaddrNode 結(jié)構(gòu)，那么 defender 通過(guò)偽造的索引便會(huì)訪問(wèn)到我們?cè)?Page 中偽造的 EmuVaddrNode 結(jié)構(gòu)，這時(shí) EmuVaddrNode 結(jié)構(gòu)的 Vaddr 是我們可控的，那么我們便獲得了任意地址讀寫能力，“寫”通過(guò)讓 defender 模擬執(zhí)行 *p=value 來(lái)實(shí)現(xiàn)，“讀”通過(guò)讓 dfender 模擬執(zhí)行 value=*p 來(lái)實(shí)現(xiàn)。有瀏覽器或者內(nèi)核漏洞相關(guān)經(jīng)驗(yàn)的同事應(yīng)該很熟悉這種場(chǎng)景，通過(guò)修改長(zhǎng)度字段來(lái)偽造對(duì)象及其 pointer 字段最終獲得任意地址讀寫的能力。

4. 獲取代碼執(zhí)行能力

在 defender 中會(huì)將常用的代碼片段進(jìn)行 jit 處理，通常 jit 內(nèi)存中存放的是 prolog 和 epilog 片段，在取得任意地址讀寫能力后，樣本中先將通過(guò)硬編碼偏移獲取到了 jit 部分的真實(shí)地址，將某個(gè) EmuVaddrNode 的 vaddr 設(shè)置為 jit 的真實(shí)地址，并且利用模擬執(zhí)行 memcpy（EmuPageNum，shellcode, sizeof (shellocde)）向 jit 地址寫入了 shellcode，最終只要 jit 功能一使用便會(huì)執(zhí)行 shellcode。

檢測(cè)原理

由于樣本是在 defender 模擬執(zhí)行的過(guò)程中觸發(fā)的漏洞，那么，如果我們僅僅簡(jiǎn)單取樣本中的幾個(gè)特征字串作為匹配規(guī)則，顯然是十分容易被繞過(guò)的。筆者建議可以綜合以下幾方面信息作為特征：

1. asprotect 殼的特征

2. 上圖所示內(nèi)容是 MpEngine 中對(duì)解壓后的內(nèi)容做的一個(gè)校驗(yàn)，只有滿足條件才會(huì)觸發(fā)堆溢出操作，因此可以對(duì)類似于 ”*(memory)=0x8d; *(memory+1)=0x85;  *(memory+6)=0x50; *(memory+7)=0xc3” 的賦值操作進(jìn)行特征匹配。

3. 樣本通過(guò) NtControlChannel 獲得版本信息以確定偏移信息，因此可以把 NtControlChannel 函數(shù)的調(diào)用特征作為匹配依據(jù)。

4. 樣本中其他為了實(shí)現(xiàn)穩(wěn)定的內(nèi)存布局而進(jìn)行的模擬調(diào)用的特征。

上述就是小編為大家分享的怎么淺析CVE-2021-1647的漏洞利用技巧了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。