Android APP漏洞之戰—驗證碼漏洞挖掘詳解

簡介

驗證碼漏洞也是當下十分常見的APP端漏洞，本文對驗證碼漏洞原理做了一個初步的講解，并復現了當下一些常見的驗證碼相關的漏洞，本文App抓包技術參考了肉絲大佬的書籍安卓Frida逆向和抓包實戰

本文第二節主要講述Android APP端抓包的基礎知識

本文第三節主要講述APP驗證碼漏洞的種類和安全場景

本文第四節主要講述APP驗證碼原理，并復現了一些常見的驗證碼相關漏洞

基礎知識

APP驗證碼漏洞挖掘，需要掌握基本的Android抓包技術，現在越來越多的APP開始進行安全防護，所以如何才能繞過一些基本的防護技術，合理的抓取到報文是驗證碼漏洞挖掘的先決條件。學習下面知識之前，可以先學習Android APP漏洞之戰（6）—HTTP/HTTPs通信漏洞詳解的基礎理論知識https://bbs.pediy.com/thread-270634.htm

1、APP抓包技術詳解

（1）高版本android系統證書導入

Android4.4后

開始引入CA證書校驗機制，這里先會涉及到Https的單向認證機制：

上述步驟4就進行證書校驗的環節，而這里的證書便是將手機內置的證書和客戶端的證書進行校驗，來判斷是否合法。

Https原理：非對稱+對稱連接

（1）非對稱主要是為了傳輸對稱連接所需要密鑰和證書校驗

（2）對稱連接是加密密碼可以安全傳輸，就可以采用對稱連接

Android4.4-Android7.0

這個階段，Android系統信任用戶下的證書，所以逆向人員可以將抓包工具的證書導入用戶目錄下，實現對Https的報文抓取，這里案例可以參考Android協議分析（一）——Fiddler安裝和使用https://bbs.pediy.com/thread-268445.htm

Android7.0+

Android7.0后，Android系統不再信任用戶目錄下證書，只信任根目錄下證書，所以我們要獲取HTTPs報文，需要將抓包工具的證書移動到根目錄下

方法一：將文件系統先掛載起來，然后移動

root權限下：mount -o remount,rw /systemcp * /etc/security/cacerts/chmod 777 /etc/security/cacerts/*mount -o remount,ro /systemreboot

方法二：使用Magisk證書模塊

Move Certificates（https://github.com/Magisk-Modules-Repo/movecert）

我們只需要將模塊安裝到Magisk中，這樣就可以成功的抓取常規狀態下的HTTPs的報文了，這里一定主要抓包時必須保證Android手機時間要正確，否則也會報錯。

（2）HTTPs雙向認證及解決方案

Https一般采用單向認證，但是一些特殊的APP在服務端也會對證書進行再次認證，這樣的認證機制我們稱為HTTPs雙向認證。

上圖中步驟5就對客戶端證書進行了校驗，這里導致我們就算客戶端導入了抓包工具的證書并信任，也無法通過服務端的認證。

解決辦法

（1）獲取客戶端的證書，可以通過編寫hook腳本的方式，獲取客戶端證書及密碼

（2）將客戶端證書導入到抓包軟件charles中，使得Charles能都獲取服務端信任（這里一般可以使用charles、Burpsuit軟件）

方法一：

這里我們一般可以先去分析開發中進行保護的函數，再對對應的函數進行hook

例如java.security.KeyStore。

這里可以參考肉絲大佬的文章《實用FRIDA進階：內存漫游、hook anywhere、抓包》

這里考慮篇幅問題，給一個參考的實操案例某交友app的雙向認證crack。

方法二：

直接在Apk文件下搜索.p12后綴的文件，這里搜索出來的很有可能就是證書文件，當然有些需要密碼的就還是要進行hook了。

tree -NCfhl |grep -i p12

（3）VPN代理機制

如果APP中編寫了檢測代理抓包軟件代碼，也可能會導致我們抓不到包：

System.getProperty(“http.proxyHost”);System.getProperty(“http.proxyPort”);

這樣我們使用代理軟件進行抓包要更加合適，當然也有一些檢測VPN的情況，這種直接hook就可以了：

具體如何配置使用，可以參考這篇文章APP流量 “一個都不能少” ！

采用VPN代理進行抓包，和Http中間人抓包有本質區別，VPN抓包本質在網絡層和路由層抓包

（4）SSL pinning

就算我們使用Vpn代理抓包，也解決了證書雙向認證的問題，但是在抓包過程中也可能會遇到證書綁定的情況。

證書綁定：APP在代碼段中有有對服務端證書進行對比一致性，如果發現是中間人就會直接終止連接。

這里我們提供一般的解決思路：

（1）識別證書綁定

（2）先使用開源框架objection或DroidSSLUnpinning先去簡單hook

（3）不成功，再去分析APP使用哪種開發框架，去有針對性的進行hook

（4）如果不知道開發框架，可以采用Hook Java的File構造函數進一步去定位證書綁定代碼

這里用一個簡單的實例來說明：識別證書綁定

當我們解決了單向認證、雙向認證、采用代理通信還出現上面的情況，說明APP可能采用了證書綁定。

使用開源框架hook——以objection為例：

我們直接使用objection的hook或spwan模式就進行證書綁定hook

hook模式啟動：android sslpinning disablespwan模式啟動：objection -g 包名 explore -s "android sslpinning disable"

針對開發框架，有針對性hook

我們需要分析APP采用何種開源框架，如okhttp等，不過這里一般開源hook工具objection已經針對了當下的很多開源框架了，所以如果沒有成功，可能是程序進行了混淆，這個時候就需要進一步去hook正確的綁定函數

未知開源框架

我們對File構造函數進行hook，然后可以觀察對應的調用鏈信息，從而分析出證書綁定的函數：

再針對這里找到的函數進行正確的hook，即可。

（5）VPN+Charles+Burpsuit環境配置

我們經過上面一系列流程基本可以解決當下常見的安全防護形式，當然針對更加安全的抓包防護策略就需要深入的解決了，這里我們介紹一下本文的抓包環境搭建，一般使用通過VPN+Charles+Burpsuit的組合抓包方式。

首先先配置VPN+Charles的抓包模式：

然后我們將Charles的流量去導入到Burpsuit中，這樣就可以實現組合使用，當然根據實際情況你也可以選擇合適抓包工具。

驗證碼漏洞安全場景和分類

1、驗證碼漏洞安全場景

驗證碼漏洞一般是APP對驗證碼沒有進行登陸校驗等安全防護導致的，攻擊者一般可以利用驗證碼漏洞進行暴力破解實現任意號碼登陸、還可以實現短信轟炸、導致驗證碼泄露、手機號換綁、驗證碼無限發送風險、萬能驗證碼登錄、修改返回包繞過驗證碼登錄等安全問題，驗證碼漏洞在APP中的影響十分嚴重，一般會造成嚴重的經濟損失。

2、驗證碼漏洞分類

我們根據上面的描述，可以將驗證碼漏洞分為如下幾類：

驗證碼漏洞原理分析和復現

1、驗證碼暴力破解漏洞

（1）原理分析

驗證碼暴力破解漏洞一般是因為用戶使用手機號+驗證碼的方式進行登陸時，短信驗證碼一般由4-6位數字組成，而且APP并未對驗證碼做時間和失敗次數校驗，所以攻擊者可以通過這個區間的所有數字進行暴力破解來進行攻擊。

（2）漏洞復現

案例：XX APP為例

我們打開APP，發現該APP并未對登錄號碼進行驗證，而且返回的驗證碼是4位驗證碼，這里我們就十分懷疑是否能進行驗證碼暴力破解。

然后我們使用上面搭建好的抓包環境，隨便輸入一個驗證碼去抓取錯誤信息：

我們發現APP根本沒有進行證書綁定等安全防護，甚至沒對驗證碼進行加密，我們于是對響應的報文進行攻擊。

然后我們采用100個線程，就暴力破解。

開始攻擊：

然后我們就成功暴力破解出驗證碼，這里我們發現還可以輸入任意的號碼18888888888同樣可以成功登錄，而且可以獲取其他用戶的訂單信息。

最后類似漏洞危害，如下：

（3）安全防護

（1）設置驗證碼時間驗證，一般建議為180s

（2）限制單位時間內驗證碼失敗的嘗試錯誤，如5分鐘連續失敗即鎖定賬號

（3）對驗證碼進行加密傳輸

2、驗證碼無限次數發送（短信轟炸）

（1）原理分析

驗證碼無限次數發送、短信轟炸漏洞一般是APP端并沒有對手機號碼進行次數顯示，也未對訪問進行時間限制。

（2）漏洞復現

我們首先對上面的APP進行發送驗證碼，查看響應的報文：

然后通過暴力破解進行短信轟炸，這里轟炸自己手機號，就轟炸個50次吧。

我們發現可以驗證碼無限次數發送，但是無法進行短信轟炸，因為驗證碼做了60s校驗，于是嘗試去分析APP代碼。

我們將APP拖入GDA分析：

這里我們發現APP進行360加固保護，我們就使用一代殼脫殼工具Frida_Dump進行脫殼。

我們定位到相關的代碼段:

分析了代碼邏輯，本來以為可以簡單的hook相關的函數，使得驗證碼60s時間變少，但是發現成功發送后還是顯示需要60s后再次發送，這說明這個驗證就是根據發送的報文，在服務端進行校驗。

我們查看發送的報文：

我們發現獲取驗證碼就是對應的手機號和time值，很顯然我們推測time值是用來校驗時間和對應手機號的。

我們分析對應源碼：

我們可以清晰發現為什么APP驗證碼對當前系統時間進行校驗，因為有系統時間獲取函數。

同理，我們可以發現驗證碼校驗的一些段落，包括四位驗證碼等。

最后經過分析，得出就是服務端會對每次發送的手機號和系統時間和手機號編碼產生的密鑰進行校驗，會對60s時間進行校驗，以及會對當前手機系統時間進行校驗。

這里我們可以簡單進行60s間隔的短信轟炸，可以簡單實現效果如下：

因為現在短信轟炸漏洞越來越少，這里沒找到更加合適的案例，這里收集一個大佬寫的短信漏洞轟炸的文章，可以參考下：挖洞技巧：繞過短信&郵箱轟炸限制以及后續。

（3）安全防護

(1)增加驗證碼發送校驗時間間隔

(2)采用代理池對ip進行限制

3、驗證碼泄露風險與萬能驗證碼漏洞

（1）原理分析

驗證碼執行【找回密碼】操作時，輸入手機號，獲取驗證碼，服務器會向手機發送驗證碼，通過burpsuite抓包工具，查看返回的響應數據包中如果包含驗證碼，則可能導致用戶密碼惡意重置、綁定手機號被惡意更換等風險。

萬能驗證碼一般是開發在業務未上線的時候為了方便測試用的,上線后忘記刪除了,例如8888 0000 1234等等。

（2）安全防護

因為當下這種漏洞較少，這里沒有找到合適案例，就只簡單介紹下原理了

4、修改返回包繞過登錄漏洞

（1）原理分析

在APP驗證碼測試過程中，我們發現很對APP并未對登錄成功的響應報文進行校驗，導致我們獲取登錄成功的響應報文后，就可以通過正確的響應報文實現任意號碼的登錄，導致信息泄露。

（2）漏洞復現

案例：XXAPP

我們先使用手機號進行正確的登錄，同時我們使用burpsuit抓取正確登錄的響應信息。

發送的請求：

響應的報文：

此時我們可以獲取正確響應的報文，我們只需要對在下次登錄時對該響應請求進行替換即可。

此時我們再次登錄，這里我們隨便輸入驗證碼5555：

然后我們注意設置對響應進行抓取：

然后進行替換：

最后我們替換報文發現成功登錄：

（3）安全防護