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

這期內容當中小編將會給大家帶來有關如何解析Windows XP版永恒之藍中的Bug，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

背景

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

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

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

多個漏洞利用鏈

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

Payload方法論

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

主要階段的Shellcode執行的是下列活動：

1.利用KdVersionBlock技術獲取&nt和&hal；

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

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

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

5.將nt!PopProcessorIdle的運行狀態恢復到正常狀態。

單核分支異常

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

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

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

這個函數估計是用來清理KPRCB的半崩潰狀態的。

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

根本原因分析

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

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

NT疑惑

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

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

但是在單核設備上是沒有HAL導入表的，只有一個字符串表：

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

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

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

HAL可變字節表

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

下面是多核版本HAL中找到的5個字節目標數據：

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

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

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

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