漏洞掃描技巧篇-Web漏洞掃描器
在很久以前有人提問(wèn) AMF 格式的請求怎么進(jìn)行檢測,或者有什么工具可以檢測。
既然我們要講解的是 Web 漏洞掃描器,那么就先假設是 AMF over HTTP (這里并不需要你了解 AMF,你只需要知道 AMF 是一種數據格式類(lèi)型就行)。
1.先解析 HTTP 中 AMF 格式數據
2.然后在測試參數中填寫(xiě) payload
3.重新封裝 AMF 格式數據
4.發(fā)送 HTTP 請求
整個(gè)流程下來(lái)沒(méi)什么問(wèn)題,但是如果又來(lái)了一個(gè) X 協(xié)議(X over HTTP),那么我們就得繼續修改 SQL 注入模塊以便支持這種 X 協(xié)議,但是掃描器中可不是只有 SQL 注入檢測模塊,還有其他同類(lèi)模塊,難道每加一個(gè)新協(xié)議我還得把所有檢測模塊都改一遍?
所以我們需要把這些協(xié)議解析和封裝單獨抽出來(lái)放在一個(gè)模塊中。
上面的遞歸 decode 主要是為了解碼某種格式的數據里面還有另外一種格式的數據,雖然看起來(lái)這種場(chǎng)景比較少見(jiàn),但是仔細想一下 multipart 帶著(zhù) json,json 里的字符串是另外一個(gè) json 字符串,是不是又覺(jué)得這種情況也并不少見(jiàn)。
因為每個(gè)檢測模塊的檢測依據大致就幾種:
-
返回內容
-
消耗時(shí)間 (time based)
-
另外一條信道的數據 (比方說(shuō) dnslog)
所以即便是我們將網(wǎng)絡(luò )操作剝離出來(lái)也不會(huì )影響檢測的效果。
在編寫(xiě)檢測模塊的時(shí)候,編寫(xiě)者可以不用關(guān)心基礎協(xié)議是什么,怎么對數據編碼解碼,只用關(guān)心根據 value 生成 payload 并填寫(xiě)到相對應的 key 中。
假如某天出現了這么一種流行編碼格式 http://www.cua-kua.com/key1, value1,key2,value2,那我們所有的檢測模塊也無(wú)需修改,僅僅需要在上一層再添加一套 encode/decode 操作即可。假如某天出現了一種比較流行的協(xié)議,我們也僅需要在上一層提供一套 client 即可。檢測模塊的工作就僅僅剩下生成并填寫(xiě) payload。
在 2014 年的時(shí)候,我做了大量的競品分析,包括使用逆向工程逆向商業(yè)的 Acunetix WVS, HP Webinspect, IBM AppScan, Netsparker 掃描邏輯,也包括閱讀開(kāi)源的 w3af, arachni 代碼。
如果不談掃描質(zhì)量,只關(guān)注整體項目設計以及產(chǎn)品中使用到的猥瑣技巧,那么其中最讓我眼前一亮的當屬 AWVS,接下來(lái)我將詳細介紹一下我從 AWVS 中學(xué)習到的 PoC 分類(lèi)。
PoC 分類(lèi):
類(lèi)型 | 描述 |
---|---|
PerServer | 用于檢測 Web Server 級別中存在的漏洞,比方說(shuō)各種中間件,Web 框架的漏洞 |
PerFile | 用于檢測某個(gè)文件中是否存在漏洞,比如對應文件的備份,Bash RCE 等 |
PerFolder | 用于檢測某個(gè)目錄中是否存在漏洞,比如敏感信息的泄漏,路徑中的 SQL 注入等 |
PerScheme | 用于檢測某個(gè)參數中是否存在漏洞,比如 SQL 注入,XSS 等 |
PostCrawl | 在爬蟲(chóng)結束之后啟動(dòng),直接使用爬蟲(chóng)的資源進(jìn)行檢測 |
PostScan | 在掃描結束之后啟動(dòng),用于檢測二階注入,存儲 XSS等 |
WebApps | 用于檢測比較常用的 Web 應用的漏洞 |
在獲取到爬蟲(chóng)資產(chǎn),對相關(guān)資產(chǎn)格式化之后,便下發(fā)到各個(gè)不同類(lèi)型的 PoC 中進(jìn)行檢測,這樣做的好處是分類(lèi)明確,覆蓋大多數檢測階段,也避免為了減少重復請求的下發(fā)而需要額外記錄中間狀態(tài)的行為。
AWVS 有個(gè)比較有趣的功能 AcuMonitor ,也就大家熟知的 dnslog、反連平臺。在 2014 年看到 AWVS 的這個(gè)功能時(shí),就建議 WooYun 出個(gè)類(lèi)似的功能,也就是 cloudeye,tangscan 也就算是國內比較早使用這種技術(shù)的掃描器,當然后續又出現了各種類(lèi)似 cloudeye 的項目,自然而然也出現了各種使用該技術(shù)的掃描器。
不過(guò)今天我們不打算繼續介紹 AcuMonitor,而是介紹另外一個(gè)也很有趣的功能 AcuSensor 。AcuSensor 就是IAST,只要稍微了解過(guò) Web 漏洞掃描器的,都應該會(huì )知道 IAST 是干啥的。那為什么我要單獨拎出來(lái)講這個(gè)呢?
主要是因為 AcuSensor 的實(shí)現方式非常有趣。AcuSensor 提供了 Java、 .NET、PHP 這三個(gè)語(yǔ)言版本,其中比較有趣的是 PHP 版本的實(shí)現。
PHP版本的AcuSensor使用方法是下載一個(gè)acu_phpaspect.php文件,再通過(guò) auto_prepend_file 加載這個(gè)文件, 眾所周知,PHP 是不能改直接 hook PHP 內置函數的,那么單單依靠一個(gè) PHP 腳本,AcuSensor是如何做到類(lèi)似 IAST 功能的呢?
很簡(jiǎn)單,直接替換所有關(guān)鍵函數。嗯,真的就那么簡(jiǎn)單。
我們來(lái)詳細介紹一下這個(gè)過(guò)程,在 acu_phpaspect.php 中:
1.獲取用戶(hù)實(shí)際請求的文件內容
2.檢查一下有沒(méi)有相關(guān) cache,如果有 cache 那么直接加載執行 cache,然后結束
3.使用 token_get_all
獲取所有 token遍歷每一個(gè) token,對自己感興趣的函數或者語(yǔ)句使用自己定義的函數進(jìn)行 wrap 并替換
4.將替換后的內容保存到 cache 中并使用 eval 執行
5.__halt_compiler
中斷編譯
整個(gè)過(guò)程簡(jiǎn)單粗暴有效,這樣做的優(yōu)點(diǎn)在于:
-
實(shí)現簡(jiǎn)單,只需要編寫(xiě) PHP 即可
-
安裝簡(jiǎn)單,無(wú)需安裝擴展,只需修改配置文件可以
-
兼容性強,比較容易兼容性各種環(huán)境,各種版本 PHP
AcuSensor
的實(shí)現。如果對自己實(shí)現的檢測邏輯效率比較自信的話(huà),甚至可以基于這個(gè)原理直接實(shí)現一個(gè) PHP 版本的 RASP 項目。在 Web 漏洞掃描器中,無(wú)論作為乙方的商業(yè)產(chǎn)品、甲方的自研產(chǎn)品,限速都是一個(gè)至關(guān)重要的功能,甚至可以說(shuō)如果你的掃描器沒(méi)有限速功能,那壓根就不能上線(xiàn)使用。接下來(lái)我們將介紹一下在掃描器中限速的幾種方法。
1.代理
使用代理做限速功能,將所有執行掃描任務(wù)的 worker 的測試流量全轉發(fā)proxy 服務(wù)器上:
由 proxy 服務(wù)器統一調度發(fā)送測試請求頻率,直接使用 proxy 方案優(yōu)點(diǎn)是可以兼容之前沒(méi)做限速功能的掃描器,缺點(diǎn)是所有基于 time based 的檢測均無(wú)效(當然也可以讓 proxy 返回真正的響應時(shí)間來(lái)進(jìn)行判斷,不過(guò)仍需要修改檢測模塊),也不允許在檢測模塊中加入超時(shí)設置。
2.雙重隊列
另外一種方法是使用雙重隊列實(shí)現限速功能,流程圖如下:
1. worker1 從隊列中取到名為 target1 的任務(wù)
2. worker1 從 target1 隊列中取出和 target1 相關(guān)的任務(wù)
3. 默認單并發(fā)執行和 target1 相關(guān)任務(wù),根據設置的 QPS 限制,主動(dòng) sleep 或者增加并發(fā)
這種方案的缺點(diǎn)是掃描器設計之初的時(shí)候就得使用這種方法,優(yōu)點(diǎn)是每個(gè)并發(fā)可以穩定的和遠程服務(wù)器保持鏈接,也不影響掃描功能。
實(shí)際上這一節并不會(huì )講具體某個(gè)漏洞檢測方法,只是簡(jiǎn)單談一下漏掃模塊每個(gè)階段該干的事情。
項目之初,沒(méi)有相關(guān)積累,那么可以選擇看一下 AWVS 的檢測代碼,雖然說(shuō)網(wǎng)上公開(kāi)的是 10.5 的插件代碼,但其實(shí)從 8.0 到 11 的插件代碼和 10.5 的也差不多,無(wú)非新增檢測模塊,修復誤漏報的情況,也可以多看看 SQLMap 代碼,看看檢測邏輯,但是千萬(wàn)不要學(xué)習它的代碼風(fēng)格。從這些代碼中可以學(xué)習到非常多的小技巧,比如動(dòng)態(tài)頁(yè)面檢測,識別 404 頁(yè)面等??创a很容易理解相關(guān)的邏輯,但我們需要去理解為什么代碼這樣處理,歷史背景是什么,所以多用 git blame。
如果掃描器是自己的一個(gè)開(kāi)源項目的話(huà),那么就必須適當的推廣自己的項目,讓更多的人去使用、反饋,然后才能繼續完善項目,從而繼續推廣自己的項目,這是一個(gè)循環(huán)的過(guò)程??偠灾?,提升漏洞檢測的精準度需要兩個(gè)條件:1. bad case,2. 維護精力
到了后期,各種常規的漏洞檢測模塊已經(jīng)實(shí)現完成,也有精力持續提升檢測精準度,日常漏洞 PoC 也有人員進(jìn)行補充。
當然除了完善資產(chǎn)收集這塊,還有輔助提升檢測效果的事情,比如說(shuō)上面提到的 AcuSensor
,這部分事情可以結合公司內部的 RASP 做到同樣效果,還有分析 access log、數據庫 log 等事情??偟膩?lái)說(shuō),做漏掃沒(méi)有什么條條框框限制,只要能發(fā)現漏洞就行。
以上都是和技術(shù)相關(guān)的事情,做漏掃需要處理的事情也不僅僅只有技術(shù),還需要去搞定詳細可操作的漏洞描述及其解決方案,匯報可量化的指標數據,最重要的是擁有有理有據、令人信服的甩鍋技巧。
以上即是我認為在掃描器中比較有用且能夠公開(kāi)的小技巧,希望能夠對你有所幫助。