[[173505]]

寫在前面

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

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

尋找目標(biāo)

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

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

山重水復(fù)

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

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

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

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

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

把params的值解碼之后，發(fā)現(xiàn)是json格式的一串?dāng)?shù)據(jù)，基本內(nèi)容如下：

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

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

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

柳暗花明

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

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

首先，發(fā)現(xiàn)加解密使用了AES算法，并且加解密所用的密鑰是16位的。

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

到目前為止，分析的過程基本上就已經(jīng)結(jié)束了，是時候?qū)懘a驗證一下分析結(jié)果了。用Python寫了AES加解密的代碼，將userId和body進(jìn)行解密之后發(fā)現(xiàn)，userId果然就是登錄的用戶名，而body的值則是如下json格式的字符串：

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

拿自己的密碼進(jìn)行驗證，證實了上述分析。

意外驚喜

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

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

總結(jié)

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

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

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

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

最后，希望此文能夠拋磚引玉，大家都能把自己的挖洞思路分享出來。挖漏洞有時候確實需要一點靈感，多學(xué)習(xí)一下別人的挖洞思路，肯定能夠?qū)ψ约河兴鶈l(fā)。