經(jīng)過這么長時間的測試終于算是可以上線了，寫篇文章跟大家分享一下自己的開發(fā)思路吧
注：本工具借鑒吸收了TideSec的web_pwd_common_crack很多優(yōu)秀的思路，在此基礎上增加了很多拓展功能使其更加強大，在這里給TideSec的大佬點個贊！
前言
在做安全測試的時候，隨著資產(chǎn)的增多，經(jīng)常會遇到需要快速檢測大量網(wǎng)站后臺弱口令的問題。
然而市面上并沒有一個比較好的解決方案，能夠支持對各種網(wǎng)站后臺的通用檢測。
所以WebCrack就應運而生。
工具簡介
WebCrack是一款web后臺弱口令/萬能密碼批量爆破、檢測工具。
不僅支持如discuz，織夢，phpmyadmin等主流CMS
并且對于絕大多數(shù)小眾CMS甚至個人開發(fā)網(wǎng)站后臺都有效果
在工具中導入后臺地址即可進行自動化檢測。
實現(xiàn)思路
大家想一下自己平常是怎么用burpsuite的intruder模塊來爆破指定目標后臺的
抓包 -> send to intruder -> 標注出要爆破的參數(shù) -> 發(fā)送payload爆破 -> 查看返回結(jié)果
找出返回包長度大小不同的那一個，基本上就是所需要的答案。
那么WebCrack就是模擬這個過程
但是就要解決兩個問題
如何自動識別出要爆破的參數(shù)
如何自動判斷是否登錄成功
識別爆破參數(shù)
對于這個問題采用了web_pwd_common_crack的解決辦法
就是根據(jù)提取表單中 user pass 等關(guān)鍵字，來判斷用戶名跟密碼參數(shù)的位置
if parameter:
if not user_key:
for z in [ 'user', 'name','zhanghao', 'yonghu', 'email', 'account']:
if z in parameter.lower():
value = '{user_name}'
user_key = parameter
ok_flag = 1
break
if not ok_flag:
for y in ['pass', 'pw', 'mima']:
if y in parameter.lower():
value = '{pass_word}'
pass_key = parameter
ok_flag = 1
break
但是在測試中還發(fā)現(xiàn)，有些前端程序員用拼音甚至拼音縮寫來給變量命名
什么yonghu , zhanghao , yhm(用戶名), mima 等
雖然看起來很捉急，但是也只能把它們?nèi)考舆M關(guān)鍵字判斷名單里。
如何判斷登錄成功
這個可以說是最頭疼的問題
如果對于一種管理系統(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)一的閾值來判斷，故舍棄。
關(guān)鍵字黑名單檢測
黑名單關(guān)鍵字列表
['密碼錯誤', '重試', '不正確', '密碼有誤','不成功', '重新輸入', 'history.back', '不存在', '登錄失敗',
'登陸失敗','出錯','已被鎖定','history.go','安全攔截','還可以嘗試','無效','攻擊行為','創(chuàng)宇盾', '非法',
'百度加速','安全威脅','防火墻','黑客', '不合法','warning.asp?msg=','Denied']
本來還設置了白名單檢測機制
就是如果有“登錄成功”的字樣出現(xiàn)肯定就是爆破成功
但是后來發(fā)現(xiàn)并沒有黑名單來的必要。
因為首先不可能把所有CMS的登錄成功的正則樣本都放進去
其次在測試的過程中，發(fā)現(xiàn)在其他檢測機制的加持后，白名單的判斷變得尤其雞肋，故舍棄。
黑名單就相比而言好的多
如果彈出來"密碼錯誤"，就不用再往下判斷了
然而實際測試中發(fā)現(xiàn)有些用js來判斷登錄的情況的時候，會同時出現(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)字典
實現(xiàn)代碼
def gen_dynam_dic(url):
dynam_pass_dic = []
tmp_dic = []
suffix_dic = ['', '123', '888', '666', '123456']
list1 = url.split('/')
host = list1[2].split(":")[0]
compile_ip = re.compile('^(1\d{2}|2[0-4]\d|25[0-5]|[1-9]\d|[1-9])\.(1\d{2}|2[0-4]\d|25[0-5]|[1-9]\d|\d)\.(1\d{2}|2[0-4]\d|25[0-5]|[1-9]\d|\d)\.(1\d{2}|2[0-4]\d|25[0-5]|[1-9]\d|\d)$')
if compile_ip.match(host):
check_ip = 1
else:
check_ip = 0
if not check_ip:
list2 = host.split(".")
i = len(list2)
for u in range(i):
list3 = list2[u:]
part = '.'.join(list3)
if (len(part) < 5):
continue
dynam_pass_dic.append(part)
for u in range(i):
list3 = list2[u]
if len(list3) < 5:
continue
tmp_dic.append(list3)
for i in tmp_dic:
for suffix in suffix_dic:
u = i + suffix
dynam_pass_dic.append(u)
return dynam_pass_dic
else:
return ''
假如域名是
webcrack.yzddmr6.com
那么就會生成以下動態(tài)字典列表
webcrack.yzddmr6.com
yzddmr6.com
webcrack
webcrack123
webcrack888
webcrack666
webcrack123456
yzddmr6
yzddmr6123
yzddmr6888
yzddmr6666
yzddmr6123456
假如正則匹配到傳來的是一個IP而不是域名的話就會返回一個空列表。
萬能密碼檢測
后臺的漏洞除了弱口令還有一大部分是出在萬能密碼上
在WebCrack中也添加了一些常用的payload
admin' or 'a'='a
'or'='or'
admin' or '1'='1' or 1=1
')or('a'='a
'or 1=1--
但是同時帶來個問題會被各大WAF攔截
這時候就可以把WAF攔截的關(guān)鍵字寫到檢測黑名單里，從而大大減少誤報。
小插曲
用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ù)說明
[
{
"name":"這里是cms名稱",
"keywords":"這里是cms后臺頁面的關(guān)鍵字,是識別cms的關(guān)鍵",
"captcha":"1為后臺有驗證碼，0為沒有。因為此版本并沒有處理驗證碼，所以為1則退出爆破",
"exp_able":"是否啟用萬能密碼模塊爆破",
"success_flag":"登錄成功后的頁面的關(guān)鍵字",
"fail_flag":"請謹慎填寫此項。如果填寫此項，遇到里面的關(guān)鍵字就會退出爆破，用于dz等對爆破次數(shù)有限制的cms",
"alert":"若為1則會打印下面note的內(nèi)容",
"note":"請保證本文件是UTF-8格式，并且請勿刪除此說明"
}
]
舉個例子
{
"name":"discuz",
"keywords":"admin_questionid",
"captcha":0,
"exp_able":0,
"success_flag":"admin.php?action=logout",
"fail_flag":"密碼錯誤次數(shù)過多",
"alert":0,
"note":"discuz論壇測試"
}
其實對于dz,dedecms,phpmyadmin等框架本身的邏輯已經(jīng)可以處理
添加配置文件只是因為程序默認會開啟萬能密碼爆破模塊
然而萬能密碼檢測會引起大多數(shù)WAF封你的IP
對于dz，dedecms這種不存在萬能密碼的管理系統(tǒng)如果開啟的話不僅會影響效率，并且會被封IP
所以配置文件里提供了各種自定義參數(shù)，方便用戶自己設置。
關(guān)于驗證碼
驗證碼識別算是個大難題吧
自己也寫過一個帶有驗證碼的demo，但是效果并不理想
簡單的驗證碼雖然能夠識別一些，但是遇到復雜的驗證碼就效率極低，拖慢爆破速度
并且你識別出來也不一定就有弱口令。。。
所以就去掉了這個功能
如果有大佬對這方面有好的想法，歡迎在github上留言或者郵箱 yzddmr6@gmail 聯(lián)系我。
總流程圖
一套流程下來大概是長這個亞子
對比測試
找了一批樣本測試，跟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)字典探測出來的弱口令。
最后
這個項目斷斷續(xù)續(xù)寫了半年吧
主要是世界上奇奇怪怪的網(wǎng)站太多了，后臺登錄的樣式五花八門。
有些是登錄后給你重定向302到后臺
有些是給你重定向到登錄失敗頁面
有些是給你返回個登錄成功，然后你要手動去點跳轉(zhuǎn)后臺
有些直接返回空數(shù)據(jù)包。。。
更神奇的是ecshop(不知道是不是所有版本都是這樣)
假如說密碼是yzddmr6
但是你輸入admin888 與其他錯誤密碼后的返回頁面居然不一樣。。。
因為加入了萬能密碼模塊后經(jīng)常有WAF攔截，需要測試各個WAF對各個系統(tǒng)的攔截特征以及關(guān)鍵字。
總的半年下來抓包抓了上萬個都有了。。。。。。
因為通用型爆破，可能無法做到百分百準確，可以自己修改配置文件來讓webcrack更符合你的需求。
