[[173505]]

寫在前面

本人學習滲透測試(主要是Web方向)有幾個月了，現在算是剛剛入門。回想起學習漏洞挖掘的過程，除了看一些經典書籍外，最想看的就是大牛們挖漏洞的詳細過程，比如如何尋找目標，從哪里入手，遇到問題怎么解決。但是，網上介紹知識的多，敘述過程的少(也可能是我的搜索姿勢不對……)。除了在烏云上有幾個大神有時會分享一些具體的挖洞思路外，大部分人還是“有圖有真相，一圖勝千言”。對于老司機來說，瞄一眼就知道是怎么回事了，但對于新手來說，往往是一頭霧水。因此，本人分享一下最近的一次挖洞過程，希望能夠拋磚引玉，大家踴躍分享自己的挖洞經驗。

PS：作為一個有操守的白帽子，本文重在分享思路與過程，細節處還是要打碼處理，畢竟不是來提交漏洞的。

尋找目標

這次是針對我常用的一個手機APP(下文簡稱：某APP)進行漏洞挖掘，說起來選擇某APP作為目標也是挺偶然的。因為我主要是搞Web滲透測試的，并沒有挖過手機APP的漏洞。有一天，在看別人分享Burp Suite的使用技巧的文章時，發現通過Burp還能夠進行手機APP抓包(畢竟Too young……)。光說不練假把式，還是要自己動手操練一番。先把Burp設置一下，在Proxy中Options下的Proxy Listeners中，點擊Edit，把Bind to address設置為All interfaces。

然后手機和電腦處于同一局域網中，給手機設置代理服務器，IP為電腦的IP地址，端口為Burp中的設置的端口，默認為8080。這時候，就可以用Burp抓取手機的請求包了。

山重水復

這時候我就打開某APP，執行常見的操作，Burp中就記錄了大量的HTTP數據報文。然后，就是對Burp中截獲的報文進行分析了。沒多久，一個請求就引起了我的注意。這是一條GET請求，請求的URL是類似下面這種格式：

http://www.example.com/path/get_some_data.jsp?id=1234567¶m1=value1¶m2=value2 

直覺告訴我，這里很有可能會有越權漏洞。于是，我用瀏覽器打開這個URL，果然直接就看到了用戶數據。換個id再試一下，把id加1，結果也是一樣的，都爆出用戶數據了。因此，到這里已經確定某APP存在越權漏洞。

確定這個越權漏洞存在后，稍微平復一下心情，然后就發現這個漏洞造成的后果并不嚴重。因為這里通過帳號越權查看到的用戶數據中，并沒有包含一些比較敏感的數據，比如姓名、手機號、身份證等。簡單地說，就是可以越權查看到他人的數據，但是“他人”是誰并不知道，這樣來說看到數據只是一堆無意義的數字而已。只釣到一條小魚有點不甘心，于是就繼續挖，應該還有其他的漏洞存在。

繼續查看Burp捕獲的報文，這次重點查看登錄過程中提交的請求和返回的響應，想從這里入手深入挖掘一番。登錄的報文如下，可以看到，只有一個POST參數params，其值經過了URL編碼。

把params的值解碼之后，發現是json格式的一串數據，基本內容如下：

其中，讓人感興趣的就是userId字段和body字段了，目測應該分別對應登錄的用戶名和密碼。然后我用相同的用戶名和不同的密碼、不同的用戶名和同樣的密碼分別登錄、抓包，然后解碼對比發現，相同的用戶名對應的userId值相同，相同的密碼對應的body值也相同，這就證實了我的推測。進一步分析發現，userId和body的值都是十六進制的數字串，userId的長度為32位(這里指32個十六進制字符，下同)，body的長度為128位。這就說明userId和body的值都經過了加密處理。對于userId，我首先想到是不是經過了MD5?不過經過計算用戶名的MD5和userId并不相等，也就是說，即便是MD5也加了salt。

分析到這里，暫時沒辦法繼續深入了。那就先放一放，分析一下登錄過程中返回的數據包，下圖是登錄成功之后返回的數據包。

一看返回的數據包直接傻眼了，明顯是經過加密的。不過，這里還是要注意一下返回的數據包長度，因為我故意輸入錯誤的密碼進行登錄時(如下圖所示)，返回的數據包長度居然相差無及!并且也能看到，有許多相同的字符。很顯然，這里有很大的可能是有問題的。

柳暗花明

到目前為止，雖然已經把登錄過程中的請求報文結構都分析清楚了，但是由于報文中的關鍵數據都進行了加密處理，所以到現在幾乎仍然是一籌莫展。事實上我在這里卡了兩天，也沒什么好的辦法，甚至還想到過分析一下別人帳號登錄過程中的數據包然后破解出密碼的想法。不過仔細一想就覺得這個想法太不現實，又不是密碼學專家，僅僅通過幾條密文就想破解加密過程，這怎么可能成功!盡管想法有點荒唐，但是還真給我帶來了靈感：既然某APP發送的報文和返回的報文都是加密的，那肯定是在某APP中進行了加密和解密的操作，那么如果能夠分析一下某APP的源碼，應該就能夠搞清楚其中的加解密過程。那么問題來了，哪里能得到某APP的源碼呢?

思來想去，最方便、最有可能的辦法就是將某APP進行反編譯得到源碼。ios版的我就不想了，畢竟也沒搞過ios開發，直接去逆向肯定是不現實的。但是安卓版的還是有搞頭的，因為之前看過別人進行APK逆向的文章，也寫過Java代碼。說干就干，網上搜一搜安卓逆向教程一大堆，畢竟咱只是想分析源代碼，并不是要搞脫殼破解，入門級的教程就能夠滿足要求，這里就不多說了。總之，將某APP反編譯之后，發現代碼進行了混淆，但是并不影響分析，稍微費點勁而已。經過分析，果然有收獲。

首先，發現加解密使用了AES算法，并且加解密所用的密鑰是16位的。

繼續分析發現，開發人員居然把密鑰“幾乎”硬編碼在代碼中!密鑰總共16位，前面幾位是網站域名，再加上devId的前幾位，湊夠16位即是密鑰。而devId在登錄的請求包中是以明文出現的，這樣一來，相當于加密算法和密鑰我們都得到了。

到目前為止，分析的過程基本上就已經結束了，是時候寫代碼驗證一下分析結果了。用Python寫了AES加解密的代碼，將userId和body進行解密之后發現，userId果然就是登錄的用戶名，而body的值則是如下json格式的字符串：

很明顯，password的值也經過了加密，這里有可能就是計算了MD5，不過有可能加了salt。繼續分析源代碼，找到了對密碼進行處理的過程，果然是加了salt的MD5!并且，salt也是硬編碼……

拿自己的密碼進行驗證，證實了上述分析。

意外驚喜

到現在為止，已經可以偽造數據包進行模擬登錄過程了。事實上，我最初的想法也是想偽造數據包模擬登錄進行暴力破解的。不過，在進行暴破之前，還是先把返回的響應報文解密看看。按照之前的分析，返回的報文肯定是有問題的。

將響應報文解密之后，果然帶來了更大的驚喜!前邊已經提到，登錄成功返回的數據包長度和失敗時返回的數據包長度很接近，解密之后發現，何止是長度接近，內容也有九成是一樣的!當然，這都不是重點，重點是不論登錄是否成功，都返回了用戶的真實數據，包括姓名、手機號、身份證號以及正確密碼的哈希值，密碼完全就是形同虛設。不枉費我一番心思，總算釣到大魚!

總結

漏洞挖掘的過程基本上結束了，之后提交漏洞的過程我就不廢話了。整個過程寫起來有點像流水賬，但是卻把我挖掘漏洞的過程和思路寫清楚了，總結起來就是：

多看多想多動手實踐，有事沒事多抓包分析

Web方面的挖洞思路和軟件逆向相結合，帶來意想不到的驚喜

不要總想著暴力破解，那是沒有辦法的辦法

最后，希望此文能夠拋磚引玉，大家都能把自己的挖洞思路分享出來。挖漏洞有時候確實需要一點靈感，多學習一下別人的挖洞思路，肯定能夠對自己有所啟發。