任意使用者密碼重置（三）：使用者混淆

前言

在邏輯漏洞中，任意使用者密碼重置最為常見，可能出現在新使用者註冊頁面，也可能是使用者登入後重置密碼的頁面，或者使用者忘記密碼時的密碼找回頁面，其中，密碼找回功能是重災區。我把日常滲透過程中遇到的案例作了漏洞成因分析，這次，關注因使用者混淆導致的任意使用者密碼重置問題。

密碼找回邏輯含有使用者標識（使用者名稱、使用者 ID、cookie）、接收端（手機、郵箱）、憑證（驗證碼、token）、當前步驟等四個要素，若這幾個要素沒有完整關聯，則可能導致任意密碼重置漏洞。

案例一：通過 cookie 混淆不同賬號，實現重置任意使用者密碼。

密碼找回頁面 https://my.xxxx.com/pwd，用攻擊者賬號 yangyangwithgnu 走完密碼找回全流程。

輸入使用者名稱和圖片驗證碼後提交：

驗證為有效使用者名稱後，系統提供手機、郵箱兩種密碼找回方式，選用郵箱方式：

登入郵箱查收重置驗證碼：

輸入重置驗證碼：

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

其中，PHPSESSID=dcusc1ahkn4ioqeeav9c6e0bdq、USER_ACCOUNT=yangyangwithgnu、 USER_APPID=1092 這三個引數引起我的注意。這個請求，用於重置賬號 yangyangwithgnu 密碼，那麼服務端如何知道該重置 yangyangwithgnu 而不是 yangyangwithgnu2、yangyangwithgnu3 呢？剛才說的那三個引數中肯定有一個用於該目的。逐一嘗試發現，PHPSESSID 就是它。

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

用上述思路嘗試將 liuwei 密碼重置為 PenTest1024，前端顯示重置成功：

嘗試用 liuwei/PenTest1024 登入：

成功進入系統：

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

案例二：通過篡改請求包中的使用者名稱引數，實現重置任意使用者密碼。

密碼找回頁面 http://www.xxxx.cn/getpass.html，用攻擊者賬號走完密碼找回全流程，涉及三步請求，依次為：驗證使用者名稱是否存在、獲取簡訊驗證碼、提交簡訊驗證碼和新密碼。第三步的請求攔截如下：

重定向至登入頁面。用普通賬號 zhangzhiqiang/PenTest1024 登入成功。

檢視個人資訊：

洩漏使用者手機號、郵箱等敏感資訊。

檢視視訊監控裝置列表：

視訊監控裝置登入資訊：

登入後可檢視實時視訊監控，隱私考量，不截圖了。

另外，密碼找回流程第三步的請求中的 vcode 引數為簡訊驗證碼，單次有效，不可複用，如何實現自動批量密碼重置？經測試，將該引數置空，或者完整刪除該引數，服務端不再校驗簡訊驗證碼。

綜上，幾個問題結合，可導致任意使用者密碼重置。

案例三：通過篡改帶 token 的重置連結中的使用者名稱，實現重置任意使用者密碼。

http://xx.xxxx.com/echannel/forgetPassword/ 為重置密碼頁面。攻擊者使用者 ID 為 42558。

輸入攻擊者賬號繫結的郵箱後點選“確認”，收到如下帶 token 的密碼重置連結：

該重置連結有兩個地方引起我的注意：一是，NDI1NTg= 為 base64 編碼，解碼為 42558，正是攻擊者賬號的使用者 ID；二是，這是個 REST 風格的請求。所以，嘗試用普通賬號的使用者 ID 的 base64 編碼替換 NDI1NTg= 後，成功重置該普通使用者的密碼。

特別注意，引數部份出現 / 應想到這是 rest 風格的引數和引數值。

防禦措施方面，一定要將重置使用者與接收重置憑證作一致性比較，通常直接從服務端直接生成，不從客戶端獲取。另外，密碼找回邏輯中含有使用者標識（使用者名稱、使用者 ID、cookie）、接收端（手機、郵箱）、憑證（驗證碼、token）、當前步驟等四個要素，這四個要素必須完整關聯，否則可能導致任意密碼重置漏洞。另外，HTTP 引數汙染、引數未提交等問題，服務端也要嚴格判斷。