0x00 背景

---

之前wooyun上經常也看到一些bypass的方法，如利用mysql的特性bypass web程式的防注入函式，又例如直接構造繞過防注入的正則等等。最近在編寫IPS特徵的時候，發現在一些其他的角度上可以做到繞過IPS防護，下面就將這些另外的角度做一個總結。在描述的時候涉及到一些網路層面的基礎知識，這裡不單獨敘述，在利用姿勢裡面強調。

Ps.此處說明，方法不代表能bypass掉所有的IPS。

0x01 bypass姿勢

---

IPS效能最佳化導致IPS規則bypass

---

做過IPS測試的選手應該都會聽到過這樣一句話，廠商在保證檢測率90%的條件下，效能是多少。這裡所說的效能一般是效能測試中涉及的新建，併發，吞吐等等指標。此處不敘述這些指標。

從上面可以看出IPS的檢測效果和效能是有一個平衡關係的。先來描述一些基本概念，第一個概念是資料流和會話的概念：

在網路基礎中有五元組的概念，即為源地址，目的地址，源埠，目的埠以及協議號，五元組相同即認為是一條同樣的會話，當你在瀏覽器中訪問www.wooyun.org的時候，開啟wireshark抓包工具抓包，然後follow下這一條stream可以發現如下內容。這也就是所描述的會話和流。

IPS中一般是透過會話，流來進行檢測的。如何來透過會話來檢測呢，這裡有第二個概念需要了解，第二個概念為重組：

為什麼要重組，一個乙太網包的最大長度為1518位元組，譬如我們這時候傳送一個大附件出去，此時就會把資料分成多個資料包傳送出去，資料包在internet上轉發的時候會被路由轉發，在整個internet中轉發的時候會出現亂序，導致有些資料包先到IPS裝置，有些資料包後到IPS裝置，此時就需要IPS將傳送的資料包，完整的組合起來。因為組合起來之後才可以方便後面的資料分析，提取內容。如下圖所示：

現在問題就來了，如果對於每條資料流的所有內容都做檢測應該就沒問題了，但是每條資料流的所有內容都進行檢測，肯定所耗費的資源也就越多，應該大部分廠商不會檢測資料流的所有包。因此就會出現個問題，到底檢測多大的大小呢？在處理這個問題的時候有些使用的是包數，有些使用的是流大小的方法。但是這都會導致所說的一個問題，就是效能最佳化導致的bypass。如下圖所示：

在該資料流中，前面多個包如20個包沒有發現特徵，20個包之後的內容不再做ips檢測，這樣後面的包裡的特徵就沒有受到IPS引擎的檢測。

利用：

例如我們在繞過bypass的時候，人為的將get方式提交改為post方式提交，同時在提交的時候，新增大量的填充資料，如使用post的方式，上傳一個大的檔案，雖然這部分填充資料不會被伺服器端所處理，但是在透過IPS裝置的時候就會被解析處理，有可能就bypass掉了ips的檢測。

截斷繞過IPS規則

---

Ips規則即為經常說到的ips特徵，見到過的很多IPS特徵都是根據不同協議來分的，如http,smtp,pop3,tcp,udp等等，每一種協議下又可以有不同的內容，如http協議下可以有cookie，header，msgbody等等。

這些特徵都會被以一種演算法載入到記憶體中，然後等到資料流解析完畢之後，進行匹配。因此這裡又涉及到了一個基礎概念：協議解析。

協議解析為啥？即將上面重組過後的資訊，提取相應的內容賦值給協議變數。打個比方，如http協議，在重組完成之後肯定會出現http標準的內容，http的cookie，header，method等等，因此IPS會根據標準的內容解析，然後將解析的內容賦值給類似http_cookie,http_method的變數。有了這些變數就可以對資料流進行IPS特徵匹配了。效果如下圖所示：

解析出來各種http的相關內容，當然不同的協議解析出來的內容不相同，有的可能是smtp，tcp等等。

但是在這個過程中，如果程式設計師處理的不好，就會出現IPS bypass的情況。

舉個例子，例如某漏洞的特徵為search{xxxx}，特徵利用正則編寫，需要匹配search{}，括號內容隨意，此時，攻擊者提交search{sada%00}，這樣在協議解析的時候出來的結果是search{sada，不會匹配到後面的}符號，導致了bypass。

編碼繞過IPS規則

---

url編碼繞過IPS規則同樣存在可能性。

在IPS中對於同一種協議可能有多種協議變數，如HTTP中可能有沒有url_decode的協議變數和進行了url_decode的協議變數，如果沒有正確使用也會導致IPS規則繞過。

瀏覽器在傳送資料包的時候，會對url進行編碼，而且不同瀏覽器的編碼還不相同，例如chrome對於單引號編碼為%27，但是IE瀏覽器對於單引號不做編碼，同時瀏覽器對於英文字元都不做編碼的。

之前碰到了一個例子，在IPS規則中，書寫特徵的人員使用了未解碼的協議變數書寫特徵，如特徵為包含search關鍵字，此時我們可以這樣bypass規則，將search書寫為%73earch，這樣當資料包經過IPS裝置的時候，內容未作解碼還是為%73earch，未匹配上規則，而到伺服器端時候，被解碼為search。

因此這裡說，在做web測試的時候，儘量編碼一些英文字元提交，可能會有驚喜。

請求方式繞過IPS規則

---

http常用請求方式有GET和POST兩種方式，POST提交的時候又常見的有www/urlencode的方式和multipart的方式，後者常常用於檔案上傳。 檢視一些CMS的原始碼，經常會發現有類似的程式碼，如下程式碼摘抄自dedecms：

#!php
if (!defined('DEDEREQUEST')) 
{
    //檢查和註冊外部提交的變數
    foreach($_REQUEST as $_k=>$_v)
    {
        if( strlen($_k)>0 && preg_match('/^(cfg_|GLOBALS)/',$_k) )
        {
            exit('Request var not allow!');
        }
    }
    foreach(Array('_GET','_POST','_COOKIE') as $_request)
    {
        foreach($$_request as $_k => $_v) ${$_k} = _RunMagicQuotes($_v);
    }
}

可以看出無論get提交，cookie提交，post提交對於web伺服器端，其實效果是一樣的，但是對於IPS就不一樣了。在我接觸的不同的IPS中，對於不同http請求部分，擁有不同的協議變數，同時不同的協議變數也有解碼和未解碼之分。

舉例，如dedecms中的一個漏洞，uploadsafe.inc.php介面的錯誤過濾導致recommend.php頁面可以sql注入。網上給出的POC通常是一個url，直接貼上到瀏覽器，即可以獲取到了管理員賬號密碼，因此一些IPS規則通常就直接書寫了一個httpurl解碼的規則。

很容易此處更換一下提交方式，使用post的方式，無論是urlencode的方式還是form-data的方式，均可以繞過該規則。

此處如果發現post方式被過濾了，此處對於post的內容進行編碼，然後再提交，仍然存在可以繞過的可能。

因此各位在編寫payload的時候儘量使用編碼過的post方式提交，成功的機率大一點。

Ps.之前wooyun上看見有提交二進位制檔案混淆繞過的，此處暫時沒有想到為什麼。

其他方式繞過IPS規則

---

1：對於host以及useraget的修改 一般不要使用預設的useragent，如使用一些自定義或則模擬瀏覽器的http-header欄位。如那些sqlmap的特徵可能就是針對於useragent做的文章。

2：字元混淆 儘量不使用網上公開的poc，針對於一些payload中可控的部分做字元混淆，使用字元填充等等。

3：漏洞利用方式 例如之前報過dedecms的recommend的注入漏洞，該漏洞是因為uploadsafe.inc.php介面導致的，其實利用頁面還有flink.php等等，網上利用的最多recommend的poc，因此使用flink.php的頁面可能就繞過了dedecms ips特徵的防禦，又如牛B的dedesql.class.php的變數覆蓋漏洞，網上大多poc是基於download.php的，其實erraddsave.php等其他頁面也是可以利用的，使用一些非主流POC的利用頁面，也是可以bypass掉ips特徵的。 一般的IPS特徵都與基於一個頁面來寫特徵，避免誤報的。

0x02 總結

---

IPS和WAF網路攻擊的防護裝置，往往為了自身的一些如效能的提升，而放棄了一些功能，例如我見過有些IPS規則在編寫的時候不支援正規表示式。可能就是正規表示式匹配的時候會大大的影響效能。由於這些功能上的放棄，必然導致各種各樣規則的bypass，作為使用者既需要這些防護裝置，同時也需要做好自身網路安全的提升，如伺服器的補丁，相關伺服器的實時監控等等。