利用密碼重置功能實現賬號劫持
責編：gltian ｜2018-04-26 14:47:11從Blind XSS說起
在對一個域名進行前期踩點時，我偶然發現一個前端應用，它有一個是很舊的主界頁，但登錄表單沒有使用HTTPS。我想，如果連登錄頁面的證書都沒有，那應該還會存在什么脆弱性呢？于是我認真檢查并發起測試請求，嘗試在該頁面網站注冊一個新賬號。可惜的是，必須需要一個后綴為@company.com的公司郵箱，或者注冊帳號需要后臺管理員驗證批準，才能成功完成注冊。
考慮到這一點，我想我應該測試一下該前端應用是否存在Blind XSS漏洞，于是我在登錄的“名字”和“姓氏”字段中提交了有效的XSS測試載荷，當我單擊“提交”按鈕時，收到以下錯誤消息，這讓我感到意外。我沒把blind XSS測試載荷一起截屏，但整個過程返回了以下錯誤響應：
測試盲注漏洞（Blind SQLi）
好吧，既然這樣，那我來試試盲注漏洞（Blind SQLi）吧。通常，出現這類錯誤響應信息后，我會第一時間想到用Sqlmap來測試一下注入漏洞。但遺憾的是，可能因為不能使用同一個郵箱兩次注冊賬號，此處發起的賬號注冊式的SQL注入請求沒能成功響應。另外，在Sqlmap中存在一個選項設置，可以在賬號注冊需要的郵箱地址中添加一個數字，形成特殊的注冊請求，但是我發現手動來做速度會更快。就這樣，我反反復復試來試去，最終也只能得到一些無效的語法響應。好在，在朋友Gerben Javado的幫助下，我成功構造了一條有效的賬號注冊式SQL請求，其響應提示，該注冊賬號已成功創建，但卻需要等待后臺激活。
既然能這樣，那這肯定存在盲注漏洞（Blind SQLi），但由于我無法從測試頁面中查看到請求響應結果，我就轉而使用以下Payload來繼續測試：
“-IF(MID(@@version,1,1) = 5, sleep(10), “”)-”
該Payload下，頁面在10秒過后發生響應，其中MID(@@version,1,1) = 5來測試后端MySQL數據庫版本是否為5以上。另外，我還在此發現了一個反射型XSS。
實現賬號劫持
現在，可以構造有效的賬號注冊式SQL請求，也能形成有效的盲注漏洞（Blind XSS ），為此，我一直用XSSHunter來測試看看能否發現新的XSS點，幾經測試已是深夜，困的不行，只能明天再戰。第二天，我認真查看測試記錄，意識到接下來可以從3個方面深入：
在第一張MySQL的錯誤響應截圖中，在底中可以看到它提示“Please contact XXXXXX and let him know you’re having trouble.“，這至少能說明我給出的注冊需要郵箱是有效的；
在第二張賬號注冊式的SQL請求截圖中，其中提示，網站系統后臺會向注冊郵箱發送一封驗證郵件；
另外，可以對網站系統的密碼重置功能進行一些后續分析。
綜合以上三方面情況，我決定測試一下其密碼重置功能。由于我提交了上述發現的盲注漏洞，目標公司告知我，曾經按計劃，這個網站應用本來是要被移除下線的，為此他們讓我不用擔心風險后果，放開手腳去測試。另外，征得目標公司同意，我獲得了一個有效的公司名后綴郵箱valid_user_address@company.com，以便用于后續測試。
在密碼重置功能中，唯一的要求是有一個有效的公司名后綴電子郵箱，它會向用戶發送一封電子郵件，該郵件內容具體不詳。我先來測試它是否易受HTTP參數污染攻擊（ HTTP Parameter Pollution），之后是SQL注入漏洞，但好像都不行。然后我想，如果系統后臺正在向我提供的郵箱地址發送驗證性郵件，那么我是否可以嘗試，使用SMTP標頭注入法（ SMTP header injection）將我自己設置的郵箱地址，添加成抄送或密件抄送的另外一個郵箱地址，這樣我就能收到與提供郵箱同樣的驗證郵件了。
SMTP頭注入漏洞是在未進行充分審查過濾的情況下，用戶輸入被放入電子郵件標頭中，從而使攻擊者能夠注入具有任意值的其他標頭。此行為可用于向第三方發送電子郵件副本、附加病毒、提供網絡釣魚攻擊，并經常更改電子郵件的內容。典型應用就是，垃圾郵件發送者通常會以這種方式，利用存在漏洞的攻擊公司名聲，來增加其電子郵件合法性。如果電子郵件包含了一些攻擊者不該看到的敏感信息(如密碼重置令牌等)，則此問題就非常嚴重。—–Portswigger
最終，我形成的抄送命令如下
valid_user_address%40company.com%0D%0ABCC%3Ame%40me.com%0D%0A
URL解碼之后是這樣的：
valid_user_address@company.com
BCC:me@me.com
其中，me@me.com是我自己提供的郵箱，即抄送副本的第二個郵箱地址。而valid_user_address@company.com是我征求公司獲取的有效公司郵箱地址。
上述抄送命令提交之后，我立即查看了我的郵箱me@me.com，看看是否有某種密碼重置令牌或其它可進行密碼重置的東東，當然，我希望這種重置機制最好是沒有其它類型的雙重驗證（2FA）。讓我驚喜的是，我郵箱收到的電子郵件內容如下:
就這樣，網站以明文形式向我發送了用戶密碼，我甚至可以通過登錄確認該密碼仍然有效。最終，我向項目組提交了我的測試報告，另外，結合之前發現的Blind XSS，我還發現了更多的SQL注入漏洞，之后，目標測試公司也下線停用了該網站。