一個(gè)HTTP請(qǐng)求，把網(wǎng)站打裂開(kāi)了！

今天給大家看一段神奇的代碼。

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

就是下面這個(gè)函數(shù)，根據(jù)傳進(jìn)來(lái)的開(kāi)始和結(jié)束位置，讀取文件數(shù)據(jù)：

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

????return?ReadFile(fd,?start,?end);
}

函數(shù)中最大只支持一次讀取1024個(gè)字節(jié)，所以增加了一個(gè)判斷邏輯。

現(xiàn)在請(qǐng)大家思考一下，這個(gè)函數(shù)有沒(méi)有什么問(wèn)題？

來(lái)思考一下，假設(shè)我像這樣來(lái)調(diào)用這個(gè)函數(shù)：

Read(0,?0,?4294967295);

會(huì)發(fā)生什么事呢？

你可能已經(jīng)注意到了，這里傳了一個(gè)很特殊的參數(shù)過(guò)去，這個(gè)數(shù)乍一看很大，遠(yuǎn)遠(yuǎn)超過(guò)了1024，按理說(shuō)會(huì)通不過(guò)函數(shù)內(nèi)部的檢查對(duì)吧？

但事情不是這么簡(jiǎn)單，這個(gè)特殊的數(shù)字——4294967295，是32位無(wú)符號(hào)整數(shù)所能表示的最大范圍。

但是請(qǐng)注意Read這個(gè)函數(shù)的參數(shù)，start和end都是int型變量，把4294967295傳遞給end的時(shí)候，會(huì)被當(dāng)作有符號(hào)的整數(shù)解析，也就是 -1 ！

現(xiàn)在來(lái)看Read函數(shù)中計(jì)算長(zhǎng)度的這行代碼：

unsigned?int?length?=?end?-?start?+?1;

計(jì)算結(jié)果就是-1 - 0 + 1 = 0！

length的結(jié)果會(huì)是0！

很自然逃過(guò)了下面對(duì)長(zhǎng)度的檢查：

if?(length?>?1024)
????return?NULL;

上面這段代碼不只是一個(gè)假想的模型，實(shí)際上，它曾經(jīng)真實(shí)存在過(guò)！

它的漏洞編號(hào)是：CVE-2015-1635。

這是一個(gè)微軟的互聯(lián)網(wǎng)服務(wù)器IIS中的一個(gè)漏洞，更要命的是，這個(gè)漏洞位于IIS處理HTTP請(qǐng)求的HTTP.sys驅(qū)動(dòng)程序中。

你知道的，驅(qū)動(dòng)程序是運(yùn)行在操作系統(tǒng)內(nèi)核之中，一旦內(nèi)核驅(qū)動(dòng)執(zhí)行出現(xiàn)異常，那后果，輕則藍(lán)屏崩潰，重則直接被攻擊者遠(yuǎn)程執(zhí)行代碼，控制服務(wù)器！

在HTTP 1.1版本的協(xié)議中，可以通過(guò)請(qǐng)求頭中的Range字段，請(qǐng)求或上傳指定資源的部分內(nèi)容，比如像這樣：

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協(xié)議的解析放在了內(nèi)核驅(qū)動(dòng)HTTP.sys中實(shí)現(xiàn)。

而其中對(duì)range字段的處理，就存在我們文章開(kāi)頭的那個(gè)邏輯錯(cuò)誤，不同的是，我們上面的那個(gè)示例是一個(gè)32位整數(shù)的版本，而IIS這個(gè)真實(shí)的漏洞是64位整數(shù)產(chǎn)生的問(wèn)題，但原理是一樣的。

通過(guò)向存在漏洞的IIS服務(wù)器發(fā)送對(duì)應(yīng)的HTTP請(qǐng)求，即可將目標(biāo)服務(wù)器打藍(lán)屏，實(shí)現(xiàn)DOS——拒絕服務(wù)攻擊。

這種攻擊方式就是——整數(shù)溢出攻擊。

接下來(lái)，咱們?cè)诖罱ㄒ粋€(gè)環(huán)境來(lái)驗(yàn)證一下。

在虛擬機(jī)中搭建一個(gè)IIS7的Web服務(wù)器：

64位無(wú)符號(hào)整數(shù)能表示的最大數(shù)是：18446744073709551615，通過(guò)向服務(wù)器發(fā)送包含range參數(shù)的請(qǐng)求，有很大可能會(huì)導(dǎo)致服務(wù)器藍(lán)屏。

使用神器metasploit來(lái)利用這個(gè)漏洞發(fā)起攻擊：

現(xiàn)在來(lái)看，服務(wù)器已經(jīng)掛了：

為什么是很大可能，而不是一定藍(lán)屏呢，如何實(shí)現(xiàn)穩(wěn)定把服務(wù)器打藍(lán)屏呢？這就需要進(jìn)一步了解這個(gè)漏洞更詳細(xì)的情況。

實(shí)際上這個(gè)漏洞原理比文章開(kāi)頭的那個(gè)邏輯要更復(fù)雜一些，這里只是做了一個(gè)簡(jiǎn)單入門(mén)介紹，關(guān)于這個(gè)漏洞的更詳細(xì)情況，大家可以看一下360大神MJ0011當(dāng)年寫(xiě)的一篇技術(shù)分析（PS：有點(diǎn)硬核，想要看懂得反復(fù)多看幾次）：

《MS15-034/CVE-2015-1635 HTTP遠(yuǎn)程代碼執(zhí)行漏洞分析》

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

我們平時(shí)在編程的時(shí)候，一定要注意變量的數(shù)據(jù)類(lèi)型，特別是涉及到數(shù)據(jù)類(lèi)型轉(zhuǎn)換的地方要格外留神。比如符號(hào)數(shù)與無(wú)符號(hào)數(shù)的互轉(zhuǎn)，32位整數(shù)和64位整數(shù)的轉(zhuǎn)換等等。

在處理外界傳入的參數(shù)處理時(shí)，要慎之又慎，一個(gè)小小的變量類(lèi)型可能就會(huì)給服務(wù)器計(jì)算機(jī)造成毀滅性打擊。