一個HTTP請求，把網(wǎng)站打裂開了！
今天給大家看一段神奇的代碼。
利用這幾行神奇的代碼，居然能把網(wǎng)站打崩潰，這是怎么一回事呢？
就是下面這個函數(shù)，根據(jù)傳進(jìn)來的開始和結(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個字節(jié)，所以增加了一個判斷邏輯。
現(xiàn)在請大家思考一下，這個函數(shù)有沒有什么問題？
---思---
---考---
---5---
---秒---
---鐘---
來思考一下，假設(shè)我像這樣來調(diào)用這個函數(shù)：
- Read(0, 0, 4294967295);
會發(fā)生什么事呢？
你可能已經(jīng)注意到了，這里傳了一個很特殊的參數(shù)過去，這個數(shù)乍一看很大，遠(yuǎn)遠(yuǎn)超過了1024，按理說會通不過函數(shù)內(nèi)部的檢查對吧？
但事情不是這么簡單，這個特殊的數(shù)字——4294967295，是32位無符號整數(shù)所能表示的最大范圍。
但是請注意Read這個函數(shù)的參數(shù)，start和end都是int型變量，把4294967295傳遞給end的時候，會被當(dāng)作有符號的整數(shù)解析，也就是 -1 ！
現(xiàn)在來看Read函數(shù)中計算長度的這行代碼：
- unsigned int length = end - start + 1;
計算結(jié)果就是-1 - 0 + 1 = 0！
length的結(jié)果會是0！
很自然逃過了下面對長度的檢查：
- if (length > 1024)
- return NULL;
上面這段代碼不只是一個假想的模型，實際上，它曾經(jīng)真實存在過！
它的漏洞編號是：CVE-2015-1635。
這是一個微軟的互聯(lián)網(wǎng)服務(wù)器IIS中的一個漏洞，更要命的是，這個漏洞位于IIS處理HTTP請求的HTTP.sys驅(qū)動程序中。
你知道的，驅(qū)動程序是運(yùn)行在操作系統(tǒng)內(nèi)核之中，一旦內(nèi)核驅(qū)動執(zhí)行出現(xiàn)異常，那后果，輕則藍(lán)屏崩潰，重則直接被攻擊者遠(yuǎn)程執(zhí)行代碼，控制服務(wù)器！
在HTTP 1.1版本的協(xié)議中，可以通過請求頭中的Range字段，請求或上傳指定資源的部分內(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ū)動HTTP.sys中實現(xiàn)。
而其中對range字段的處理，就存在我們文章開頭的那個邏輯錯誤，不同的是，我們上面的那個示例是一個32位整數(shù)的版本，而IIS這個真實的漏洞是64位整數(shù)產(chǎn)生的問題，但原理是一樣的。
通過向存在漏洞的IIS服務(wù)器發(fā)送對應(yīng)的HTTP請求，即可將目標(biāo)服務(wù)器打藍(lán)屏，實現(xiàn)DOS——拒絕服務(wù)攻擊。
這種攻擊方式就是——整數(shù)溢出攻擊。
接下來，咱們在搭建一個環(huán)境來驗證一下。
在虛擬機(jī)中搭建一個IIS7的Web服務(wù)器：
64位無符號整數(shù)能表示的最大數(shù)是：18446744073709551615，通過向服務(wù)器發(fā)送包含range參數(shù)的請求，有很大可能會導(dǎo)致服務(wù)器藍(lán)屏。
使用神器metasploit來利用這個漏洞發(fā)起攻擊：
現(xiàn)在來看，服務(wù)器已經(jīng)掛了：
為什么是很大可能，而不是一定藍(lán)屏呢，如何實現(xiàn)穩(wěn)定把服務(wù)器打藍(lán)屏呢？這就需要進(jìn)一步了解這個漏洞更詳細(xì)的情況。
實際上這個漏洞原理比文章開頭的那個邏輯要更復(fù)雜一些，這里只是做了一個簡單入門介紹，關(guān)于這個漏洞的更詳細(xì)情況，大家可以看一下360大神MJ0011當(dāng)年寫的一篇技術(shù)分析（PS：有點硬核，想要看懂得反復(fù)多看幾次）：
《MS15-034/CVE-2015-1635 HTTP遠(yuǎn)程代碼執(zhí)行漏洞分析》
https://blogs.#/post/cve_2015_6135_http_rce_analysis.html
我們平時在編程的時候，一定要注意變量的數(shù)據(jù)類型，特別是涉及到數(shù)據(jù)類型轉(zhuǎn)換的地方要格外留神。比如符號數(shù)與無符號數(shù)的互轉(zhuǎn)，32位整數(shù)和64位整數(shù)的轉(zhuǎn)換等等。
在處理外界傳入的參數(shù)處理時，要慎之又慎，一個小小的變量類型可能就會給服務(wù)器計算機(jī)造成毀滅性打擊。
