任意密碼重置的一個場景

背景

做授權滲透的時候要求要寫明文傳輸漏洞，這就導致很多沒有上 HTTPS 的網站為了修這個明文傳輸的問題，用盡了各種奇葩的做法，其中見得比較多的就是使用 RSA 或是 AES 對傳輸的數據進行加密後傳輸（還見到用 base64 進行編碼之後就算修了的）。

但是要知道，加密都是在客戶端進行的，而且 AES 是對稱加密演算法（就算是 RSA 非對稱加密，也只是不能解密加密的內容，但有了公鑰之後，拿去加密自己提交的 payload 還是可以的），所以只要攔截到數據包，理論上加密的信息都是可以解密的。面對這些掩耳盜鈴的修復方式也是很無奈，但是也還是有稍微提高一些攻擊成本的。

場景

最近就碰到一個場景了。 修改用戶密碼的地方在收取手機驗證碼的時候注意到驗證碼只有4位，而且是純數字，介面還沒有對驗證碼的驗證次數進行限制，這就意味著可以進行遍歷對任意用戶的密碼進行重置。 但是還有一個問題就是它對提交的信息都進行了加密

這就意味著，如果需要繼續進行下去，就需要繞過加密這道坎。然後我就進行了各種嘗試。

第一次嘗試

思路一：對它的加密過程進行逆向，拿到 key 和 vi 值，然後再寫個腳本在本地進行加密後再post到目標地址，但是逆了一個多個小時，愣是沒搞掂（留下了沒技術的眼淚），然後就放棄了這條路。

思路二：把網頁的關鍵內容扒下了，然後在本地調用它預留的加密和處理的介面，再post過去。但是又遇到問題了，一開始以為它的 key 和 vi 值是固定的，就下斷點調試從網頁上拿到 key 和 vi 值之後就放到本地去做加密處理，但是後來發現它的 key 和 vi 值過幾秒就會刷新一次，網頁每次請求之前都會獲取一次新的。但是本地的網頁和目標網站不是同一個源，而且網站的CORS設置也沒有問題，所以根據瀏覽器的同源策略，AJAX 獲取 key 和 vi 是不行的，通過 AJAX 去 POST 數據也是不行的。

然後到這裡，第一次嘗試就已失敗告終了（當時項目很急，而且任務量還很大，如果一直死磕這個問題，那後面的就不用做了，所以當時就只能放棄了）

第二次嘗試

過了幾個星期，也就是這幾天，那個項目要求再做一次測試，鑒於之前已經把問題挖得七七八八了，所以這次就有時間去繼續研究下這個問題了。

分析了一下上次的失敗，寫代碼是不可能的，這輩子都不可能，只有當腳本小子才能勉強維持現在的生活。那第二個思路關鍵點在於解決同源的問題。 想到這個關鍵點之後就好辦了，最直接的方式就是在它的源上運行我的代碼。那要怎麼才能在它的源上運行我的代碼呢？

首先想到的就是在瀏覽器上修改代碼，但是瀏覽器並沒有提供這個功能，那就要把伺服器返回給瀏覽器的數據給修改了，欺騙瀏覽器去運行，這就要祭出我們強大的 burpsuite 了。

把這個頁面的代碼攔截下來修改（這個場景很欺騙，手機驗證碼在這個頁面才驗證，所以並不是到了這個頁面就可以重置密碼了）：

攔截下來之後稍微加工一下：

這代碼的意思是遍歷1000到9999（因為驗證碼是4位），把對應的數值轉換為文本後放到提交的數據的驗證碼欄位，再交給它頁面本身的加密演算法加密後去提交（所以這裡我根本不需要知道它加密演算法的細節，只管去調用就行了）。

放行之後瀏覽器就收到這個修改之後的頁面，裡面已經包含我加入的代碼了，剩下就交給瀏覽器去跑了，幾分鐘後跑了出來，自動跳轉到登錄頁：

自此，成功修改13800138000用戶的密碼（之前還有一個任意號碼註冊的洞，所以當時註冊了這個不存在的手機號）。

總結

很多時候一些代碼其實不需要自己手工去一步一步逆，可以藉助環境幫你跑出來（一開始我也鑽了牛角尖），很多CTF的 writeup 也看到藉助環境跑出加密的代碼或變數的。 通過攔截和修改伺服器的返回包可以欺騙瀏覽器在指定源上跑自己的代碼從而繞過同源策略的限制。

*本文作者：三隻小瀦，本文屬 FreeBuf 原創獎勵計劃，未經許可禁止轉載

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！