1. 程式人生 > >挖洞思路 | 賬號攻擊的幾種常見手法

挖洞思路 | 賬號攻擊的幾種常見手法

開始 混淆 xxxx 很多 coo obi 現在 破密碼 如果

web 安全事件中,賬號,通常是呈現給攻擊者的第一接觸點,與賬號相關的功能若存在缺陷,攻擊者可以此獲取關鍵信息和重要功能,如,登錄失敗的報錯信息可判斷出是否因賬號不存在所致,可被利用枚舉有效賬號,比如,登錄試錯無次數限制,可導致暴破密碼,又如,註冊流程各步驟未嚴格關聯,導致批量註冊任意賬號,再如,密碼找回功能各步驟未嚴格關聯,導致任意賬號密碼重置。

我在日常滲透時遇到個同時存在這幾類問題的網站 https://www.xxxx.com/,該網站為某電商平臺,合理結合幾類問題,當時已拿到管理員權限,漏洞現已提交並確認修復,思路分享給大家。

開始之前,說個習慣,很多網站分了 PC 版本和手機版本,手機版常為功能裁減,相應安全防禦也較弱,“柿子專挑軟的捏”,所以,我會先盡可能找出該網站的手機版。具體而言,我習慣先用手機直接訪問,服務端自動將跳轉至手機版,提取手機版的訪問地址;如果覺得手機上輸入 URL 麻煩,你可以安裝 firefox 的 useragent-switcher(https://mybrowseraddon.com/useragent-switcher.html)擴展,模擬手機終端進行訪問;當然,其他手段也可考慮,你可以通過子域名枚舉工具 Sublist3r(https://github.com/aboul3la/Sublist3r)找到類似 https://m.xxxx.com/ 的手機版本,也可以通過路徑枚舉工具 dirsearch(https://github.com/maurosoria/dirsearch)找到類似 https://www.xxxx.com/wap 的手機版本,還可以通過 google hacking (inurl:xxxx.com 移動端)找到類似 https://www.xxxx.com/mobile。


賬號可枚舉

在登錄頁面 https://www.xxxx.com/Wap/User/login 輸入賬號、密碼:

技術分享圖片

提交後攔截請求,若賬號不存在則服務端應答為:

技術分享圖片

若賬號存在則服務端應答為:

技術分享圖片

分析發現,雖然應答很類似,但還是有區別,有效賬號比無效賬號多了個“您”,或者,從應答體的長度也能判斷出該賬號是否有效。同時,服務端未限制高頻訪問,所以,可枚舉有效賬號。

將 mobile 參數值定為枚舉變量、以常見國人姓名拼音 top500 和常見後臺賬號作為字典,在枚舉結果中用,應答包長度為 561 的均為有效賬號:

技術分享圖片

其中,既有 chenying、chenyun 這類普通賬號,也有 admin、ceshi 這類後臺賬號,結果存為 username.txt:

技術分享圖片


密碼可暴破

服務端有密碼試錯上限的機制,錯誤 5 次則一小時內禁止登錄:

技術分享圖片

查看登錄請求:

技術分享圖片

logintime 參數名和參數值引起我註意,剛好也是試錯上限 5,嘗試將值其改為 4 後,服務器又正常響應,或者,刪除整改 logintime 後,也可繞過試錯限制。

現在,用刪除 logintime 後的請求包,將 mobile 定義為枚舉變量 1、以前面生成的 username.txt 為字典,將 password 定義為枚舉變量 2、以常見弱口令 top1000 為字典,進行密碼暴破:

技術分享圖片

其中,應答包長度為 380 的均為有效密碼,存為 logined.txt:

技術分享圖片


任意賬號註冊

在註冊頁面 https://www.xxxx.com/Wap/User/register 輸入未註冊過的手機號點擊“獲取驗證碼”後、輸入收到的短信驗證碼後提交,進入密碼設置頁面:

技術分享圖片

輸入密碼後攔截請求:

技術分享圖片

簡單分析發現,register_mobile 為註冊的用戶名,只要該參數值未註冊過,通過這個請求包可繞過短信驗證成功創建任意賬號。

比如,系統本來只允許用手機號當用戶名進行註冊,利用該漏洞,可以創建賬號 yangyangwithgnu/abcd1234,登錄確認:

技術分享圖片


任意賬號密碼找回

密碼找回頁面 https://www.xxxx.com/Wap/User/forgetpass 用攻擊者賬號 13908080808 進入密碼找回全流程,輸入短信驗證碼後提交:

技術分享圖片

進入新密碼頁面,輸入後提交,攔截請求如下:

技術分享圖片

其中,PHPSESSID=p6nujg7itekpau6p1e9ibbpe86、register_mobile=13908080808 這兩個參數引起了我的註意。這個請求,用於重置賬號 13908080808 密碼,那麽服務端如何知道該重置 13908080808 而不是 13908080807、13908080809 呢?剛才說的幾個參數中肯定有一個用於該目的。逐一嘗試發現,PHPSESSID 就是它,另外,boss_language 和 register_mobile 可刪除,不影響結果。

這讓我聞到濃郁的 cookie 混淆的味道。大致攻擊思路:首先,用攻擊者賬號 13908080808 進入密碼找回流程,查收重置驗證碼、通過校驗;然後,輸入新密碼後提交,攔截中斷該請求,暫不發至服務端,這時,PHPSESSID 關聯的是 13908080808 賬號;接著,關閉瀏覽器的 burp 代理,新開重置流程的首頁,在頁面中輸入普通賬號 13908090133 後獲取短信驗證碼,這時,PHPSESSID 已關聯成 13908090133 了;最後,放行之前中斷的請求,放至服務端,邏輯上,可以成功重置 13908090133 的密碼。

用上述思路嘗試將 13908090133 密碼重置為 PenTest1024,前端顯示重置成功。嘗試用 13908090133/PenTest1024 登錄,成功進入系統:

技術分享圖片

同理可重置管理員賬號,為避免影響業務,不再實際操作。


防禦措施

通常來說,密碼找回邏輯中含有用戶標識(用戶名、用戶 ID、cookie)、接收端(手機、郵箱)、憑證(驗證碼、token)、當前步驟等四個要素,這四個要素必須完整關聯,否則可能導致任意賬號密碼找回漏洞。另外,服務端應限制枚舉等惡意請求。

本文原創作者:yangyangwithgnu 轉自 www.freebuf.com

挖洞思路 | 賬號攻擊的幾種常見手法