一個HTTP請求，把網站打裂開了！

大家好，我是小白哥，今天給大家看一段神奇的代碼。

利用這幾行神奇的代碼，居然能把網站打崩潰，這是怎么一回事呢？

就是下面這個函數，根據傳進來的開始和結束位置，讀取文件數據：

char* Read(int fd, int start, int end) {
    unsigned int length = end - start + 1;
    if (length > 1024)
        return NULL;
    return ReadFile(fd, start, end);
}

函數中最大只支持一次讀取1024個字節，所以增加了一個判斷邏輯。

現在請大家思考一下，這個函數有沒有什么問題？

---思---

---考---

---5---

---秒---

---鐘---

來思考一下，假設我像這樣來調用這個函數：

Read(0, 0, 4294967295);

會發生什么事呢？

你可能已經注意到了，這里傳了一個很特殊的參數過去，這個數乍一看很大，遠遠超過了1024，按理說會通不過函數內部的檢查對吧？

但事情不是這么簡單，這個特殊的數字——4294967295，是32位無符號整數所能表示的最大范圍。

但是請注意Read這個函數的參數，start和end都是int型變量，把4294967295傳遞給end的時候，會被當作有符號的整數解析，也就是 -1 ！

現在來看Read函數中計算長度的這行代碼：

unsigned int length = end - start + 1;

計算結果就是-1 - 0 + 1 = 0！

length的結果會是0！

很自然逃過了下面對長度的檢查：

if (length > 1024)
    return NULL;

上面這段代碼不只是一個假想的模型，實際上，它曾經真實存在過！

它的漏洞編號是：CVE-2015-1635。

這是一個微軟的互聯網服務器IIS中的一個漏洞，更要命的是，這個漏洞位于IIS處理HTTP請求的HTTP.sys驅動程序中。

你知道的，驅動程序是運行在操作系統內核之中，一旦內核驅動執行出現異常，那后果，輕則藍屏崩潰，重則直接被攻擊者遠程執行代碼，控制服務器！

在HTTP 1.1版本的協議中，可以通過請求頭中的Range字段，請求或上傳指定資源的部分內容，比如像這樣：

GET /bg-upper.png HTTP/1.1
User-Agent: curl/7.35.0
Host: 127.0.0.1:8180
Accept: */*
Range: bytes=0-10

其中的Range字段格式如下：

Range: bytes=start-end

微軟的IIS為了提高性能，將HTTP協議的解析放在了內核驅動HTTP.sys中實現。

而其中對range字段的處理，就存在我們文章開頭的那個邏輯錯誤，不同的是，我們上面的那個示例是一個32位整數的版本，而IIS這個真實的漏洞是64位整數產生的問題，但原理是一樣的。

通過向存在漏洞的IIS服務器發送對應的HTTP請求，即可將目標服務器打藍屏，實現DOS——拒絕服務攻擊。

這種攻擊方式就是——整數溢出攻擊。

接下來，咱們在搭建一個環境來驗證一下。

在虛擬機中搭建一個IIS7的Web服務器：

64位無符號整數能表示的最大數是：18446744073709551615，通過向服務器發送包含range參數的請求，有很大可能會導致服務器藍屏。

使用神器metasploit來利用這個漏洞發起攻擊：

現在來看，服務器已經掛了：

為什么是很大可能，而不是一定藍屏呢，如何實現穩定把服務器打藍屏呢？這就需要進一步了解這個漏洞更詳細的情況。

實際上這個漏洞原理比文章開頭的那個邏輯要更復雜一些，這里只是做了一個簡單入門介紹，關于這個漏洞的更詳細情況，大家可以看一下360大神MJ0011當年寫的一篇技術分析（PS：有點硬核，想要看懂得反復多看幾次）：

《MS15-034/CVE-2015-1635 HTTP遠程代碼執行漏洞分析》

https://blogs.#/post/cve_2015_6135_http_rce_analysis.html

我們平時在編程的時候，一定要注意變量的數據類型，特別是涉及到數據類型轉換的地方要格外留神。比如符號數與無符號數的互轉，32位整數和64位整數的轉換等等。

在處理外界傳入的參數處理時，要慎之又慎，一個小小的變量類型可能就會給服務器計算機造成毀滅性打擊。