如何進(jìn)行BlueKeep漏洞利用分析

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

0x00 信道的創(chuàng)建、連接與釋放

通道的數(shù)據(jù)包定義在MCS Connect Inittial PDU with GCC Conference Create Request中，在rdp連接過(guò)程如下圖所示：

信道創(chuàng)建數(shù)據(jù)包格式如下：

在MCS Connect Inittial中屬于Client Network Data數(shù)據(jù)段，MS_T120將會(huì)在連接一開始的時(shí)候通過(guò)函數(shù)termdd!_IcaRegisterVcBin創(chuàng)建一個(gè)虛擬通道id是0x1f大小為0x18的結(jié)構(gòu)體，之后就調(diào)用termdd!IcaCreateChannel開始創(chuàng)建大小為0x8c的信道結(jié)構(gòu)體之后將會(huì)與虛擬通道id是0x1f綁定，也就是這個(gè)結(jié)構(gòu)體將會(huì)被我們利用

信道的定義字段主要是名字加上配置，配置主要包括了優(yōu)先級(jí)等

在server對(duì)MCS Connect Inittial應(yīng)答包，將會(huì)依次給出對(duì)應(yīng)虛擬通道的id值：

在rdp內(nèi)核中依次注冊(cè)的值對(duì)應(yīng)應(yīng)該是0、1、2、3, MS_T120信道將會(huì)通過(guò)我們發(fā)送的用戶虛擬id為3的值再一次綁定，首先通過(guò)termdd!_IcaFindVcBind找到了剛開始注冊(cè)的虛擬通道id是0x1f，如下所示：

但是在termdd!_IcaBindChannel時(shí)，卻將我們自定義的id值為3與信道結(jié)構(gòu)體再一次綁定在一起了,此信道結(jié)構(gòu)體就是MS_T120

同時(shí)我們自己的用戶id將內(nèi)部綁定的0x1f給覆蓋了

我們往信道MS_T120發(fā)送數(shù)據(jù)主動(dòng)釋放其分配的結(jié)構(gòu)體，其傳入虛擬通道id值為3通過(guò)函數(shù)termdd!IcaFindChannel在channeltable中查找返回對(duì)應(yīng)的信道結(jié)構(gòu)體：

下圖為返回的MS_T120信道結(jié)構(gòu)體，其中0xf77b4300為此信道可調(diào)用的函數(shù)指針數(shù)組：

在這個(gè)函數(shù)指針數(shù)組中主要存放了三個(gè)函數(shù)，其中對(duì)應(yīng)了termdd!IcaCloseChannel、termdd!IcaReadChannel、termdd!IcaWriteChannel

我們傳入釋放MS_T120信道的數(shù)據(jù)如下，字節(jié)大小為0x12，主要數(shù)據(jù)對(duì)應(yīng)了0x02

之后將會(huì)進(jìn)入nt! IofCompleteRequest函數(shù)，通過(guò)apc注入后，將會(huì)通過(guò)nt! IopCompleteRequest和nt!IopAbortRequest進(jìn)行數(shù)據(jù)請(qǐng)求的響應(yīng)，最終在termdd!IcaDispatch完成我們發(fā)送數(shù)據(jù)的的請(qǐng)求，_BYTE v2就是我們發(fā)送的數(shù)據(jù)，所以我們發(fā)送的數(shù)據(jù)0x02將會(huì)最終調(diào)用到IcaClose函數(shù)進(jìn)入IcaCloseChannel函數(shù)，最后主動(dòng)釋放掉了MS_T120信道結(jié)構(gòu)體

0x01 通過(guò)RDPDR信道進(jìn)行數(shù)據(jù)占位

我們先來(lái)了解下rdpdr信道，首先rdpdr信道是文件系統(tǒng)虛擬通道擴(kuò)展，該擴(kuò)展在名為rdpdr的靜態(tài)虛擬通道上運(yùn)行。目的是將訪問(wèn)從服務(wù)器重定向到客戶端文件系統(tǒng)，其數(shù)據(jù)頭部將會(huì)主要是兩種標(biāo)識(shí)和PacketId字段組成：

在這里我們剛好利用到了rdpde客戶端name響應(yīng)的數(shù)據(jù)來(lái)進(jìn)行池內(nèi)存的占位

在完全建立連接后，將會(huì)創(chuàng)建rdpdr信道的結(jié)構(gòu)體

在window7中，在建立完成后接收到server的rdpdr請(qǐng)求后，通過(guò)發(fā)送客戶端name響應(yīng)數(shù)據(jù)，將會(huì)調(diào)用到termdd! IcaChannelInputInternal中的ExAllocatePoolWithTag分配非分頁(yè)池內(nèi)存，并且其長(zhǎng)度是我們可以控制的，基本滿足了UAF利用的需求：

可是在windowsxp中，直接發(fā)送client name request將會(huì)導(dǎo)致內(nèi)存分配失敗，直接進(jìn)入termdd! _IcaCopyDataToUserBuffer,并且在Tao Yan and Jin Chen[1]一文中也提到了通過(guò)發(fā)送client name request在觸發(fā)一定的條件后將會(huì)繞過(guò)termdd!_IcaCopyDataToUserBuffer而進(jìn)入ExAllocatePoolWithTag分配我們想要的非分頁(yè)內(nèi)存，而打破條件如下：

我們先來(lái)看看最開始信道結(jié)構(gòu)體的創(chuàng)建，我們可以發(fā)現(xiàn)從一開始創(chuàng)建信道結(jié)構(gòu)體的時(shí)候，將會(huì)出現(xiàn)兩個(gè)標(biāo)志，而這兩個(gè)標(biāo)志是按照地址順序排列的，而在上面需要打破的條件中，只要channelstruct +0x108的地址存放的是同一個(gè)地址，循環(huán)就會(huì)被break

我們發(fā)送一個(gè)正常的rdpdr的name request數(shù)據(jù)包，頭部標(biāo)識(shí)是0x7244和0x4e43

經(jīng)過(guò)termdd!_IcaCopyDataToUserBuffer之后，將會(huì)進(jìn)入nt!IofCompleteRequest，在響應(yīng)請(qǐng)求后進(jìn)入rdpdr!DrSession::ReadCompletion,此函數(shù)處理邏輯如下，其將會(huì)遍歷一個(gè)鏈表，從鏈表中取出對(duì)應(yīng)的vftable函數(shù)數(shù)組

遍歷第一次取出第一張函數(shù)數(shù)組

傳入我們發(fā)送的數(shù)據(jù)后，通過(guò)函數(shù)數(shù)組調(diào)用rdpdr!DrSession::RecognizePacket進(jìn)行讀取

判斷頭部標(biāo)志是否為（RDPDR_CTYP_CORE）0x7244

接著將會(huì)讀取函數(shù)vftable第二個(gè)地址，進(jìn)行轉(zhuǎn)發(fā)

如下圖可以看到rdpdr的數(shù)據(jù)包處理邏輯

rdpdr經(jīng)過(guò)一系列數(shù)據(jù)包處理后最終進(jìn)入了我們關(guān)心的地方，將會(huì)傳入channelstruct通過(guò)調(diào)用termdd! _IcaQueueReadChannelRequest進(jìn)行標(biāo)志位的處理

最初rdpdr的channelstruct的標(biāo)志位如下

經(jīng)過(guò)函數(shù)termdd! _IcaQueueReadChannelRequest對(duì)此標(biāo)志的處理后變成如下，所以下一個(gè)數(shù)據(jù)依然會(huì)進(jìn)入termdd!_IcaCopyDataToUserBuffer，導(dǎo)致我們進(jìn)行池噴射的失敗

回到rdpdr頭部處理函數(shù)rdpdr!DrSession::RecognizePacket，我們發(fā)現(xiàn)在鏈表遍歷失敗后將會(huì)進(jìn)行跳轉(zhuǎn)，最后將會(huì)進(jìn)入讀取失敗處理函數(shù)rdpdr!DrSession::ChannelIoFailed，然后直接return了

我們構(gòu)造一個(gè)頭部異常的數(shù)據(jù)包發(fā)送，頭部標(biāo)志我們構(gòu)造的是0x7240，將會(huì)導(dǎo)致rdpdr!DrSession::RecognizePacket判斷失敗，之后將會(huì)繼續(xù)遍歷鏈表依次再取出兩張函數(shù)數(shù)組

最后兩個(gè)函數(shù)數(shù)組依次調(diào)用rdpdr!DrExchangeManager::RecognizePacket和rdpdr!DrDeviceManager::RecognizePacket，都會(huì)判斷錯(cuò)誤的頭部標(biāo)志0x7240，最后導(dǎo)致鏈表遍歷完后進(jìn)行錯(cuò)誤跳轉(zhuǎn)，直接繞過(guò)了termdd! _IcaQueueReadChannelRequest對(duì)標(biāo)志位的修改，將會(huì)打破循環(huán)

最后我們連續(xù)構(gòu)造多個(gè)錯(cuò)誤的數(shù)據(jù)包后將會(huì)進(jìn)入ExAllocatePoolWithTag，分配到我們需要的非分頁(yè)內(nèi)存！

0x02 win7 EXP 池噴射簡(jiǎn)要分析

首先被釋放的MS_T120池大小包括是0x170,池的標(biāo)志是TSic

分析Win7 exp 可以知道數(shù)據(jù)占位是用的rdpsnd信道，作者沒(méi)有采用rdpdr信道，應(yīng)該也和噴射的穩(wěn)定性有關(guān)，rdpsnd噴射是再建立完了rdpdr初始化后開始的，在free掉MS_T120結(jié)構(gòu)體前，發(fā)送了1044個(gè)數(shù)據(jù)包去申請(qǐng)0x170大小的池內(nèi)存，這樣做可以說(shuō)應(yīng)該是為了防止之后被free掉的內(nèi)存被其他程序占用了，提高free后內(nèi)存被我們占用的生存幾率

占位被free的實(shí)際數(shù)據(jù)大小為0x128,利用的中轉(zhuǎn)地址是0xfffffa80ec000948

之后開始池噴射，將payload噴射到可以call [rax] == 0xfffffa80ec000948的地方，噴射的payload大小基本是0x400，總共噴射了200mb的數(shù)據(jù)大小，我們先來(lái)看下噴射前帶標(biāo)志TSic總共占用池內(nèi)存大小是58kib左右

噴射完后帶TSic標(biāo)志池內(nèi)存大小大約就是201mb，池內(nèi)存噴射基本是成功的，我的win7是sp1，總共內(nèi)存大小是1GB，再噴射過(guò)程中也沒(méi)有其他干擾的，所以噴射很順利

圖中可以發(fā)現(xiàn)基本已經(jīng)很穩(wěn)定的0x400大小的池噴射payload，地址越高0x400大小的內(nèi)存基本就很穩(wěn)定了

最后斷開連接時(shí)候，被free的內(nèi)存已經(jīng)被我們噴射的0x128大小的數(shù)據(jù)給占用了

執(zhí)行call指令后穩(wěn)定跳轉(zhuǎn)到了我們的payload，成功執(zhí)行！

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