解析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架構上存在的差異。

這也是Eternal系列漏洞的一個分析樣例，全球的網路組織可能會重複使用相同的漏洞利用代碼或Payload，但他們也會使用不同的方法來開發Exploit。如果一種方法無法成功，也可以通過漏洞利用代碼的多樣化特點最終完成他們的攻擊任務。

*參考來源：zerosum0x0，FB小編Alpha_h4ck編譯，轉載請註明來自FreeBuf.COM

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！