黑客針對HTTP請求繞過IDS的八種方式
IDS作為企業(yè)安全防護系統(tǒng)被眾多的企業(yè)所采用，但是安裝IDS系統(tǒng)的企業(yè)也不能徹底的安心，隨著黑客技術(shù)的發(fā)展，許多黑客也可以通過各種方式繞過IDS的檢測，從而對企業(yè)進(jìn)行攻擊，本篇文章主要就介紹黑客在攻擊時通過針對HTTP請求繞過IDS監(jiān)視。
針對HTTP請求以繞過IDS監(jiān)視
㈠URL編碼問題,將URL進(jìn)行編碼，可以避開一些采用規(guī)則匹配的NIDS。
二進(jìn)制編碼中HTTP協(xié)議允許在URL中使用任意ASCII字符，把二進(jìn)制字符表示成形如"%xx" 的十六進(jìn)制碼，有的IDS并不會去解碼。 如"cgi-bin"可以表示成"%63%67%69%2d%62%69%6e"，有些IDS的規(guī)則匹配不出，但web服務(wù)器可以正確處理。不過現(xiàn)在大多數(shù)IDS已經(jīng)是在匹配規(guī)則之前解碼，目前這個手段已經(jīng)不適用了，一般的IDS都可以檢測到的！# %u編碼，是用來代表Unicode/wide特征字符，但微軟IIS web服務(wù)器支持這種非標(biāo)準(zhǔn)的web請求編碼方式由于%u編碼不是標(biāo)準(zhǔn)的編碼，IDS系統(tǒng)不能解碼%u，所以可以繞過IDS的檢測。例如:
我們使用下列的編碼方式就可以繞過一些NIDS對".ida"的攻擊的檢測。
GET /abc.id%u0061 HTTP/1.0
不過，snort1.8可以檢測到這種編碼后的攻擊，但有一些公司的IDS沒注意到這個問題。解決辦法主要就是在規(guī)則匹配前對URL內(nèi)容的%u編碼進(jìn)行解碼后匹配。 #unicode編碼，主要針對IIS，將URL中的一些特定的字符或字符串（主要是針對一些IDS匹配的規(guī)則內(nèi)容）用unicode編碼表示，例如：
我們使用下列的編碼方式就可以繞過一些NIDS對".ida"的攻擊的檢測。
GET /abc.id%c1%01 HTTP/1.0
snort1.8目前好象不能檢測到這種編碼后的攻擊。采用通配符如"*string*"匹配的很多IDS應(yīng)該都存在此類問題。解決辦法就是在規(guī)則匹配前對URL內(nèi)容的unicode編碼進(jìn)行解碼后匹配。
㈡網(wǎng)絡(luò)中斜線問題即"/"和"\"。# "/" 問題：
如果在HTTP的提交的請求中把'/' 轉(zhuǎn)換成 '//'，如"/cgi-bin/test.cgi"轉(zhuǎn)換成"//cgi-bin//test.cgi"，雖然兩個字符串不匹配，但對許多web服務(wù)器的解釋是一樣的。如果把雙斜線換成三斜線或更多效果也是一樣的。目前有些IDS無法檢測到這種類型的請求。 # "\"問題：Microsoft用'\'來分隔目錄，Unix用'/'來分隔，而HTTP RFC規(guī)定用'/'， Microsoft的web服務(wù)器如IIS 會主動把'/' 轉(zhuǎn)換成 '\'。
例如發(fā)送"/cgi-bin\test.cgi"之類的命令，IIS可以正確識別，但這樣IDS就不會匹配"/cgi-bin/test.cgi"了，此法可以逃避一些IDS。
㈢增加目錄問題：
插入一些無用的特殊字符，使其與IDS的檢測內(nèi)容不匹配。 如'..'意思是父目錄，'.'意思是子目錄，window下的"c:\tmp\.\.\.\.\"的意思就是"c:\tmp\"；相應(yīng)的unix下的"/tmp/././././"和"/tmp/"等價。對"/cgi-bin/phf"可以任意變化成"/./cgi-bin/././phf等形式。
例如：
GET /cgi-bin/blahblah/../test.cgi HTTP/1.0實際和"/cgi-bin/test.cgi"一樣
目前一般IDS都能識別。 很多智能的IDS會把請求還原成正常的形式。
㈣不規(guī)則方式問題:
#用tab替換空格（對IIS不適用）：智能的IDS一般在客戶端的數(shù)據(jù)中取出URL請求，截去
變量，然后按照HTTP的語法格式檢查請求。在HTTP RFC 中，http v1.0的請求格式如下：Method URI HTTP/ Version CRLF CRLFHTTP是按照空格來把請求分成三部分的。但是，Apache 1.3.6和其以后的版本（早些時候的版本可能也是）允許用tab去請求：Method URI HTTP/ Version CRLF CRLF這會使那些根據(jù)RFC協(xié)議格式處理這個請求的程序失敗。但有的IDS為了減少誤報會在匹配時用上空格。如"/phf"會很容易在字符串中匹配，但"/phf（空格）"會減少很多誤報， 這時對用tab的請求就沒法匹配了。
# NULL方式：構(gòu)造如下的請求： GET%00 /cgi-bin/test.cgi HTTP/1.0， 由于在C語言中很多字符串處理函數(shù)用NULL作為字符串的結(jié)尾，如果IDS是利用c函數(shù)處理字符串的話，IDS就不可匹配NULL后面的字符串了。這種方式適合IIS，Apache不能處理%00。
㈤命令問題：
許多IDS系統(tǒng)檢測時缺省認(rèn)為客戶提交的請求是用GET提交的，如GET /cgi-bin/test.cgi。但是相同的請求用HEAD命令也能實現(xiàn)，如用HEAD發(fā)送：HEAD /cgi-bin/test.cgi，則有些依靠get方法匹配的IDS系統(tǒng)就不會檢測到這個掃描。
㈥會話組合問題：
把請求分開放在不同的包文中發(fā)出 D D注意不是分片，則IDS可能就不會匹配出攻擊了。例如，請求"GET / HTTP/1.0"可以放在不同的包文中("GE", "T ", "/", " H", "T", "TP", "/1", ".0")，但不能逃過一些采用協(xié)議分析和會話重組技術(shù)的IDS。
㈦長URL（Long URLs）問題：
一些原始的IDS為了提高效率往往只檢查前xx個字節(jié)，通常情況這樣很正確，因為請求是在數(shù)據(jù)的最前面的，但是如果構(gòu)造一個很長的請求：
GET /rfprfprfprfp/../cgi-bin/test.cgi HTTP/1.0，
超過了IDS檢測的長度，這樣就會使IDS檢測不到后面的CGI。通?？梢栽谡埱笾邪?-2K個隨機字符，但是有一些IDS會根據(jù)某些協(xié)議請求的長度來判斷是否是緩沖區(qū)溢出，這時IDS就會對此類掃描誤報為緩沖區(qū)溢出！
㈧虛假的請求結(jié)束問題：
對有些智能的IDS來說，為了提高效率上和減少占有系統(tǒng)資源，對客戶端發(fā)過來的數(shù)據(jù),一般只會處理請求部分。
例如發(fā)送如下請求：
GET /%20HTTP/1.0%0d%0aHeader:%20/../../cgi-bin/test.cgi HTTP/1.0\r\n\r\n
解碼后是這樣的：
GET / HTTP/1.0\r\nHeader: /../../cgi-bin/test.cgi HTTP/1.0\r\n\r\n
這是一個正確的請求，但對某些智能的IDS只會截取GET的命令行，發(fā)現(xiàn)"HTTP/1.0\r\n"后就結(jié)束，然后對截取得部分進(jìn)行操作，所以智能的IDS就不能正確報告基于此cgi的攻擊。
㈨大小寫敏感問題：
DOS/Windows與unix不同，它對大小寫不敏感。例如：對IIS來說使用大小寫是一樣的，對有的老式IDS來說，可能造成不匹配。
針對HTTP請求進(jìn)行欺騙的工具主要是Whisker，它采用了上面的一些技術(shù)進(jìn)行WWW掃描，目前的IDS能發(fā)現(xiàn)絕大部分的欺騙方式，但對于采用URL編碼（尤其是unicode編碼）和不規(guī)則方式（如TAB替換空格）的掃描，有相當(dāng)一部分IDS可能檢測不到！
【編輯推薦】
- 如何構(gòu)建入門級IDS
- IDS漏洞分析與黑客入侵手法
- 測試評估IDS的性能指標(biāo)
- 正確評估IDS性能的標(biāo)準(zhǔn)與步驟
- 企業(yè)測試IDS的四條重要標(biāo)準(zhǔn)
