HTTP.SYS遠程執行代碼漏洞分析 （MS15-034 ）

寫在前言：

 

      在2015年4月安全補丁日，微軟發布了11項安全更新，共修復了包括Microsoft Windows、Internet Explorer、Office、.NET Framework、Server軟件、Office Services和Web Apps中存在的26個安全漏洞。其中就修復了HTTP.sys 中一處允許遠程執行代碼漏洞，編號為：CVE-2015-1635（MS15-034 ）。目前服務器安全狗已經更新了安全補丁，建議及時修復安全狗提示給您的漏洞信息，以免漏洞被利用遭到攻擊。

      據稱，利用HTTP.sys的安全漏洞，攻擊者只需要發送惡意的http請求數據包，就可能遠程讀取IIS服務器的內存數據，或使服務器系統藍屏崩潰。

      根據公告顯示，該漏洞對服務器系統造成了不小的影響，主要影響了包括Windows 7、Windows Server 2008 R2、Windows 8、Windows Server 2012、Windows 8.1 和 Windows Server 2012 R2在內的主流服務器操作系統。

       安全狗安全研究團隊的小伙伴們在得知這一漏洞情況后，也對其進行了深入挖掘研究，下面就將相關信息結果分享給大家。如果有任何想法，以及進一步的利用操作，也歡迎指教討論。

 

1. 首先對補丁文件做了二進制比對

 

以下是Windows 7 修復前后HTTP.SYS的變化。

 

 

值得注意的經驗是，每個函數名中都有’range’。 這不禁讓我想起了之前Apache HTTPd ‘Range’ 頭漏洞, （參見RFC2616章14.35節）。

 

漏洞數據由 ‘range’ 頭帶入已經毋庸置疑。 下面要做的是深入研究其產生的原因。如IDA 自動分析出的的HTTP!UlpParseRange 函數的調用關系圖所示：

 

 

這里我使用Vmware搭建了一個未打補丁的Windows 7 SP1 作為測試目標，並且啟用了內核調試器, 對所有關鍵函數設置斷點，收集關鍵數據和內核信息。

 

 

在斷點被觸發之后, 堆棧信息會被打印出來, 接着程序繼續執行.  我們使用了之前的Apache Rangedos 測試樣本針對目標服務器做了攻擊性測試, 調試器捕獲到了下面這些信息：

 

 

標准的Apache RangeDos 腳本確實產生了效果，下面讓我們更進一步的來看一下 HTTP!UlpParseRange 函數的實現:

 

在舊代碼的調試中發現函數在此處調用了一個很大的整數。

 

 

而新版本的代碼 調用了HTTP!RtlULongLongAdd 來檢查是否有整數溢出。 注意，這個HTTP.sys內的函數調用5個參數而不是3個參數。重復之前的測試腳本, 就會發現系統返回的錯誤代碼是0xC000000D(STATUS_INVALID_PARAMETER)，而不再是 STATUS_INTEGER_OVERFLOW 。

 

修正之后的一個簡單的POC測試腳本如下(此腳本僅用來解析證明模塊內部對Range頭參數的解析過程)。

 

 

接着讓我們在未打補丁的模塊上下斷點。

 

 

非常明顯了。 EAX 是0x7A69 (Poc中設置的range上限 31337), EDI 是0x539（Poc中設置的range下限 1337）。 在老代碼中，如果我們的下限是0，則上限不會做如此的改變。在上限非常大的時候(整數臨界值), 我們加1, 就會發生整數溢出。 HexRays 的輸出更加明了:

*(_QWORD *)v18 = __PAIR__(v22, v23) – __PAIR__(v21, v20) + 1.讓我們來試試看。

 

 

這時候可以看到上限已經非常的大了(0xFFFFFFFF)。代碼接着執行。

 

 

We can see that EAX is predictably small now.  Now that we have some indication of what the pre-patch block is doing, let’s look at the patch again.

 

最后EAX在加1之后溢出變成了0. 讓我們再看看打過補丁的模塊:

 

 

使用同樣的手法, 我們得到了一個不同的錯誤信息. 有趣的是很多情況下都會產生這個錯誤信息(比如節點深度問題等)。但是我們的主要目標是判斷是否打補丁, 所以這個沒什么大礙. 現在讓我們回到系統是否打補丁的預判上.

 

一種方法讓未打補丁的模塊返回STATUS_INVALID_PARAMETER錯誤信息的方法就是使下面代碼的關鍵處校驗失敗。

 

 

使用調試器動態改變跳轉條件, 我們可以讓服務器返回下面這個有趣的頁面(手工內存補丁成功)：

 

 

打完補丁以后當你提交了包含非法range頭字段的http包的時候, 系統會報上面的錯誤。

 

如果沒打補丁你看到的就是下面這樣:

 

這就是判斷是否打了補丁的關鍵.

 

 

打了補丁:  HTTP!RtlULongLongAdd在遇到非法range頭的時候會返回一個 STATUS_INVALID_PARAMETER 錯誤, 接着HTTP!UlpParseRang 產生一個”Invalid Header” 錯誤信息給客戶端.  

 

打了補丁:  HTTP!UlpParseRange 返回 0, 接着產生一個 “Requested Range Not Satisfiable”.錯誤信息給客戶端.

 

2、漏洞測試腳本:

 

#sutff.py
import socket
import random

ipAddr = "218.90.198.20"
hexAllFfff = "18446744073709551615"

req1 = "GET / HTTP/1.0\r\n\r\n"
req = "GET / HTTP/1.1\r\nHost: stuff\r\nRange: bytes=0-" + hexAllFfff + "\r\n\r\n"

print("[*] Audit Started")
client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client_socket.connect((ipAddr, 80))
client_socket.send(req1)
boringResp = client_socket.recv(1024)
if "Microsoft" not in boringResp:
    print("[*] Not IIS")
    exit(0)
    client_socket.close()
    client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    client_socket.connect((ipAddr, 80))
    client_socket.send(req)
    goodResp = client_socket.recv(1024)
    if "Requested Range Not Satisfiable" in goodResp:
        print("[!!] Looks VULN")
    elif " The request has an invalid header name" in goodResp:
        print("[*] Looks Patched")
    else:
        print("[*] Unexpected response, cannot discern patch status")

 

一個簡單的檢測方法:

 

curl  http://xxx.com/ -H "Host: irrelevant" -H "Range: bytes=0-18446744073709551615"|grep "range is not satisfiable"

有發現 返回”range is not satisfiable”就說明有漏洞了.