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

成都創(chuàng)新互聯(lián)公司堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站制作、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿(mǎn)足客戶(hù)于互聯(lián)網(wǎng)時(shí)代的拜泉網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

背景

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

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

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

多個(gè)漏洞利用鏈

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

Payload方法論

原來(lái)，漏洞利用代碼根本沒(méi)問(wèn)題，有問(wèn)題的是FuzzBunch的Payload。

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

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

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

3.恢復(fù)Boot處理器KPCR/KPRCB，因?yàn)樗鼤?huì)在漏洞利用過(guò)程中崩潰；

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

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

單核分支異常

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

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

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

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

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

根本原因分析

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

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

NT疑惑

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

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

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

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

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

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

HAL可變字節(jié)表

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

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

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

這里有一個(gè)類(lèi)似的mov指令，但它并不是movzx指令。因?yàn)檫@個(gè)函數(shù)中并不包含這個(gè)字節(jié)序列，因此代碼無(wú)法找到這個(gè)目標(biāo)函數(shù)。

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

上述就是小編為大家分享的如何解析Windows XP版永恒之藍(lán)中的Bug了，如果剛好有類(lèi)似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。