Microsoft Windows被在野利用的提權漏洞的分析報告是怎樣的

今天就跟大家聊聊有關Microsoft Windows被在野利用的提權漏洞的分析報告是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

背景

2021年03月10日，奇安信威脅情報中心監測發現CVE-2021-1732漏洞利用細節及POC已經被公開，故發布該漏洞分析報告。

2021年2月，微軟在例行補丁日中修復了一枚在野的Windows 內核提權漏洞：CVE-2021-1732。與此同時，奇安信紅雨滴團隊在高級威脅狩獵中通過自研的紅雨滴沙箱也自動捕獲到該在野攻擊樣本，樣本在紅雨滴云沙箱上通過選擇Windows 10 x64分析環境進行檢測，可以準確識別到樣本在運行過程中進行了提權攻擊，從而最終進入了我們的分析視野。

https://sandbox.ti.qianxin.com/sandbox/page

漏洞分析

捕獲到的攻擊樣本包含以下的編譯pdb

C:\Users\Win10\source\repos\KSP_EPL\x64\Release\ConsoleApplication13.pdb

在win10 1909上運行之后可以看到提權程序被提升到system權限，這里需要注意該程序直接運行完畢后就退出了，因此需要通過調試器附加運行才能看到具體的提權效果。

該漏洞由CreateWindowExW函數產生，CreateWindowExW函數最終會調用到在win32kfull.sys中xxxCreateWindowEx函數，當通過該函數創建一個帶擴展內存的窗口時，xxxCreateWindowEx會調用xxxClientAllocWindowClassExtraBytes以分配對應的擴展內存，并將返回值保存到poi(tagWND+0x28)+0x128的位置，而這里poi(tagWND+0x28)+0x128實際是保存了對應窗口的擴展內存的位置，但是這個位置的值有兩種情況，內存指針或該內存的內核offset，而具體為哪一種方式則依賴于(tagWND+0x28)+0xE8的位置來確定，默認情況下為內存指針。

而xxxClientAllocWindowClassExtraBytes實際分配內存的操作是通過KeUserModeCallback函數進行的內核回調生成的。

KeUserModeCallback函數的參數原型如下所示，其中比較重要的是第一個ApiNumber，該參數指定了返回到應用層時對應的回調函數在KernelCallbackTable中的序號，并通過該序號獲取對應的回調函數的地址，之后的兩組參數分別為對應的回調調用的輸入參數/參數長度，及回調返回時的輸出參數/參數長度。

KeUserModeCallback最終返回到應用層的KiUserCallbackDispatcher，該函數通過PEB獲取KernelCallbackTable，這個表中記錄了一系列內核返回應用層的回調函數，通過KeUserModeCallback傳遞的第一個參數ApiNumber尋址到目標回調函數，回調調用完畢后通過int2B 觸發KiCallbackReturn返回內核。

KernelCallbackTable這張表的位置默認會保存在當前的peb中，KiUserCallbackDispatcher就是通過PEB獲取該表的地址，這里需要注意這張表實際是在use32.dll中，如果當前進程沒有加載該dll，peb中對應的KernelCallbackTable位置則是null，因此exp中有專門引入use32.dll的操作。

如下所示為KiUserCallbackDispatcher的一個偽代碼，通過peb獲取對應的回調并調用后，通過函數NtCallbackReturn返回內核。

NtCallbackReturn的原型如下，其第一個參數中保存了返回的數據，最終會賦值給KeUserModeCallback的outputstring。

由于這里KernelCallbackTable的位置保存在PEB中，因此可以通過代碼的方式獲取到該表的地址，并對表中的回調函數的地址進行替換，從而hook任意的內核到應用層的回調函數，這里如果在hook的回調函數中調用函數NtUserConsoleControl，并傳入對應的創建的窗口的句柄，將會導致對應窗口的擴展內存被設置為分配內存的offset，且對應的flag標記被設置，如下所示，NtUserConsoleControl 最終在win32kfull中會調用xxxConsoleControl。

xxxConsoleControl中如下所示可以看到poi(tagWND +0x28)+0x128處最終被設置為到DesktopAlloc分配的內存空間的offset，同時對應poi(tagWND+0x28)+0xE8處的flag標記被設置為offset尋址。

而這里如果我們在回調hook函數中手動調用NtCallbackReturn，由于漏洞將可以再次設置該窗口的擴展內存，由于之前NtUserConsoleControl已經將該窗口的flag設置為offset，因此這里實際上通過NtCallbackReturn二次設置該offset為任意攻擊者指定的地址。

因此該漏洞的實質就是，在創建一個帶擴展內存的窗口時，內核中xxxClientAllocWindowClassExtraBytes的應用層回調對來自應用層返回的數據校驗不嚴導致，通過hook xxxClientAllocWindowClassExtraBytes，并在hook函數中調用NtUserConsoleControl/NtCallbackReturn可以將目標窗口的poi(tagWND+0x28)+0x128位置設置為任意offset，從而導致越界寫入。

漏洞利用原理分析

具體的利用主函數如下所示，實際的利用代碼在函數fun_Eprivlcore中。

fun_Eprivlcore中首先遍歷系統進程，以確認是否有卡巴斯基的殺軟安裝。

之后判斷運行環境是否為64位系統，該代碼目前只支持64位系統，并初始化一系列偏移常量。

依次動態獲取/RtlGetNtVerisonNumbers/NtUserConsoleControl/NtCallbackReturn函數的地址

通過函數RtlGetNtVerisonNumbers判斷具體的win10系統版本，這里會判斷具體的win10版本是否大于1709，其支持的目標涉及1709-1909，當系統版本大于1903，則會修改其中部分偏移常量的數值，并進入到fun_EOP中進行具體的提權操作。

fun_EOP中調用函數fun_Init/fun_Inithwnd完成前期的初始化工作

fun_Init中首先通過IsMenu函數搜索未導出的函數pHmValidateHandle，該函數可用于獲取一個應用層窗口句柄對應的內核句柄對象在應用層的內存映射。

之后通過PEB獲取kernelCallbackTable，并修改該表中xxxClientAllocWindowClassExtraBytes函數的地址，將其指向fun_HOOKClientAllocWindowClassExtraBytes，完成對應xxxClientAllocWindowClassExtraBytes函數的hook

之后創建兩個窗口類normalClass/magicClass，注意這里magicClass窗口類在申明的時候對應cbWndExtra擴展內存字段的大小設置為var_magicClasscbWndExtra，該值是一個隨機生成的長度，而normalClass的cbWndExtra則設置為32，通過var_magicClasscbWndExtra就可以在hook函數中判斷具體的回調是來自于哪一個窗口的內核回調

而這里normalClass用于生成輔助的利用窗口

而magicClass則是具體觸發漏洞的窗口。

fun_Inithwnd中通過normalClass創建10個窗口0-9，并將10個窗口句柄保存在hWnd這個數組中，同時調用var_pHmValidateHandle獲取這10個窗口句柄對應的內核窗口對象在應用層的映射，并保存到v23這個數組中。

之后通過LocalAlloc分配內存，并構造對應的fakespmenu，fakespmenu會在之后用于實現任意地址讀的功能。

構造出的fakespmenu相關內存結構如下所示，最終的目標讀取地址會寫入到var_OffsetrcBarleft

依次獲取第0和第1個應用層的窗口句柄，及對應的內核窗口對象的應用層映射地址，并通過映射地址獲取該內核對象在內核地址中的偏移（位置在內核對象偏移0x8的位置保存），之后依次將2-0個窗口對象通過函數DestroyWindow釋放，并通過函數var_NtUserConsoleControl將第0個窗口對象的擴展內存尋址設置為offset類型。

如下所示r14和rsi中依次保存了0，1的窗口對象的應用層映射內存，其偏移0x8的位置為對應的內核對象在內核地址中的偏移。

通過magicClass類創建窗口，這里簡稱為窗口2，由于magicClass窗口類中對應的cbwndExtra字段和hook函數中的一致，因此窗口2創建的過程中會觸發漏洞函數xxxClientAllocWindowClassExtraBytes并最終通過內核回調進入到我們設置的hook函數中。

內核中函數xxxClientAllocWindowClassExtraBytes調用前，可以看到此時窗口2對應的cbwndExtra為12a5。

win10中tagWND對象的符號已經被刪除，其內容也發生了相當的變化，以下為通過分析之后還原出的tagWND的重要結構，上圖中的ffffff0681244870即為對應的pwnd，位于tagWND偏移0x28，其中比較重要的是

0x98 spmenu          窗口對應的menu菜單對象

0xc8 cbwndExtra       窗口對應擴展內存的大小

0xe8 Extra flag        窗口對象擴展內存的尋址標記，支持指針尋址，和偏移尋址，默認為指針尋址

0x128 pExtraBytes     保存擴展內存對應的位置，根據Extra flag為指針或offset偏移

tagWND偏移0x18+0x80的位置為對應的內核基地址，配合上對應的內核偏移就可以計算出對應的tagWND對象pwnd在內核中的偏移。

具體的hook函數如下，由于窗口2在創建時使用的是maginClass類，其對應的cbWndExtra符合hook函數中的過濾條件，因此觸發對應的var_xxxClientAllocWindowClassExtraByteshook，進入具體的hook流程中，hook中通過函數fun_FindcurrenHwnd獲取到當前窗口的hwnd，并以此調用NtUserConsoleControl，將其對應內核對象poi(tagWND2+0x28)+0xE8的處flag標記設置為offset類型尋址，之后將var_normalClassoffset0作為var_NtCallbackReturn參數返回，這將導致var_normalClassoffset0寫入到窗口2poi(tagWND2+0x28)+0x128處，此時通過對var_magicClasshwnd2調用SetWindowLongW（該函數用來改變指定窗口的屬性，函數也將指定的一個32位值設置在窗口的擴展內存空間的指定偏移位置）來修改擴展空間內存內容時，實際上修改的是var_normalClasshwnd0句柄對應內核對象pwnd的內容。

NtUserConsoleControl對應的內核函數為xxxConsoleControl，如下所示會設置pwnd偏移0xE8處的擴展內存尋址flag為offset類型，并初始化對應的擴展內存pExtraBytes為對應內存的內核偏移。

xxxConsoleControl調用之后的2窗口如下所示，注意此時的pExtraBytes還沒有被設置指向0窗口內核對象的pwnd內核偏移。

直到內核回調返回之后2窗口內核對象的pwnd.pExtraBytes字段此時才被設置為0窗口內核對象的pwnd的內核偏移，之后通過xxxSetWindowLong設置窗口2的擴展內存時，實際的操作地址將是0窗口內核對象的pwnd。至此可以通過窗口2調用xxxSetWindowLong來將窗口0的cbwndExtra字段設置為0xfffffff，以此獲取越界寫入的能力。

漏洞觸發后的2窗口內核對象的pwnd，此時擴展內存尋址flag已經設置為offset尋址，對應的pExtraBytes已經被修改為窗口0的內核對象pwnd的內核偏移。

此時通過對var_magicClasshwnd窗口2調用SetWindowLongW，將var_normalClasshwnd0窗口0對應的tagWND0.cbWndExtra設置為0xffffff，操作結束后var_normalClasshwnd0窗口0對應的cbWndExtra將設置為0xffffff，此時var_normalClasshwnd0窗口0具備了越界寫入的能力。

通過var_normalClasshwnd0窗口0調用SetWindowLongPtrA設置var_normalClasshwnd1窗口1的dwStely字段，并通過var_normalClasshwnd1窗口1調用SetWindowLongPtrA將spmenu設置為fakespmenu偽造的menu對象，用于實現任意地址讀，這里將窗口1的dwStely修改為WS_CHILD將確保spmenu能進行設置，當fakespmenu設置成功之后，還會將該dwStely的類型還原，因為只有在原dwStely中，var_normalClasshwnd1才能通過調用GetMenuBarInfo依賴fakespmenu進入到特定的錯誤代碼的代碼分支，以實現具體的讀取操作，總結一句話就是通過窗口0的越界寫能力將窗口0設置為錯誤類型，并附加錯誤的菜單對象，以此來實現任意地址讀取。

整個利用過程中關鍵窗口的設置操作如下所示:

xxxSetWindowLong對應的內核代碼如下，其中if中對應擴展內存的offse尋址方式。else為指針尋址方式

通過窗口2調用SetWindowLong，將擴展內存c8的位置設置為fffffff，由于窗口2內核對象的pwnd. pExtraBytes已經被設置為窗口0內核對象的pwnd內核偏移，此時將直接把fffffff寫入到窗口0內核對象的pwnd+0xc8處，即0窗口內核對象的pwnd. cbwndExtra。

如下所示獲取pExtraBytes(窗口0內核對象的pwnd內核偏移)+內核基址+c8

可以看到此時計算出的目標地址就是窗口0內核對象的pwnd. cbwndExtra，其原本的大小為0x20，ffffffff寫入后窗口0對象將具備越界寫能力。

寫入成功。

之后通過窗口0調用SetWindowLongPtrA以修改窗口1的dwStely屬性

SetWindowLongPtrA和SetWindowLong的實現大同小異，如下紅框所示為對應的擴展內存offset尋址的實現方式。

進入內核xxxSetWindowLongPtr函數

如下所示為窗口1內核對象的pwnd，需要修改的dwStely位置在其偏移0x18處（right紅框才是正確位置）

檢測判斷對應的尋址flag

進入offset尋址流程，如下獲取對應的內核基地址，此時的偏移15308為窗口0/1內核對象的pwnd內核偏移的差值+0x18（dwStely的pwnd偏移）。

最終計算出窗口1內核的pwnd.dwStely地址，寫入將其設置為WS_CHILD類型(right紅框才是正確位置)。

寫入結果如下所示

之后通過窗口1調用SetWindowLongPtrA將窗口1的spmenu設置指向前面構造的fakespmenu

這里可以看到，實際上此時SetWindowLongPtrA設置的參數為-12(0xFFFFFFF4)，即為設置子窗口的新標識符。但是需要注意這里注明了該窗口不能是頂級窗口

而當函數xxxSetWindowLongPtr對應的第二個參數不為偏移，而是特殊的負數標記id時，將會進入到函數xxxSetWindowData函數中處理，也就是我們這里的情況

如下所示為對應的-12時的處理邏輯，可以看到這里會檢測對應窗口的類型是否為WS_CHILD，如果是則將value(這里指向了我們構造的fakespmenu)設置到對應窗口內核對象0xa和窗口內核對象的pwnd偏移0x98位置

如下所示內核調試器進入xxxSetWindowLongPtr

經過判斷之后進入xxxSetWindowData函數中。

進入對應的-12分支處理邏輯。

首先判斷其是否WS_CHILD類型的窗口

判斷通過直接將偽造的fakespmenu賦值

窗口1內核對象及窗口1內核對象pwnd對應賦值后如下所示

之后窗口0調用SetWindowLongPtrA將窗口1的dwStely還原

進入內核xxxSetWindowLongPtr

如下所示窗口1的dwstely已經恢復，因此這里的操作實際上是通過窗口0的越界寫入能力修改了窗口1的dwStely為WS_CHILD，這將導致可以通過窗口1以GWLP_ID調用xxxSetWindowLongPtr將窗口1內核對象的pwnd.spmenu設置指向我們的fakespmenu，之后恢復窗口1的dwStely，這就導致窗口1具備了原本dwStely=WS_CHILD時才有的spmenu屬性

設置spmenu之后，由于xxxSetWindowLongPtr的特性會將寫入前的內容返回，此時返回的內容為一個標準的內核結構，根據該內核結構的地址配合上后續的任意地址讀取，將方便的獲取ERPROCESS

借助var_normalClasshwnd1窗口1的fakespmenu，配合GetMenuBarInfo實現任意地址讀取，這里首先第一次調用GetMenuBarInfo以獲取對應var_OffsetrcBarleft偏移（后文會詳述），之后第二次調用GetMenuBarInfo才是用于讀取對應地址的數據

GetMenuBarInfo的函數原型如下所示

具體參數如下所示，這里漏洞利用時idObject為0xFFFFFFFD，對應的item為1，最終結果則通過第四個參數返回

第四個參數為MENUBARINFO，如下所示

其中的rcBar為一個矩形結構

這里通過idObject為0xFFFFFFFD可以看到在內核中對應函數為xxxGetMenuBarInfo，其核心為-3這個邏輯代碼塊。

該邏輯實際上是通過窗口內核對象0xa8處獲取對應的spmenu，這里窗口1對應的spmenu指向了我們惡意構造的fakespmenu，并將該段內存映射到內核，之后通過fakespmenu.fakerect.0x28處var_OffsetrcBarleft字段中的數據和窗口內核對象的pwnd指定偏移0x58/0x5c處的數據做計算，并將結果返回對應的pmbi.rcBar這個rect矩形結構，而這個過程中由于fakespmenu中的數值是攻擊者完全可控的，而pwnd指定偏移0x58/0x5c默認為0，這就導致通過這個操作可以進行任意地址讀取操作，這里需要注意的是實際上dwstelye=WS_CHILD，才能設置對應的spmenu，而設置了spmenu，dwstelye=WS_CHILD的窗口正常情況下并不會進入到以下的代碼分支，但是因為利用中在設置了窗口1的spmenu之后，又通過窗口0的越界寫恢復了窗口1的dwStely，從而可以進入以下的錯誤代碼分支，如下所示依次計算rect的四個坐標，并保存到變量v7中。

完成最后一個bottom寫入

如下所示第一次會讀取之前原spmenu處返回的內核結構+0x50處的數據，即下圖中fffff0680825000+50處的數據。

讀取函數中會嘗試兩次調用GetMenuBarInfo

第一次調用GetMenuBarInfo以獲取計算時var_OffsetrcBarleft的偏移。

之后第二次完成真正意義上的讀取，首先第一次讀取如下所示，此時傳入的pmbi如下所示

xxxGetMenuBarInfo中進入-3的代碼邏輯

這里會首先判斷對應dwStely，如果之前不將窗口0的dwStely恢復（恢復前為4c），則不會進入之后的代碼邏輯

之后獲取窗口1內核對象+0xa8處的fakespmenu對象

通過該fakespmenu，調用SmartObjStackRefBase<tagMENU>::operator將其映射到內核中。

如下所示可以看到對應的返回的fffffe0dd36df9e0指向了var_pmenu,之后就是后續構造的var_fakerect

判斷GetMenuBarInfo第三個參數idItem是否大于poi(poi(var_fakerect+028)+0x2c)，這里idItem為1，poi(poi(var_fakerect+028)+0x2c)在fakespmenu構造的時候將其設置為0x10，檢測通過

之后獲取var_fakeract偏移0的內容，并保存到返回的pmbi+0x18

依次檢測var_fakeract偏移0x40，0x44處是否為0，這里利用代碼在構造fakespmenu時也依次將這兩個值域進行了設置。

之后再此判斷窗口偏移0x1a處的數據，并進入最終的坐標計算邏輯。

獲取poi(poi(var_fakerect+0x58))處的var_OffsetrcBarleft，即下圖中000002804f910150

可以看到此時第一次的var_OffsetrcBarleft保存指針指向的數據是通過攻擊者手動構造的

之后依次計算返回pmbi.rcBar的left; top; right; bottom;

Left=poi(var_OffsetrcBarleft+0x40)+ poi(poi(tagWND1+0x28)+0x58)，即0x40+0=0

寫入到left字段

Right=left+ poi(var_OffsetrcBarleft+0x48) = 0x40+0x44 = 0x88

0x88寫入right字段

top=poi(var_OffsetrcBarleft+0x44)+ poi(poi(tagWND1+0x28)+0x5c)，即0x44+0=0x44

寫入到top字段

Bottom = top + poi(var_OffsetrcBarleft+0x4c) =0x44+0x4c =0x90。

寫入button字段

可以看到如下所示中，pmbi.rcBar返回的矩形實際上是通過poi(var_OffsetrcBarleft)+0x40處0x10長度的內存數據（0x40的偏移由idItem=1決定，如果等于2應該為0x40+0x60=0xa0，所以利用中默認都通過idItem=1調用GetMenuBarInfo）配合窗口內核對象的pwnd+0x58/0x5c兩個字段生成，由于這里pwnd+0x58/0x5c默認為0，因此直接依賴于poi(var_OffsetrcBarleft)+0x40處的0x10內存數據，而根據公式可以發現，pwnd+0x58/0x5c為0的情況下，left，top數據實際上就是poi(var_OffsetrcBarleft)+0x40/ poi(var_OffsetrcBarleft)+0x44這連續8個字節的內容，由于poi(var_OffsetrcBarleft)指向內容為攻擊者可控，只需將其值設置為des-0x40（0x40的偏移根據idItem而不同），即可實現對des地址數據的讀取。

內核返回的pmbi

第一次讀取返回的pmbi值

第一次讀取測試成功后返回的left正好就是var_OffsetrcBarleft的偏移

這也就是為什么第一次調用時var_OffsetrcBarleft指向內存如此構造的原因，實際上每一個4字節內存都是一個偏移，Left=poi(var_OffsetrcBarleft+0x40)+ poi(poi(tagWND1+0x28)+0x58), poi(poi(tagWND1+0x28)+0x58)=0,因此left中一定返回的是對應的偏移。

進入第二次調用將目標讀取地址減去pmbi.rcBar.left中返回的偏移值ffffff0680828050-0x40

= ffffff0680828010

此時更新過var_OffsetrcBarleft值后整體的fakespmenu內存如下所示var_OffsetrcBarleft指向了目標讀取地址-0x40的位置。

內核進入xxxGetMenuBarInfo

檢驗對應窗口的dwStely

映射對應的fakespmenu內存

如下所示left讀取此時獲取了目標地址指向內容的低四位。

Left=poi(var_OffsetrcBarleft+0x40)+ poi(poi(tagWND1+0x28)+0x58)= 0x8385a690+0=0x8385a690

將目標地址保存的第四位內容保存到left中

獲取對應的right，Right=left+ poi(var_OffsetrcBarleft+0x48) = 0x8385a690+0= 0x8385a690

寫入到right字段

top=poi(var_OffsetrcBarleft+0x44)+ poi(poi(tagWND1+0x28)+0x5c) = 0xffffff06+0 = 0xffffff06，正好是目標讀取地址的高四字節。

寫入到top字段

Bottom = top + poi(var_OffsetrcBarleft+0x4c) =0xffffff06+0 =0xffffff06。

寫入到bottom字段

此時返回后對應pmbi.rcBar

通過left+top即可獲取對應的目標地址內容。

之后如下所示依次讀取對應的EPROCESS及內核基址

如下方式讀取對應的內核基址

如下方式讀取EPROCESS

通過EPROCESS獲取系統token及當前進程token地址，并通過函數fun_Write進行寫入

fun_write借助窗口0 var_normalClasshwnd0，窗口1 var_normalClasshwnd1實現任意地址寫入，其本質是通過窗口0 var_normalClasshwnd0的越界寫入能力，調用SetWindowLongPtrA修改窗口1 var_normalClasshwnd1的擴展內存地址pExtraBytes來實現任意地址寫。

窗口0通過越界寫 調用SetWindowLongPtrA修改窗口1的pExtraBytes為目標寫入地址

首先計算對應的窗口0內核對象到窗口1內核對象的pwnd. pExtraBytes的內核偏移。

內核進入xxxSetWindowLongPtr

函數返回后窗口1內核對象的pwnd. pExtraBytes,已經被設置為當前進程的token地址。

此時通過窗口1直接調用xxxSetWindowLongPtr，并將參數index設置為0，將直接完成對當前pExtraBytes（當前進程token）地址的寫入操作

進入內核

這里不小心步過了，重新調了下，如下所示為fun_write

窗口1調用xxxSetWindowLongPtr完成對當前進程token的寫入替換

進入內核xxxSetWindowLongPtr

窗口1內核對象的pwnd. pExtraBytes指向了當前進程的token地址，這里是pointer的擴展內存尋址方式。

判斷具體的拓展內存尋址flag

計算目標地址，由于index為0，因此目標地址直接是pExtraBytes指向的當前進程token的地址。

完成寫入，提權完畢。

看完上述內容，你們對Microsoft Windows被在野利用的提權漏洞的分析報告是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。