如何解析Windows XP版永恒之藍中的Bug

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)如何解析Windows XP版永恒之藍中的Bug，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

背景

黑掉Windows 7已經(jīng)沒什么挑戰(zhàn)了，我這一次打算重新回顧一下那個針對Windows XP永恒之藍漏洞的漏洞利用代碼，之前這份Exploit就沒成功過，而且我嘗試了各種版本的補丁和服務(wù)包，但這份漏洞利用代碼要么無法工作，要么就讓設(shè)備藍屏。因此我打算繼續(xù)研究一下，因為FuzzBunch有太多沒有被挖掘出來的“潛力”了。

但是在一次針對其他Windows XP設(shè)備的滲透測試過程中，我本來對FuzzBunch沒抱希望的，但可怕的是，它竟然能用…

所以我問自己，為什么它能用到外界的Windows XP設(shè)備上，卻沒辦法在我的實驗環(huán)境中使用呢？（長話短說：因為單核/多核/PAE CPU中的NT/HAL存在差別，導(dǎo)致FuzzBunch的XP Payload在單核設(shè)備上會終止運行。）

多個漏洞利用鏈

請記住，永恒之藍有很多個版本。但是FuzzBunch針對Windows XP的漏洞利用鏈卻和針對其他版本的Exploit有著很大區(qū)別，具體請參考DerbyCon 8.0的相關(guān)資料：【幻燈片】【視頻】。

Payload方法論

原來，漏洞利用代碼根本沒問題，有問題的是FuzzBunch的Payload。

主要階段的Shellcode執(zhí)行的是下列活動：

1.利用KdVersionBlock技術(shù)獲取&nt和&hal；

2.解析某些必要的函數(shù)指針，比如說hal!HalInitializeProcessor；

3.恢復(fù)Boot處理器KPCR/KPRCB，因為它會在漏洞利用過程中崩潰；

4.運行DoublePulsar，在SMB服務(wù)中植入后門；

5.將nt!PopProcessorIdle的運行狀態(tài)恢復(fù)到正常狀態(tài)。

單核分支異常

在IdleFunction上設(shè)置多個硬件斷點，并向Shellcode中設(shè)置偏移量+0x170，我們會發(fā)現(xiàn)多核設(shè)備安裝分支的情況跟單核設(shè)備的不同。

kd>ba w 1 ffdffc50 "ba e 1 poi(ffdffc50)+0x170;g;"

多核設(shè)備會要求獲取一個指向hal!HalInitializeProcessor的函數(shù)指針。

這個函數(shù)估計是用來清理KPRCB的半崩潰狀態(tài)的。

單核設(shè)備無法找到hal!HalInitializeProcessor，sub_547會返回NULL值。Payload將無法繼續(xù)運行，然后通過數(shù)據(jù)清零來進行自毀，并且會設(shè)置ROP鏈來釋放某些內(nèi)存，恢復(fù)執(zhí)行流程。

根本原因分析

sub_547這個Shellcode函數(shù)無法在單核CPU主機上找到hal!HalInitializeProcessor的地址，從而導(dǎo)致Payload的執(zhí)行過程被強制終止。因此我們需要對這個Shellcode函數(shù)進行逆向分析，找到導(dǎo)致攻擊Payload運行失敗的根本原因。

這里的內(nèi)核Shellcode存在一個問題，即沒有考慮到Windows XP上所有可用的不同類型的NT內(nèi)核可執(zhí)行文件。比如說，多核設(shè)備的NT程序（例如ntkrnlamp.exe）可以正常工作，但單核設(shè)備（例如ntoskrnl.exe）就會出現(xiàn)問題。除此之外，halmacpi.dll和halacpi.dll也存在類似的問題。

NT疑惑

sub_547要做的第一件事就是獲取NT程序所使用的HAL導(dǎo)入函數(shù)。Payload首先會讀取NT程序中的0x1040偏移量來查找HAL函數(shù)。

在多核Windows XP設(shè)備中，讀取這個偏移地址可以讓Shellcode找到正確的hal!HalQueryRealTimeClock函數(shù)：

但是在單核設(shè)備上是沒有HAL導(dǎo)入表的，只有一個字符串表：

一開始我以為自己找到了問題的根源，但其實不然，因為這里有一個修正碼問題。Shellcode會檢查偏移量0x1040的值是否位于HAL范圍內(nèi)。如果條件不滿足，則會減去0xc40，然后以0x40作為增量值在HAL地址范圍內(nèi)進行搜索，直到搜索地址再次到達0x1040為止。

最終，單核設(shè)備上的Payload會找到一個HAL函數(shù)，即hal!HalCalibratePerformanceCounter：

題外話：方程式組織（國際著名黑客組織）在判斷不同XP NT類型上做得非常優(yōu)秀！

HAL可變字節(jié)表

Shellcode在找到了HAL函數(shù)之后，會嘗試定位hal!HalInitializeProcessor。Shellcode中內(nèi)置的表（位于0x5e7偏移量）包含了一個長度為1字節(jié)的域，后面可以跟一段字節(jié)序列。接下來，Shellcode會以在增量0x20字節(jié)遍歷搜索新的HAL函數(shù)地址。

下面是多核版本HAL中找到的5個字節(jié)目標數(shù)據(jù)：

但是，單核版本的HAL函數(shù)差異就很大：

這里有一個類似的mov指令，但它并不是movzx指令。因為這個函數(shù)中并不包含這個字節(jié)序列，因此代碼無法找到這個目標函數(shù)。

大家都知道，在不同版本的Windows系統(tǒng)中，想通過搜索字節(jié)序列來識別函數(shù)并不是一件容易的事情。從這個漏洞中，我們至少應(yīng)該學(xué)到一點，即各位Exploit開發(fā)者在設(shè)計漏洞利用代碼時必須要考慮周全，注意NTOSKRNL和HAL在單核/多核/PAE架構(gòu)上存在的差異。

上述就是小編為大家分享的如何解析Windows XP版永恒之藍中的Bug了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。