前言

　　在做安全測試的時候，隨著資產(chǎn)的增多，經(jīng)常會遇到需要快速檢測大量網(wǎng)站后臺弱口令的問題。

　　然而市面上并沒有一個比較好的解決方案，能夠支持對各種網(wǎng)站后臺的通用檢測。

　　所以WebCrack就應運而生。

　　工具簡介

　　WebCrack是一款web后臺弱口令/萬能密碼批量爆破、檢測工具。

　　不僅支持如discuz，織夢，phpmyadmin等主流CMS

　　并且對于絕大多數(shù)小眾CMS甚至個人開發(fā)網(wǎng)站后臺都有效果。

　　在工具中導入后臺地址即可進行自動化檢測。

　　實現(xiàn)思路

　　大家想一下自己平常是怎么用burpsuite的intruder模塊來爆破指定目標后臺的

　　找出返回包長度大小不同的那一個，基本上就是所需要的答案。

　　那么WebCrack就是模擬這個過程

　　但是就要解決兩個問題

　　如何自動識別出要爆破的參數(shù)

　　如何自動判斷是否登錄成功

　　識別爆破參數(shù)

　　對于這個問題采用了web_pwd_common_crack的解決辦法

　　就是根據(jù)提取表單中 user pass 等關鍵字，來判斷用戶名跟密碼參數(shù)的位置

　　但是在測試中還發(fā)現(xiàn)，

　　有些前端程序員用拼音甚至拼音縮寫來給變量命名

　　什么yonghu , zhanghao , yhm(用戶名), mima 等

　　雖然看起來很捉急，但是也只能把它們?nèi)考舆M關鍵字判斷名單里。

　　如何判斷登錄成功

　　這個可以說是最頭疼的問題

　　如果對于一種管理系統(tǒng)還好說，只要找到規(guī)律，判斷是否存在登錄成功的特征就可以

　　但是作為通用爆破腳本來說，世界上的網(wǎng)站各種各樣，不可能去一個個找特征，也不可能一個個去正則匹配。

　　經(jīng)過借鑒web_pwd_common_crack的思路，與大量測試

　　總結(jié)出來了以下一套比較有效的判斷方式。

　　判斷是否動態(tài)返回值并獲取Error Length

　　先發(fā)送兩次肯定錯誤的密碼如length_test

　　獲取兩次返回值并比較

　　如果兩次的值不同，則說明此管理系統(tǒng)面對相同的數(shù)據(jù)包返回卻返回不同的長度，此時腳本無法判斷，退出爆破。

　　如果相同，則記錄下此值，作為判斷的基準。

　　然而實際中會先請求一次，因為發(fā)現(xiàn)有些管理系統(tǒng)在第一次登錄時會在響應頭部增加標記。如果去掉此項可能會導致判斷失誤。

　　判斷用戶名跟密碼的鍵名是否存在在跳轉(zhuǎn)后的頁面中

　　這個不用過多解釋，如果存在的話說明沒登錄成功又退回到登錄頁面了。

　　有人會問為什么不直接判斷兩個頁面是否相等呢

　　因為測試中發(fā)現(xiàn)有些CMS會給你在登錄頁面彈個登錄失敗的框，所以直接判斷是否相等并不準確。

　　還有一種計算頁面哈希的辦法，然后判斷兩者的相似程度。

　　但是覺得并沒有那個必要，因為有不同的系統(tǒng)難以用統(tǒng)一的閾值來判斷，故舍棄。

　　關鍵字黑名單檢測

　　本來還設置了白名單檢測機制

　　就是如果有“登錄成功”的字樣出現(xiàn)肯定就是爆破成功

　　但是后來發(fā)現(xiàn)并沒有黑名單來的必要。

　　因為首先不可能把所有CMS的登錄成功的正則樣本都放進去

　　其次在測試的過程中，發(fā)現(xiàn)在其他檢測機制的加持后，白名單的判斷變得尤其雞肋，故舍棄。

　　并且黑名單的設置對于萬能密碼爆破模塊很有好處，具體往下看吧。

　　Recheck環(huán)節(jié)

　　為了提高準確度，防止誤報。

　　借鑒了web_pwd_common_crack的思路增加recheck環(huán)節(jié)。

　　就是再次把crack出的賬號密碼給發(fā)包一次，并且與重新發(fā)送的error_length作比對

　　如果不同則為正確密碼。

　　在這里沒有沿用上一個error_length，是因為在實際測試中發(fā)現(xiàn)由于waf或者其他因素會導致返回包長度值變化。

　　框架拓展

　　用上面幾種辦法組合起來已經(jīng)可以做到基本的判斷算法了

　　但是為了使WebCrack更加強大，我又添加了以下三個模塊

　　動態(tài)字典

　　這個不用過多解釋，很多爆破工具上都已經(jīng)集成了。

　　假如沒有域名，正則檢測到遇到IP的話就會返回一個空列表。

　　假如域名是

　　那么就會生成以下動態(tài)字典列表

　　后綴可以自己在腳本中定義。

　　萬能密碼檢測

　　后臺的漏洞除了弱口令還有一大部分是出在萬能密碼上

　　在WebCrack中也添加了一些常用的payload

　　可以自行在腳本里添加更多payload。

　　但是同時帶來個問題會被各大WAF攔截

　　這時候黑名單就派上用場啦

　　可以把WAF攔截的關鍵字寫到檢測黑名單里，從而大大減少誤報。

　　小插曲

　　用webcrack檢測目標資產(chǎn)進入到了recheck環(huán)節(jié)

　　但是webcrack卻提示爆破失敗。

　　手工測試了一下檢測出的萬能密碼

　　發(fā)現(xiàn)出現(xiàn)了sql錯誤信息

　　意識到可能存在后臺post注入

　　發(fā)現(xiàn)了sa注入點

　　這也反應了對于后臺sql注入，webcrack的正則匹配還做的不夠完善，下一個版本改一下。

　　自定義爆破規(guī)則

　　有了上面這些機制已經(jīng)可以爆破大部分網(wǎng)站后臺了

　　然而還是有一些特(sha)殊(diao)網(wǎng)站，并不符合上面的一套檢測算法

　　于是webcrack就可以讓大家自定義爆破規(guī)則。

　　自定義規(guī)則的配置文件放在同目錄cms.json文件里

　　參數(shù)說明

　　舉個例子

　　其實對于dz,dedecms,phpmyadmin等框架本身的邏輯已經(jīng)可以處理

　　添加配置文件只是因為程序默認會開啟萬能密碼爆破模塊

　　然而萬能密碼檢測會引起大多數(shù)WAF封你的IP

　　對于dz，dedecms這種不存在萬能密碼的管理系統(tǒng)如果開啟的話不僅會影響效率，并且會被封IP

　　所以配置文件里提供了各種自定義參數(shù)，方便用戶自己設置。

　　關于驗證碼

　　驗證碼識別算是個大難題吧

　　自己也寫過一個帶有驗證碼的demo，但是效果并不理想

　　簡單的驗證碼雖然能夠識別一些，但是遇到復雜的驗證碼就效率極低，拖慢爆破速度

　　并且你識別出來也不一定就有弱口令。。。

　　所以就去掉了這個功能

　　總流程圖

　　一套流程下來大概是長這個亞子

　　對比測試

　　找了一批樣本測試，跟tidesec的版本比較了一下

　　web_pwd_common_crack 跑出來11個

　　其中7個可以登錄。4個是邏輯上的誤報，跟waf攔截后的誤報。

　　webcrack 跑出來19個

　　其中16個可以登錄。2個是ecshop的誤報，1個是小眾cms邏輯的誤報。

　　webcrack比web_pwd_common_crack多探測出來的9個中

　　有5個是萬能密碼漏洞，2個是發(fā)現(xiàn)的web_pwd_common_crack的漏報，2個是動態(tài)字典探測出來的弱口令。

　　世界上奇奇怪怪的網(wǎng)站太多了，后臺登錄的樣式五花八門。

　　有些是登錄后給你重定向302到后臺

　　有些是給你重定向到登錄失敗頁面

　　有些是給你返回個登錄成功，然后你要手動去點跳轉(zhuǎn)后臺

　　有些直接返回空數(shù)據(jù)包。。。

　　更神奇的是ecshop(不知道是不是所有版本都是這樣)

　　假如說密碼是yzddmr6

　　但是你輸入admin888 與其他錯誤密碼后的返回頁面居然不一樣。。。

　　因為加入了萬能密碼模塊后經(jīng)常有WAF攔截，需要測試各個WAF對各個系統(tǒng)的攔截特征以及關鍵字。

　　總的半年下來抓包抓了上萬個都有了。

　　因為通用型爆破，可能無法做到百分百準確，可以自己修改配置文件來讓webcrack更符合你的需求。