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