- 相關(guān)推薦
兩種基于HTTP的通用IDS躲避技術(shù)
I．介紹
自從Rain Forest Puppy（RFP）的網(wǎng)絡(luò)掃描器whisker首次公布于眾以來［1］，HTTP IDS躲避技術(shù)已經(jīng)逐漸流行。原先許多的HTTP IDS技術(shù)，都是從whisker的第一個(gè)版本出現(xiàn)的，包括簡單的使用多個(gè)“/”的混淆目錄技術(shù)，也包括更復(fù)雜的 － 在URL里插入“HTTP/1.0”以躲避那些搜索URL地址的IDS算法。
除了whisker中出現(xiàn)的躲避技術(shù)，還有其他類型的HTTP混淆方法。其中的一個(gè)混淆URL的方法就是使用絕對(duì)URI與相對(duì)URI［2］。雖然這些方法很有趣，但是都不如whisker掃描中使用的方法常見。
下一個(gè)流行的躲避方法也是RFP發(fā)布的，利用了微軟互聯(lián)網(wǎng)信息服務(wù)器（IIS）的UTF-8 unicode解碼漏洞［3］。雖然是IIS的一個(gè)嚴(yán)重漏洞，它同時(shí)也給出了一個(gè)IDS未曾實(shí)現(xiàn)的URL編碼方法。目前為止，大部分IDS仍然只是關(guān)注以前whisker的ASCII編碼與目錄遍歷躲避技術(shù)，對(duì)Unicode的UTF-8編碼卻沒有相應(yīng)的保護(hù)。Eric Hacker對(duì)這種類型的HTTP IDS躲避技術(shù)，寫了一篇非常專業(yè)的文章［4］。本文也會(huì)對(duì)Hacker文中的一些觀點(diǎn)分析并解釋。我們將繼續(xù)Hacker的觀點(diǎn)并深入了解：這些編碼到底意味著什么，怎樣才能造出更奇怪的編碼。
本文介紹的其他種類的HTTP IDS躲避技術(shù)，使用了HTTP協(xié)議的屬性。其中之一就是請(qǐng)求管道，以及使用內(nèi)容編碼頭并將HTTP請(qǐng)求的參數(shù)放置到請(qǐng)求負(fù)載中的技術(shù)。
II．IDS HTTP協(xié)議分析
為了能夠識(shí)別URL攻擊，IDS必須檢查HTTP的URL字段，看是否有惡意內(nèi)容。兩種最流行的IDS檢測(cè)方法 － 模式匹配和協(xié)議分析 － 都需要檢測(cè)URL中是否含有惡意內(nèi)容（通過某種形式的模式匹配或者HTTP協(xié)議分析）。
兩種方法的不同之處取決于你的目的，協(xié)議分析法只搜索HTTP流URL字段部分的惡意內(nèi)容，而模式匹配法的搜索范圍是整個(gè)數(shù)據(jù)包。
這兩種方法在處理惡意URL之前的行為是類似的。之后，協(xié)議分析法只需要對(duì)URL字段添加合適的解碼算法即可（它已經(jīng)有內(nèi)建的HTTP協(xié)議解碼引擎）。而模式匹配算法并不知道需要對(duì)包的哪一部分正常化，因此需要與某種形式的協(xié)議分析相結(jié)合，找到相應(yīng)的URL字段，才能使用相應(yīng)的解碼算法。某種形式的HTTP協(xié)議分析被添加到模式匹配法中，之后兩者又行為類似了。
由于這些IDS方法的類似性，本文討論的HTTP IDS躲避方法適用于各種類型的IDS。
第一種通用的IDS躲避方法是無效協(xié)議解析。舉個(gè)例子，如果HTTP URL沒有被正確發(fā)現(xiàn)，那么惡意URL就不能被檢查出來，原因是：IDS沒有發(fā)現(xiàn)URL，就不能對(duì)URL進(jìn)行解碼。
如果URL是正確的，IDS必須知道正確的解碼算法，否則，仍然不能得到正確的URL。這就是第二種IDS躲避技術(shù) － 無效協(xié)議字段解碼。
A. 無效協(xié)議解析
使用無效協(xié)議解析IDS躲避技術(shù)，在RFP的whisker［1］和Bob Graham的SideStep［5］中給出了很多例子。這兩個(gè)程序的區(qū)別在于：whisker使用了有缺陷的IDS協(xié)議解析來躲避檢查，而SideStep使用正常的網(wǎng)絡(luò)層協(xié)議來躲避IDS的協(xié)議解碼器。
這種情況下，無效協(xié)議解析的躲避技術(shù)，對(duì)于HTTP協(xié)議的兩個(gè)字段URL和URL參數(shù)是非常有效的。
例如：如果IDS的HTTP解碼器假設(shè)每個(gè)請(qǐng)求包只有一個(gè)URL，那么一個(gè)包里包含兩個(gè)URL，IDS就不能對(duì)第二個(gè)URL正確解析。這種技術(shù)在請(qǐng)求管道躲避技術(shù)中還會(huì)提到。
B．無效協(xié)議段解碼
無效協(xié)議段解碼可以測(cè)試IDS是否能夠處理特定協(xié)議段的各種類型的解碼。
如果是HTTP，主要的目標(biāo)就是URL字段。對(duì)于IDS，需要測(cè)試它與HTTP RFC編碼標(biāo)準(zhǔn)的符合程度，還要看是否能支持特定Web服務(wù)器的編碼類型（例如IIS）。如果IDS不能對(duì)某種URL編碼進(jìn)行正確解碼，攻擊者就能利用該編碼跳過對(duì)惡意URL的檢測(cè)。
另一個(gè)HTTP無效協(xié)議段編碼，是通過目錄混淆，操縱目錄屬性來實(shí)現(xiàn)的。例如：對(duì)于/cgi-bin/phf，可以使用多個(gè)“/”而不是一個(gè)“/”來改變目錄的“外貌”，或者使用目錄遍歷來混淆目錄路徑。需要注意的是，只有當(dāng)IDS共同查找目錄和文件時(shí)，目錄混淆才能隱藏惡意URL。對(duì)于“/cgi-bin/phf”來說，如果IDS在“cgi-bin”目錄中尋找“phf”文件時(shí)，我們的攻擊例子才能奏效；如果IDS只尋找“phf”文件，目錄混淆方法就不管用了。
III．無效協(xié)議段解碼
URL混淆的前題是HTTP服務(wù)器所接受的各種類型的編碼方法。實(shí)際上，大部分的編碼方法都與IIS有關(guān)，為了文章的完整性，每種編碼類型都對(duì)每種HTTP服務(wù)器進(jìn)行測(cè)試。
利用URL編碼來混淆Web攻擊的思想依據(jù)，是大部分的IDS缺乏對(duì)不同類型Web服務(wù)器編碼的足夠分析。IDS的模式匹配與協(xié)議檢測(cè)技術(shù)都存在問題。
對(duì)于URI請(qǐng)求的編碼，只有兩個(gè)RFC標(biāo)準(zhǔn)：十六進(jìn)制編碼和UTF－8 Unicode編碼。這兩種方法都使用“％”來表示編碼。Apache也只支持這兩種URL編碼類型。
我們研究的大部分其他編碼類型，都是服務(wù)器相關(guān)的，不符合RFC標(biāo)準(zhǔn)。微軟的IIS Web服務(wù)器就屬于這一類。在這一段也包括了URL混淆。
A．十六進(jìn)制編碼
十六進(jìn)制編碼方法是對(duì)URL進(jìn)行編碼的符合RFC要求的一種方式，也是最簡單的URL編碼方法。該方法只須在每個(gè)編碼字符的十六進(jìn)制字節(jié)值前，加一個(gè)“％”。如果我們想對(duì)大寫的A進(jìn)行十六進(jìn)制編碼（ASCII的十六進(jìn)制值是0x41），編碼的結(jié)果是：
• %41 = ‘A’
B．雙百分號(hào)十六進(jìn)制編碼
雙百分號(hào)十六進(jìn)制編碼是基于正常的十六進(jìn)制編碼。具體的方法是將百分號(hào)編碼并后接信息編碼的十六進(jìn)制值。對(duì)大寫的A進(jìn)行編碼，結(jié)果是：
• %2541 = ‘A’
你可以看到，百分號(hào)的編碼是％25（等價(jià)于“％”），該值解碼后變成了％41（等價(jià)于“A”）。這種編碼方法受到微軟IIS的支持。
C．雙四位十六進(jìn)制編碼
雙四位十六進(jìn)制編碼也是基于標(biāo)準(zhǔn)的十六進(jìn)制編碼，每個(gè)四位十六進(jìn)制使用標(biāo)準(zhǔn)的十六進(jìn)制編碼方法。例如，對(duì)大寫的A編碼，結(jié)果是：
• %%34%31 = ‘A’
正常的A，十六進(jìn)制編碼是％41。雙四位十六進(jìn)制編碼的方法是對(duì)每個(gè)四位進(jìn)行編碼，因此，4被編碼為％34（這是數(shù)字4的ASCII值），第二個(gè)四位，1，被編碼為％31（這是數(shù)字1的ASCII值）。
在第一次URL解碼
后，四位值變成了數(shù)字4和數(shù)字1。因?yàn)?和1前邊有一個(gè)％，第二遍會(huì)將％41解碼為大寫的A。
D．首四位十六進(jìn)制編碼
首四位十六進(jìn)制編碼類似于雙四位十六進(jìn)制編碼，不同之處在是只有第一個(gè)四位被編碼。因此對(duì)于大寫的A，雙四位十六進(jìn)制編碼后為%%34%31，而按照首四位十六進(jìn)制編碼結(jié)果為：
• %%341 = ‘A’
像以前一樣，第一次URL解碼以后，％34被解碼為數(shù)字4，因此第二次解碼時(shí)的對(duì)象就成了％41，最后的結(jié)果依然是大寫的A。
E．后四位十六進(jìn)制編碼
后四位十六進(jìn)制編碼與首四位十六進(jìn)制編碼完全相同，只不過只執(zhí)行標(biāo)準(zhǔn)解碼的后四位。因此大寫A的編碼結(jié)果是：
• %4%31 = ‘A’
第一次解碼時(shí)，％31解碼為數(shù)字1，第二次解碼的對(duì)象就是％41，最終的結(jié)果是“A”。
F．UTF-8編碼
1） UTF-8 介紹
UTF-8編碼允許大于單字節(jié)（0－255）的值以字節(jié)流的形式表示。HTTP服務(wù)器使用UTF-8編碼來表示大于ASCII代碼范圍之外（1－127）的Unicode碼。
UTF-8工作的時(shí)候，字節(jié)的高位有特殊的含義。兩字節(jié)的UTF-8和三字節(jié)的UTF-8序列表示如下：
110xxxxx 10xxxxxx (二字節(jié)序列)
1110xxxx 10xxxxxx 10xxxxxx (三字節(jié)序列)
UTF-8序列的第一字節(jié)是最重要的，通過它你可以知道這個(gè)UTF-8序列有多少字節(jié)，這是通過檢查第一個(gè)0之前的1的個(gè)數(shù)來獲得的。例子中，兩字節(jié)的UTF-8序列，0之前的高位有兩個(gè)1。第一個(gè)UTF-8字節(jié)0后邊的位可以用來計(jì)算最終的值。后邊的UTF-8字節(jié)格式相同，最高位是1，次高位是0，兩位用于鑒別UTF-8，剩下的6位用來計(jì)算最終的值。
為了對(duì)URL進(jìn)行UTF-8編碼，每個(gè)UTF-8字節(jié)都是用一個(gè)百分號(hào)進(jìn)行轉(zhuǎn)換。一個(gè)例子是：%C0%AF = ‘/’.
2）Unicode碼點(diǎn)簡介
可以使用UTF-8編碼來對(duì)Unicode碼點(diǎn)值進(jìn)行編碼。碼點(diǎn)值的范圍通常是0－65535，HTTP URL中的任何大于127的碼點(diǎn)值都使用UTF-8編碼。
值為0－127的Unicode碼點(diǎn)，將會(huì)映射成單獨(dú)的ASCII值。這樣，就剩下65408個(gè)值，可以表示其他語言中的字符（例如匈牙利語或者日語）。通常，這些語言有自己的Unicode代碼頁，從Unicode代碼頁中可以得到Unicode的碼點(diǎn)值。每種Unicode代碼頁有自己獨(dú)特的值，因此如果Unicode代碼頁變了，Unicode碼點(diǎn)值所代表的字符也就不同了。這一概念對(duì)于下一節(jié)的URL編碼是很重要的。
3）把躲避手段綜合起來
IDS很難處理UTF-8編碼的Unicode碼點(diǎn)值，主要有三個(gè)原因：
第一個(gè)原因是，UTF-8編碼可以將一個(gè)碼點(diǎn)值或者ASCII值用不止一種方式表示，這在最近的Unicode標(biāo)準(zhǔn)中已經(jīng)修正，但是在Web服務(wù)器中仍然很常見（包括Apache）。
例如，大寫字母A可以用兩字節(jié)的UTF-8序列編碼：
• %C1%81 (11000001 10000001 = 1000001 = ‘A’)
同樣，大寫字母A也可以用三字節(jié)的UTF-8序列編碼：
• %E0%81%81 ( 11100000 10000001 10000001 = 1000001 = ‘A’)
因此，使用UTF-8來對(duì)ASCII字符進(jìn)行編碼，會(huì)得到很多結(jié)果。
第二個(gè)原因，某些非ASCII的Unicode碼點(diǎn)也可以映射為ASCII字符。例如，Unicode碼點(diǎn)12001可以映射為大寫字母A。如果想要知道哪一個(gè)碼點(diǎn)可以映射到ASCII字符，要么閱讀整個(gè)Unicode碼的映射，要么對(duì)服務(wù)器測(cè)試所有不同的Unicode碼點(diǎn)。目前，唯一這么做的Web服務(wù)器就是微軟的IIS服務(wù)器。
第三個(gè)原因與第二個(gè)原因有關(guān)。如果Unicode碼的映射改變或者未知，翻譯后的Unicode碼點(diǎn)就有可能是無效的。這一點(diǎn)很重要，這是因?yàn)橹袊�、日本、波蘭等國的IIS Web服務(wù)器使用不同的代碼頁，因此如果IDS不了解Web服務(wù)器使用的代碼頁，對(duì)URL進(jìn)行UTF-8解碼的結(jié)果就有可能是錯(cuò)誤的。因此如果一個(gè)IDS不能對(duì)所監(jiān)視服務(wù)器使用的Unicode代碼頁進(jìn)行配置，對(duì)于IDS沒有監(jiān)測(cè)的代碼頁，任何Web服務(wù)器都是不受保護(hù)的。
G． UTF-8 空字節(jié)編碼
UTF-8空字節(jié)編碼與UTF-8編碼類似，區(qū)別在于并不適用百分號(hào)進(jìn)行轉(zhuǎn)意，發(fā)送的字節(jié)就是實(shí)際的字節(jié)，如果A被編碼，結(jié)果是：
• 0xC1 0x81 = ‘A’
這種類型的編碼只被微軟的IIS服務(wù)器所支持。
H．微軟％U編碼
微軟的％U編碼使用一種獨(dú)特的方式來對(duì)Unicode碼點(diǎn)值小與65535（或者兩個(gè)字節(jié)）的對(duì)象編碼。格式很簡單，％U后邊是Unicode碼點(diǎn)值的4個(gè)四位值的十六進(jìn)制：
• %UXXXX
例如，大寫A可以編碼成：
• %U0041 = ‘A’
這種編碼被微軟的IIS所支持。
I．不匹配編碼
不匹配編碼使用不同的編碼方法來表示一個(gè)ASCII字符，不過這并不是一種單獨(dú)的編碼。
例如，我們使用微軟的％U編碼方法來對(duì)大寫A進(jìn)行編碼。因?yàn)镮IS要對(duì)URL進(jìn)行雙解碼，我們可以使用其他的方法來對(duì)％U方法進(jìn)行編碼。比如，我們可以對(duì)％U方法中的“U”進(jìn)行十六進(jìn)制編碼。這樣，一個(gè)簡單的％U0041就變成了％％550041。我們也可以對(duì)0041進(jìn)行十六進(jìn)制編碼，或者使用別的編碼方法。下邊是一個(gè)針對(duì)IIS服務(wù)器的更加復(fù)雜的不匹配編碼，使著分析這串字符到底代表什么ASCII字符：
• %U0025%550%303%37
IV． 無效協(xié)議解析
A．使用請(qǐng)求管道來實(shí)現(xiàn)URL躲避
請(qǐng)求管道的躲避方法，是一種無效協(xié)議解析的躲避方法。它使用了HTTP協(xié)議版本1.1的請(qǐng)求管道來使URI更加模糊。
請(qǐng)求管道標(biāo)準(zhǔn)允許Web客戶端在一個(gè)數(shù)據(jù)包中發(fā)送多個(gè)請(qǐng)求，這個(gè)與HTTP的保持連接頭有所不同，不要混淆。請(qǐng)求管道把所有的請(qǐng)求放在一個(gè)包中，而HTTP保持連接是為了保持TCP流一直開放，接受更多的請(qǐng)求。
我們使用請(qǐng)求管道特性在一個(gè)包中嵌入多個(gè)URL。大部分的IDS都能正確解析第一個(gè)URL，但基本上都不能正確解析其余的URL。這為躲避技術(shù)打開了大門，其他的URL雖然
能被服務(wù)器解碼，但是卻被大多數(shù)的IDS忽略。比如，下列的數(shù)據(jù)負(fù)載使用了請(qǐng)求管道的技術(shù)來躲避對(duì)URL的檢測(cè)：
• GET / HTTP/1.1\r\nHost: \r\n\r\nGET /foobar.html \r\nHost: \r\n\r\nGET /cgi%2Dbin%2Fph%66 HTTP/1.1\r\nHost: r\n
B． 使用POST和Content-Encoding參數(shù)進(jìn)行躲避
另一個(gè)在攻擊中包含惡意數(shù)據(jù)的HTTP協(xié)議字段，就是URL的參數(shù)字段。大部分?jǐn)?shù)據(jù)庫和cgi類型的攻擊，都使用了該字段，而大部分的IDS都有相應(yīng)的規(guī)則來檢測(cè)惡意的參數(shù)鍵和參數(shù)值。一種躲避IDS的簡單方法，就是使用與編碼URL相同的技術(shù)來對(duì)參數(shù)進(jìn)行編碼，但大部分的IDS對(duì)參數(shù)字段也進(jìn)行了解碼。我們的方法是：使用POST請(qǐng)求將參數(shù)字段放到HTTP請(qǐng)求頭的末尾。如果參數(shù)字段是名文形式，IDS就能很容易的發(fā)現(xiàn)惡意內(nèi)容，因此我們使用了頭選項(xiàng)，Content-Encoding，對(duì)參數(shù)字段進(jìn)行BASE64編碼。除非IDS對(duì)POST的內(nèi)容也進(jìn)行BASE64解碼，攻擊就有可能不斷進(jìn)行；即使IDS對(duì)POST實(shí)現(xiàn)了BASE64編碼，這也是一個(gè)非常耗時(shí)的過程，因此如果發(fā)送大量包含巨型參數(shù)字段的POST請(qǐng)求，甚至?xí)䦟?duì)IDS造成DOS攻擊。
V．結(jié)論
HTTP IDS躲避技術(shù)有兩大類，分別是無效協(xié)議解析和無效協(xié)議字段編碼。如果IDS對(duì)HTTP協(xié)議字段的編碼類型不了解，就不能正確的解碼URL，攻擊躲避的事件就會(huì)發(fā)生。這也是經(jīng)常討論的編碼技術(shù)。如果IDS對(duì)HTTP缺乏足夠的了解，仍有可能發(fā)生漏報(bào)。請(qǐng)求管道與內(nèi)容編碼躲避技術(shù)就是需要注意的。通過對(duì)IDS協(xié)議解碼的研究發(fā)現(xiàn)，大部分的漏報(bào)都是使用了這兩項(xiàng)技術(shù)。
【兩種基于HTTP的通用IDS躲避技術(shù)】相關(guān)文章：
基于混合TCP-UDP的HTTP協(xié)議實(shí)現(xiàn)方法08-06
工控網(wǎng)中基于Linux的嵌入式HTTP服務(wù)器設(shè)計(jì)08-06
基于混沌圖像的防偽技術(shù)08-06
基于圖像的OMR技術(shù)的實(shí)現(xiàn)08-06
基于Web技術(shù)的網(wǎng)絡(luò)考試系統(tǒng)08-06
基于先驗(yàn)預(yù)知的動(dòng)態(tài)電源管理技術(shù)08-06
基于指紋認(rèn)證技術(shù)的WEB訪問控制08-06