IIS6中的解析漏洞
下面是iis6文件解析的原理：
1、當(dāng)WEB目錄下，文件名以 xxx.asp;xxx.xxx 來進(jìn)行命名的時(shí)候，此文件將送交asp.dll解析(也就是執(zhí)行腳本)
2、當(dāng)WEB目錄下，在訪問以 xxx.asp 命名的目錄下的任意文件時(shí)，此文件將送交asp.dll解析(也就是執(zhí)行腳本)
我們都知道IIS6中間件主要解析的就是asp語言的文件，如果你放入一個(gè)JAVA語言的文件，php語言的文件他是不會(huì)進(jìn)行解析的，只能當(dāng)做文本文件進(jìn)行顯示出來，而里面語法所表達(dá)的意思是不會(huì)執(zhí)行的。那么從iis底層審計(jì)原理和測試發(fā)現(xiàn)IIS6在解析文件時(shí)存在如下問題：
1、后綴如下會(huì)被當(dāng)做asp程序進(jìn)行執(zhí)行 .asp .cer .asa .cdx
2、IIS 6.0在處理含有特殊符號(hào)的文件路徑時(shí)會(huì)出現(xiàn)邏輯錯(cuò)誤，從而造成文件解析漏洞。這一漏洞有兩種完全不同的利用方式： /test.asp/test.jpg test.asp;.jpg
為什么說這樣的解析我們叫做漏洞呢？而不叫做多一種解析方式呢？
主要的原因是很多研發(fā)在編寫上傳功能的時(shí)候會(huì)進(jìn)行黑名單活著白名單的判斷，而往往不了解這種解析漏洞，忽略了這種校驗(yàn)，從而被其他人繞過上傳能解析的大小馬。
比如：有一個(gè)頭像上傳功能，開發(fā)者后臺(tái)只允許上傳后綴為jpg的文件，其他文件不允許上傳，而黑客利用第二條解析漏洞上傳了個(gè)1.asp;.jpg這時(shí)候能順利的將該文件上傳到服務(wù)器中，如果服務(wù)器只是將其按照圖片解析，那么里面插入的asp馬腳本就解析不成功無法發(fā)揮馬的作用，但是iis6會(huì)將其安裝asp文件解析，因此這個(gè)馬就能起到馬的作用，從而被黑客利用。
而iis6由于是設(shè)計(jì)上的缺陷，因此該漏洞沒有廠家的修復(fù)方案，只要研發(fā)在本身上傳功能上對上述漏洞進(jìn)行過濾。
IIS7/IIS7.5中的解析漏洞
漏洞影響 IIS7 及IIS7.5 在使FastCGI方式調(diào)用php時(shí)，在php.ini里設(shè)置cgi.fix_pathinfo=1
使得訪問任意文件URL時(shí)，在URL后面添加“/x.php”等字符時(shí)，該文件被iis當(dāng)php文件代碼解析。
如制作1.gif圖片馬（在圖片中插入php馬腳本）正常情況下訪問 http://127.0.0.1/1.gif 的內(nèi)容為正常的圖片，里面的php腳本并不會(huì)執(zhí)行，因?yàn)镮IS7/IIS7.5只會(huì)按照圖片的解析格式來進(jìn)行解析。當(dāng)訪問 http://127.0.0.1/1.gif/1.php可以看到1.gif里的php代碼被iis解析執(zhí)行了。 那么“黑客”在具體利用網(wǎng)站漏洞的時(shí)候，先可以通過網(wǎng)站提供的圖片上傳功能（也可以是其他的手段）上傳一個(gè)包含了惡意PHP代碼的圖片文件。然后通過上面描敘方法，讓iis解析執(zhí)行任意惡意的php代碼，控制網(wǎng)站及主機(jī)，最終導(dǎo)致網(wǎng)站被“脫庫”、“掛馬”、“植入非法seo鏈接”等等嚴(yán)重后果。
IIS7/IIS7.5解析漏洞的修復(fù)方案有如下幾個(gè)：
第1種方案：繼續(xù)使用FastCGI方式調(diào)用PHP，要解決這個(gè)安全問題可以在php.ini里設(shè)置 cgi.fix_pathinfo=0 ，修改保存后建議重啟iis(注意可能影響到某些應(yīng)用程序功能)。
第2種方案：使用ISAPI的方式調(diào)用PHP。（注意：PHP5.3.10已經(jīng)摒棄了 ISAPI 方式）
第3種方案：可以使用其他web服務(wù)器軟件，如Apache等。
IIS漏洞發(fā)展史
在文章的最后我們引用“千里目實(shí)驗(yàn)室“搜集的近十五載的IIS相關(guān)漏洞，中、高危漏洞共計(jì)39個(gè)，其中15年爆發(fā)的(MS15-034)HTTP.sys 遠(yuǎn)程執(zhí)行代碼漏洞和16年的(MS16-016)WebDAV 特權(quán)提升漏洞影響范圍尤其廣泛。
