BlueKeep 漏洞利用分析
- 2019 年 10 月 5 日
- 筆記
作者：SungLin@知道創宇404實驗室 時間：2019年9月18日
原文鏈接：https://paper.seebug.org/1035/
0x00 信道的創建、連接與釋放
通道的數據包定義在MCS Connect Inittial PDU with GCC Conference Create Request中，在rdp連接過程如下圖所示：
信道創建數據包格式如下：
在MCS Connect Inittial中屬於Client Network Data數據段，MS_T120將會在連接一開始的時候通過函數termdd!_IcaRegisterVcBin創建一個虛擬通道id是0x1f大小為0x18的結構體，之後就調用termdd!IcaCreateChannel開始創建大小為0x8c的信道結構體之後將會與虛擬通道id是0x1f綁定，也就是這個結構體將會被我們利用
信道的定義欄位主要是名字加上配置，配置主要包括了優先順序等
在server對MCS Connect Inittial應答包，將會依次給出對應虛擬通道的id值：
在rdp內核中依次註冊的值對應應該是0、1、2、3, MS_T120信道將會通過我們發送的用戶虛擬id為3的值再一次綁定，首先通過termdd!_IcaFindVcBind找到了剛開始註冊的虛擬通道id是0x1f，如下所示：
但是在termdd!_IcaBindChannel時，卻將我們自定義的id值為3與信道結構體再一次綁定在一起了,此信道結構體就是MS_T120
同時我們自己的用戶id將內部綁定的0x1f給覆蓋了
我們往信道MS_T120發送數據主動釋放其分配的結構體，其傳入虛擬通道id值為3通過函數termdd!IcaFindChannel在channeltable中查找返回對應的信道結構體：
下圖為返回的MS_T120信道結構體，其中0xf77b4300為此信道可調用的函數指針數組：
在這個函數指針數組中主要存放了三個函數，其中對應了termdd!IcaCloseChannel、termdd!IcaReadChannel、termdd!IcaWriteChannel
我們傳入釋放MS_T120信道的數據如下，位元組大小為0x12，主要數據對應了0x02
之後將會進入nt! IofCompleteRequest函數，通過apc注入後，將會通過nt! IopCompleteRequest和nt!IopAbortRequest進行數據請求的響應，最終在termdd!IcaDispatch完成我們發送數據的的請求，_BYTE v2就是我們發送的數據，所以我們發送的數據0x02將會最終調用到IcaClose函數進入IcaCloseChannel函數，最後主動釋放掉了MS_T120信道結構體
0x01 通過RDPDR信道進行數據佔位
我們先來了解下rdpdr信道，首先rdpdr信道是文件系統虛擬通道擴展，該擴展在名為rdpdr的靜態虛擬通道上運行。目的是將訪問從伺服器重定向到客戶端文件系統，其數據頭部將會主要是兩種標識和PacketId欄位組成：
在這裡我們剛好利用到了rdpde客戶端name響應的數據來進行池記憶體的佔位
在完全建立連接後，將會創建rdpdr信道的結構體
在window7中，在建立完成後接收到server的rdpdr請求後，通過發送客戶端name響應數據，將會調用到termdd! IcaChannelInputInternal中的ExAllocatePoolWithTag分配非分頁池記憶體，並且其長度是我們可以控制的，基本滿足了UAF利用的需求：
可是在windowsxp中，直接發送client name request將會導致記憶體分配失敗，直接進入termdd! _IcaCopyDataToUserBuffer,並且在Tao Yan and Jin Chen[1]一文中也提到了通過發送client name request在觸發一定的條件後將會繞過termdd!_IcaCopyDataToUserBuffer而進入ExAllocatePoolWithTag分配我們想要的非分頁記憶體，而打破條件如下：
我們先來看看最開始信道結構體的創建，我們可以發現從一開始創建信道結構體的時候，將會出現兩個標誌，而這兩個標誌是按照地址順序排列的，而在上面需要打破的條件中，只要channelstruct +0x108的地址存放的是同一個地址，循環就會被break
我們發送一個正常的rdpdr的name request數據包，頭部標識是0x7244和0x4e43
經過termdd!_IcaCopyDataToUserBuffer之後，將會進入nt!IofCompleteRequest，在響應請求後進入rdpdr!DrSession::ReadCompletion,此函數處理邏輯如下，其將會遍歷一個鏈表，從鏈表中取出對應的vftable函數數組
遍歷第一次取出第一張函數數組
傳入我們發送的數據後，通過函數數組調用rdpdr!DrSession::RecognizePacket進行讀取
判斷頭部標誌是否為（RDPDR_CTYP_CORE）0x7244
接著將會讀取函數vftable第二個地址，進行轉發
如下圖可以看到rdpdr的數據包處理邏輯
rdpdr經過一系列數據包處理後最終進入了我們關心的地方，將會傳入channelstruct通過調用termdd! _IcaQueueReadChannelRequest進行標誌位的處理
最初rdpdr的channelstruct的標誌位如下
經過函數termdd! _IcaQueueReadChannelRequest對此標誌的處理後變成如下，所以下一個數據依然會進入termdd!_IcaCopyDataToUserBuffer，導致我們進行池噴射的失敗
回到rdpdr頭部處理函數rdpdr!DrSession::RecognizePacket，我們發現在鏈表遍歷失敗後將會進行跳轉，最後將會進入讀取失敗處理函數rdpdr!DrSession::ChannelIoFailed，然後直接return了
我們構造一個頭部異常的數據包發送，頭部標誌我們構造的是0x7240，將會導致rdpdr!DrSession::RecognizePacket判斷失敗，之後將會繼續遍歷鏈表依次再取出兩張函數數組
最後兩個函數數組依次調用rdpdr!DrExchangeManager::RecognizePacket和rdpdr!DrDeviceManager::RecognizePacket，都會判斷錯誤的頭部標誌0x7240，最後導致鏈表遍歷完後進行錯誤跳轉，直接繞過了termdd! _IcaQueueReadChannelRequest對標誌位的修改，將會打破循環
最後我們連續構造多個錯誤的數據包後將會進入ExAllocatePoolWithTag，分配到我們需要的非分頁記憶體！
0x02 win7 EXP 池噴射簡要分析
首先被釋放的MS_T120池大小包括是0x170,池的標誌是TSic
分析Win7 exp 可以知道數據佔位是用的rdpsnd信道，作者沒有採用rdpdr信道，應該也和噴射的穩定性有關，rdpsnd噴射是再建立完了rdpdr初始化後開始的，在free掉MS_T120結構體前，發送了1044個數據包去申請0x170大小的池記憶體，這樣做可以說應該是為了防止之後被free掉的記憶體被其他程式佔用了，提高free後記憶體被我們佔用的生存幾率
佔位被free的實際數據大小為0x128,利用的中轉地址是0xfffffa80ec000948
之後開始池噴射，將payload噴射到可以call [rax] == 0xfffffa80ec000948的地方，噴射的payload大小基本是0x400，總共噴射了200mb的數據大小，我們先來看下噴射前帶標誌TSic總共佔用池記憶體大小是58kib左右
噴射完後帶TSic標誌池記憶體大小大約就是201mb，池記憶體噴射基本是成功的，我的win7是sp1，總共記憶體大小是1GB，再噴射過程中也沒有其他干擾的，所以噴射很順利
圖中可以發現基本已經很穩定的0x400大小的池噴射payload，地址越高0x400大小的記憶體基本就很穩定了
最後斷開連接時候，被free的記憶體已經被我們噴射的0x128大小的數據給佔用了
執行call指令後穩定跳轉到了我們的payload，成功執行！
參考鏈接： [0] https://github.com/rapid7/metasploit-framework/pull/12283 [1] https://unit42.paloaltonetworks.com/exploitation-of-windows-cve-2019-0708-bluekeep-three-ways-to-write-data-into-the-kernel-with-rdp-pdu/ [2]https://wooyun.js.org/drops/%E7%BE%8A%E5%B9%B4%E5%86%85%E6%A0%B8%E5%A0%86%E9%A3%8E%E6%B0%B4%EF%BC%9A%20%E2%80%9CBig%20Kids%E2%80%99%20Pool%E2%80%9D%E4%B8%AD%E7%9A%84%E5%A0%86%E5%96%B7%E6%8A%80%E6%9C%AF.html
