深入解讀:Windows HTTP.sys遠程代碼執行漏洞跟蹤進展

此次微軟公告MS15-034 IIS7 http.sys漏洞，引來業界的關注，其震蕩性不亞於Windows領域的心臟出血事件。綠盟科技威脅響應中心啟動緊急響應機制，在4月15日、4月16日分別發布緊急通告及產品規則升級通告，受如下系統影響的用戶還請儘快升級廠商的補丁及綠盟科技產品規則包。

Microsoft Windows Server 2012 R2

Microsoft Windows Server 2012

Microsoft Windows Server 2008 SP1

Microsoft Windows 8.1

Microsoft Windows 8

Microsoft Windows 7 SP1

http.sys漏洞影響範圍

隨著各方的深入分析，各地域受Windows HTTP.sys漏洞影響的情況正在逐漸浮出水面。昨天的通告信息中提到Http.sys是Microsoft Windows處理HTTP請求的內核驅動程序，據綠盟科技網際網路廣譜平臺數據顯示，全球部署IIS的系統數量大概有444萬餘，從目前受影響的IIS各版本分布統計數據來看，其中IIS 7.5部署量最大，佔比42.3%，也是本次追蹤分析的重點。

在如下全球IIS7.5分布態勢圖中，可以看到美洲、歐洲、亞洲等國家受影響比較嚴重，其中美國、中國、英國及德國為受影響的稠密區域。

 

http.sys漏洞危害性分析

很多大型企業或組織在應對http.sys漏洞的時候，往往需要採取謹慎的態度，對於應對措施需要，並且結合自身的業務情況及網絡環境，定製行動計劃，以避免對業務系統造成損害，這就需要深入了解此次漏洞的原理，才能給出合適的方案。未知攻焉知防！下面對此漏洞的原理進行分析，以便大家更好的理解和防禦這一高危安全漏洞。

1、漏洞觸發

根據Pastebin上披露的PoC（http://pastebin.com/ypURDPc4），很容易構造出能觸發BSOD的PoC，比如以下請求：

GET /welcome.png HTTP/1.1

Host: PoC

Range: bytes=12345-18446744073709551615

可以使安裝有IIS 7.5的Windows 7 SP1系統BSOD。

2、漏洞原理

這裡以Windows 7 SP1 X64系統上安裝的IIS 7.5為例進行分析，其內核的版本為6.1.7601.18409，HTTP.sys的版本為6.1.7601.17514。

對BSOD崩潰的現場進行分析，發現是各種情況的內存錯誤，由此推測觸發漏洞後可能造成了內存破壞。對HTTP.sys的處理流程進行分析、逐步排查，可以確定內存破壞發生在函數HTTP!UlBuildFastRangeCacheMdlChain中，調用棧如下：

函數HTTP!UlBuildFastRangeCacheMdlChain用於生成響應報文的緩存MDL鏈，來描述HTTP響應的狀態行、頭部與消息體，鏈上的各MDL通過調用nt! IoBuildPartialMdl來生成。

MSDN中對nt! IoBuildPartialMdl的說明如下：

注意這裡明確要求了由VirtualAddress與Length確定的區間必須是SourceMdl描述的緩衝區的一個自區間，正是對此要求的違反導致了此漏洞中的內存破壞。

第3次調用nt! IoBuildPartialMdl來生成消息體MDL時的參數如下：

SourceMdl = 0xfffffa801a38cb60

SourceMdl.VirtualAddress = 0xfffffa801ac94000

SourceMdl.ByteCount = 0x2d315

SourceMdl.ByteOffset = 0x0

TargetMdl = 0xfffffa801a2ed580

TargetMdl.VirtualAddress = 0xfffffa801ac97000

TargetMdl.ByteCount = 0xffffcfc7

TargetMdl.ByteOffset = 0x39

VirtualAddress = 0xfffffa801ac97039

Length = 0xffffcfc7

這裡的Length是根據HTTP請求消息頭部中的Range欄位計算得到的，過程如下：

首先，在HTTP!UlpParseRange中對Range欄位進行解析，得到RangeBegin、RangeEnd；

然後，計算RangeLength = RangeEnd - RangeBegin + 1；

最後，將RangeLength截斷為32位得到Length。

以PoC中的Range: bytes=12345-18446744073709551615為例：

RangeBegin = 12345 = 0x3039

RangeEnd = 18446744073709551615 = 0xffffffffffffffff

RangeLength = 0xffffffffffffffff - 0x00003039 + 1 = 0xffffffffffffcfc7

Length = 0xffffcfc7

顯然由於Length超長而導致違反了nt! IoBuildPartialMdl的要求，進而造成內存破壞。

3、限制條件

HTTP.sys中的一些校驗措施可能在進入HTTP!UlBuildFastRangeCacheMdlChain函數前將RangeLength修改為合法值，從而不會觸發漏洞。

例如，在Windows 7 SP1 X64系統的IIS 7.5中，函數HTTP!UlAdjustRangesToContentSize會對RangeLength進行檢查，並在必要時進行調整，如下：

當RangeBegin >= ContentLength時，移除對應的數據；

當RangeLength== -1時，RangeLength= ContentLength – RangeBegin；

當RangeEnd + 1 >= ContentLength時，RangeLength= ContentLength – RangeBegin；

因此，要保持RangeLength不被修正而又能觸發漏洞，必須要同時滿足RangeEnd + 1 < ContentLength與RangeEnd > ContentLength，RangeEnd就只能為0xffffffffffffffff。

這樣，RangeBegin就必須小於ContentLength，同時還不能為1（否則將使RangeLength = 0xffffffffffffffff – 1 + 1 = -1而導致RangeLength被修正）。

在其他版本的系統中可能會有更多的限制。

4、代碼執行

從上述分析可以看出，觸發此漏洞可越界寫數據而造成內存破壞，理論上存在遠程執行代碼的可能性。但是越界所寫數據的長度下限由ContentLength決定，通常會是一個較大的值而立即使系統崩潰。即使目標伺服器上存在一些大的文件，可以用來越界寫少量數據，所寫數據內容與被覆蓋目標也很難控制。因此，在實際環境中想要穩定的利用此漏洞來執行代碼是非常困難的。

與http.sys漏洞攻擊賽跑

通過前面的分析可以看到，利用此漏洞的攻擊大致會有兩種形式：1種難度比較低，很容易導致伺服器系統藍屏；2如果攻擊者的水平比較高，就可以精確的控制內存，通過遠程執行代碼，進而獲得對系統的完全控制。尤其是面臨高價值回報的攻擊目標時，發生的機率就更高了，企業或組織的IT人員需要儘快考慮應對方案，避免在安全防禦措施上線之前遭受攻擊。這至少應該包含如下環節：

首先，應該第一時間獲取漏洞通告及相關信息，了解此次漏洞的影響範圍及深度。

再者，需要將通告和解讀與自身實際IT業務系統狀況相結合，全面判斷出影響範圍和程度（這包括對自身業務及對其客戶的影響程度），這個判斷過程，需要數據作為準確方案制定的事實依據，建議用戶使用安全可靠的漏洞掃描工具，升級最新發布的插件或規則庫，對全網進行安全掃描，拿到第一手數據後以便作為決策依據；

再次，IT人員需要從業務穩定性、危害程度和範圍及重要性等多個維度綜合考慮，制定整改時間計劃表，權重由高到低依次對局部網絡及主機設備或某業務系統設備展開整改和加固工作（建議邀請漏洞相關廠商及安全廠商一同參與）。

這個階段需要安全廠商提供專業技術協助，比如漏洞加固諮詢、驗證加固是否成功；同時需要了解安全廠商的哪些設備已經發布或即將發布防護規則，升級後即可進行防護；

如果還沒有採用任何一款安全設備，就需要採取臨時防護措施，包括採用漏洞相關廠商及安全廠商的相關方案，為整體加固爭取時間，避免在未加固整改成功之前這個窗口時間遭到攻擊並受到損失，這樣的情況在相當多的0day事件中屢見不鮮；

另外，還需要漏洞相關廠商與安全廠商通力協作，互相溝通漏洞原理和利用過程，進行較深層次的解讀，才能夠促進漏洞相關廠商的開發人員深入了解這個漏洞並根據其自身情況進行代碼層面的整改；

然後，在加固階段性或整體完成後，需要再次進行完整掃描和人工驗證整改加固結果，在技術投入允許的條件下，建議您再次進行各方面日誌分析，觀察整改加固期間有沒有成功的攻擊到其系統造成其他損失；

最後，在整體響應工作完成後，進行總結和備案記錄。 

IIS漏洞情況

前車之鑑後事之師，IIS由於使用量較大，出現的問題不少，總是給人以不踏實的感覺。其實在2014年，微軟IIS就出現了兩個高危漏洞，其中第2個且目前廠商還沒有提供補丁或者升級程序，我們建議使用這些IIS版本的用戶隨時關注廠商的主頁以獲取最新版本，並諮詢綠盟科技的服務人員！

1.2014-11-11，IIS安全功能繞過漏洞（MS14-076）（CVE-2014-4078）

描述：IIS 8.0/8.5版本的IP安全功能沒有根據"IP Address and Domain Restrictions"列表正確處理進站Web請求，這可使遠程攻擊者通過HTTP請求，利用此漏洞繞過目標規則。

2.2014-04-02，CGI CRLF注入漏洞（CVE-2011-5279）

描述：Windows NT及Windows 2000上IIS 4.x及5.x版本的CGI實現中存在CRLF注入漏洞，這可使遠程攻擊者通過CGI請求中的\n字符（新行）構造畸形請求修改環境變量，從而進一步執行任意代碼。

此外，IIS在其歷史上也出過幾次重大漏洞，綠盟科技研究院特別整理了這些信息，便於企業和組織的IT人員借鑑。以下加粗字體，為目前廠商還沒有提供補丁或者升級程序的漏洞，請予以特別關注：

1.2010-09-14 Microsoft IIS FastCGI請求頭遠程溢出漏洞（MS10-065）（CVE-2010-2730）

描述：對於啟用了FastCGI功能的IIS伺服器，遠程攻擊者可以通過提交特製的HTTP請求觸發緩衝區溢出，導致執行任意代碼。攻擊者可以遠程執行任意代碼。

2.2010-06-08 Microsoft IIS認證令牌處理遠程代碼執行漏洞（MS10-040）（CVE-2010-1256）

描述：IIS Web伺服器在解析從客戶端所接收到了認證信息時沒有正確地分配內存，遠程攻擊者可以通過發送特製的認證報文導致以工作進程標識（WPI）的上下文中執行代碼。必須啟用了Extended Protection for Authentication功能才可以利用這個漏洞（默認為禁用）。攻擊者可以遠程執行任意代碼。

3.2009-10-13 Microsoft IIS FTPd服務NLST命令遠程棧溢出漏洞（MS09-053）（CVE-2009-3023）

描述：攻擊者可以導致拒絕服務或遠程執行任意代碼。Microsoft IIS內嵌的FTP伺服器中存在棧溢出漏洞。如果遠程攻擊者對帶有特製名稱的目錄發布了包含有通配符的FTP NLST（NAME LIST）命令的話，就可以觸發這個溢出，導致拒絕服務或執行任意代碼。僅在攻擊者擁有寫訪問權限的情況下才可以創建帶有特殊名稱的目錄。攻擊者可以導致拒絕服務或遠程執行任意代碼。

4.2009-09-15 Microsoft IIS腳本文件名錯誤解析漏洞

描述：IIS在處理腳本文件名的解析時存在漏洞，當文件名為[YYY].asp;[ZZZ].jpg形式時，IIS會自動以asp格式來進行解析，而當文件名為[YYY].php;[ZZZ].jpg形式時，IIS會自動以php格式來進行解析（其中[YYY]與[ZZZ]為可變化字符串）。遠程攻擊者可以利用此漏洞突破Web應用對上傳文件類型的限制，在伺服器上執行任意腳本代碼從而獲取對伺服器的控制。攻擊者可以遠程執行任意代碼。

5.2009-06-09 Microsoft IIS 5.0 WebDAV繞過認證漏洞（MS09-020）（CVE-2009-1122）

描述：IIS的WebDAV擴展沒有正確解碼特製請求的URL，導致WebDAV在處理該請求時應用不正確的配置。如果應用的配置允許匿名訪問，則特製的請求可以繞過身份驗證。請注意IIS在配置的匿名用戶帳戶的安全上下文中仍會處理該請求，因此此漏洞不能用於繞過NTFS ACL，文件系統ACL對匿名用戶帳戶強加的限制將仍然執行。攻擊者可以繞過認證獲得非授權訪問。

6.2009-06-09 Microsoft IIS WebDAV Unicode請求繞過認證漏洞（MS09-020）（CVE-2009-1535）

描述：IIS的WebDAV功能在解析URI並發送回數據時沒有正確地處理Unicode令牌環，遠程攻擊者可以通過提交惡意HTTP GET請求繞過受口令保護的文件夾的認證，或在受口令保護的WebDAV目錄中列出、上傳或下載文件。攻擊者可以繞過認證執行非授權操作。

7.2008-02-12 Microsoft IIS ASP遠程代碼執行漏洞（MS08-006）（CVE-2008-0075）

描述：IIS處理ASP網頁輸入的方式存在遠程代碼執行漏洞，允許攻擊者向網站的ASP頁面傳送惡意輸入。成功利用這個漏洞的攻擊者可以在IIS伺服器上以WPI的權限（默認配置為網絡服務帳號權限）執行任意操作。攻擊者可以遠程執行任意代碼。

請持續關注相關漏洞信息

綠盟科技研究院會長年跟蹤分析這些漏洞，並將整理後的結果發送給您，便於您持續關注漏洞的發展態勢，為企業及組織的安全方案提供數據及信息支撐，如果您對我們提供的內容有任何疑問，或者需要了解更多的信息，可以隨時通過在微博、微信中搜索綠盟科技聯繫我們，歡迎您的垂詢！

【責任編輯：

王林

TEL：[phone]】

點讚 0