在此之前，移動端應用程序會直接忽略掉所有的SSL錯誤，并允許攻擊者攔截和修改自己的通信流量。但是現在，很多熱門應用程序至少會檢查證書鏈是否是一個有效可信任的證書機構(CA)頒發(fā)的。

作為一名滲透測試人員來說，我們常常需要讓目標應用程序信任我們的證書是有效的，這樣我們就可以進行中間人攻擊(MITM)并修改其流量了。在這篇文章中，我們將給大家介紹四種繞過Android SSL驗證的方式。

一、SSL MitM

為什么我們要特別關注移動端應用程序的SSL MitM安全情況呢?為了觀察或對移動端應用程序的Web服務調用情況，我們需要使用類似BurpSuite或ZAP這樣的攔截代理。當我們利用代理攔截下SSL流量之后，客戶端的SSL鏈接將會中斷。默認情況下，類似Burp這種工具所生成的自簽名證書將失效，如果證書不被信任，那么移動端App將會中斷連接。接下來，我們所要介紹的技術將能夠讓移動端應用程序信任我們的攔截代理所提供的證書。

技術#1-向用戶證書中添加自定義CA

避免SSL錯誤的最好方法就是設置一個有效可信任的證書。這種方法相對比較簡單，如果你可以向設備安裝一個新的可信任CA證書，并且操作系統(tǒng)信任你的CA，那么它就會信任由你CA簽名的證書。

Android有兩個內置的證書存儲(即System Store和User Store)，它們會對操作系統(tǒng)信任的CA進行跟蹤。其中System Store用于存儲預裝的CA，User Store存儲用戶安裝的CA。默認配置下，使用了類似TLS或HTTPS的安全連接會信任預安裝的系統(tǒng)CA，而Android 6.0(API Level23)及以下版本默認會新人用戶添加的CA。

這意味著什么呢?如果我們向User Store中添加自己的CA，那我們就可以嘗試對Android 6.0及以下版本的設備進行中間人攻擊了。如果針對的是高于Android 6.0版本的設備，那么我們所添加的證書將不會被信任。為了解決這個問題，我們可以編輯應用程序的Manifest文件，并強制它適配Android 6.0。目標API Level定義在AndroidManifest.xml文件中的‘platformBuildVersionCode’屬性(’manifest’元素)：

1. <manifest xmlns:android="http://schemas.android.com/apk/res/android"package="com.test.app" platformBuildVersionCode="25"platformBuildVersionName="7.1.1"> 

我們要把‘platformBuildVersionCode=25’改成23：

1. <manifest xmlns:android="http://schemas.android.com/apk/res/android"package="com.test.app" platformBuildVersionCode="23"platformBuildVersionName="6.0"> 

重新打包之后，應用程序將會信任用戶添加的CA證書了。

當然了，如果你想要在特定平臺版本中運行的話，你也可以在APK的‘/res/xml/network_security_config.xml’文件中定義一個 。比如說，下面的代碼就定義了一個新的受信任CA，文件存儲在/res/raw/my_ca：

1. <?xm lversion="1.0" encoding="utf-8"?> 
2. <network-security-config> 
3. <base-config> 
4. <trust-anchors> 
5. <certificates src="@raw/my_ca"/> 
6. </trust-anchors> 
7. </base-config> 
8. </network-security-config> 

這樣一來，我們就能夠順利完成MitM了。

技術#2-用自定義CA證書重寫已打包的CA證書

如果第一種方法不起效的話，可能是因為開發(fā)人員限制了應用程序所能信任的CA證書了。還記得剛才我們使用自定義的 來提供CA證書路徑嗎?而開發(fā)人員同樣可以使用這種方法來保護自己的應用程序免受SSL攔截攻擊。

在這種場景下，為了讓我們的攔截證書可以被信任，我們就需要提取APK并用我們自定義的CA證書來重寫應用程序所提供的CA證書。需要注意的是，這種方法可能會要求進行一系列驗證。

使用APK Studio之類的工具打開APK文件，然后在窗口中找到應用程序所捆綁的證書。在上圖中，證書位于應用程序的assets目錄下。接下來，用我們自定義的CA覆蓋應用程序原本的CA(‘UniversalRootCA’證書)，這樣就可以讓應用程序直接信任我們的證書了并實現流量攔截了。

技術#3-Frida Hook

如果安裝自定義CA也無法成功的話，說明應用程序可能使用了某種SSL綁定技術或采用了額外的SSL驗證。一般來說，為了繞過這種驗證方法，我們需要對應用程序的代碼以及驗證接口設置鉤子。這種接口一般用于限制手機被root或越獄，但是在Frida框架【工具下載】的幫助下，我們就可以在不root設備的情況下，對應用程序進行動態(tài)分析了。

Frida可以在操作系統(tǒng)中以獨立應用程序的形式運行，但是這需要對設備進行root。為了避免root操作，我們可以直接將Frida注入到目標APK之中。Frida工具中包含了一個能夠讓應用程序在運行時加載Frida的動態(tài)庫，并允許我們對目標應用程序的代碼和指令進行動態(tài)修改。

接下來，我們需要提取APK文件，注入動態(tài)庫，然后編輯一些smali代碼來讓我們的代碼庫在應用程序啟動時最先被調用。完成之后，重新打包APK并進行安裝。整個過程的完整操作方法可以參考【這篇文章】。

除此之外，我們也可以使用Objection工具【項目地址】來實現我們的目標。Objection可以讓整個過程自動化完成，我們只需要在命令行中提供目標APK的路徑，Objection就可以幫我們完成所有的代碼注入以及修改操作。

1. C:\>objection patchapk -s test_app.apk 
2. No architecture specified. Determining it using `adb`... 
3. Detected target device architecture as: armeabi-v7a 
4. Github FridaGadget is v10.6.28, local is v10.6.13. Updating... 
5. Downloading armeabi-v7a library toC:\.objection\android\armeabi-v7a\libfrida-gadget.so.xz... 
6. Unpacking C:\.objection\android\armeabi-v7a\libfrida-gadget.so.xz... 
7. Cleaning up downloaded archives... 
8. Using Gadget version: 10.6.28 
9. Unpacking test_app.apk 
10. App already has android.permission.INTERNET 
11. Reading smali from:C:\Temp\tmp8dxqks1u.apktemp\smali\com/test/app/TestMainActivity.smali 
12. Injecting loadLibrary call at line: 10 
13. Writing patched smali back to:C:\Temp\tmp8dxqks1u.apktemp\smali\com/test/app/TestMainActivity.smali 
14. Creating library path: C:\Temp\tmp8dxqks1u.apktemp\lib\armeabi-v7a 
15. Copying Frida gadget to libs path... 
16. Rebuilding the APK with the frida-gadget loaded... 
17. Built new APK with injected loadLibrary and frida-gadget 
18. Signing new APK. 
19. jar signed. 
20. Signed the new APK 
21. Performing zipalign 
22. Zipaling completed 
23. Copying final apk from C:\Users\cwass\AppData\Local\Temp\tmp8dxqks1u.apktemp.aligned.objection.apkto current directory... 
24. Cleaning up temp files... 

接下來，我們的工作目錄中應該會出現一個名叫‘test_app.objection.apk’的文件(默認情況下，工具會在原始APK文件名的后面添加一個.objection后綴)。我們可以像安裝普通APK一樣安裝這個文件，使用命令“adb install test_app.objection.apk”可以直接將其推送到連接設備上。安裝完成之后運行目標App，此時App將會卡在啟動界面。現在，我們就可以連接到Frida服務器，并開始監(jiān)聽設備流量了。Frida命令行工具的使用方法如下：

1. C:\>frida-ps-U 
2. PID  Name 
3. ----  ------ 
4. 6383  Gadget 
5.   
6. C:\>frida-U gadget 
7. ____ 
8. / _ |Frida 10.3.14 - A world-class dynamic instrumentation framework 
9. | (_|| 
10. >_ | Commands: 
11. /_/|_| help -> Displays the help system 
12. . . .. object? -> Display information about 'object' 
13. . . .. exit/quit -> Exit 
14. . . .. 
15. . . .. More info at http://www.frida.re/docs/home/ 
16.   
17. [MotorolaMoto G (5) Plus::gadget]-> Java.available 
18. true 
19.   
20. Alternatively,Objection supports interaction with the listening Frida server by using the‘explore’ command: 
21.   
22. C:\>objectionexplore 
23. ___||_  |_|___ ___| |_|_|___ ___ 
24. | . |. | | | -_|  _|  _| | . |  | 
25. |___|___|_||___|___|_| |_|___|_|_| 
26. |___|(object)inject(ion)v1.2.2 
27.   
28. RuntimeMobile Exploration 
29. by:@leonjza from @sensepost 
30.   
31. [tab]for command suggestions 
32. com.test.appon (motorola: 7.0) [usb] # android hooking search classes TrustManager 
33. android.security.net.config.RootTrustManager 
34. android.app.trust.ITrustManager$Stub$Proxy 
35. android.app.trust.ITrustManager 
36. android.security.net.config.NetworkSecurityTrustManager 
37. android.security.net.config.RootTrustManagerFactorySpi 
38. android.app.trust.TrustManager 
39. android.app.trust.ITrustManager$Stub 
40. com.android.org.conscrypt.TrustManagerImpl 
41. com.android.org.conscrypt.TrustManagerImpl$ExtendedKeyUsagePKIXCertPathChecker 
42. com.android.org.conscrypt.TrustManagerImpl$TrustAnchorComparator 
43. com.android.org.conscrypt.TrustManagerFactoryImpl 
44. javax.net.ssl.TrustManagerFactory$1 
45. javax.net.ssl.TrustManager 
46. javax.net.ssl.TrustManagerFactory 
47. javax.net.ssl.X509TrustManager 
48. javax.net.ssl.TrustManagerFactorySpi 
49. javax.net.ssl.X509ExtendedTrustManager 
50. [Ljavax.net.ssl.TrustManager; 

此時，你就可以使用內置的SSL綁定繞過函數來實施攻擊了：

1. com.test.appon (motorola: 7.0) [usb] # android sslpinning disable 
2. Job:2f633f86-f252-4a57-958e-6b46ac8d69d1 - Starting 
3. [6b46ac8d69d1][android-ssl-pinning-bypass] Custom, Empty TrustManager ready 
4. Job:2f633f86-f252-4a57-958e-6b46ac8d69d1 – Started 

技術#4-逆向自定義證書的驗證代碼

當然了，開發(fā)人員也有可能會使用自己開發(fā)的SSL庫，而不是直接使用系統(tǒng)庫來處理SSL證書驗證過程。如果這樣的話，我們就需要提取出APK文件，然后將smali代碼轉換成Java代碼，這樣我們才可以對負責處理證書驗證的代碼進行分析，并想辦法實現流量攔截，這里我們需要使用到dex2jar工具。

dex2jar工具的使用命令語句如下所示：

1. C:\>d2j-dex2jar.bat"C:\test_app.apk" 
2. dex2jarC:\test_app.apk -> .\test_app-dex2jar.jar 

輸出的.jar文件可以直接在絕大多數Java逆向工具(例如JD-GUI)中打開。

當你找到了負責處理證書驗證的代碼之后，你就可以選擇對代碼進行直接修改或者使用Frida來給特定函數設置鉤子了。為了避免對整個應用程序進行重構，我們可以直接對證書驗證函數設置鉤子。具體的操作方法可以參考技術#3所介紹的內容(使用Frida命令行工具或Objection接口)。

二、總結

本文所介紹的技術可以允許我們繞過Android開發(fā)人員所設置的常見防護措施，并攔截目標Android應用的SSL通信流量。除此之外，本文還簡單介紹了Objection接口以及Frida工具，這些工具可以幫助我們繞過應用程序的SSL綁定以及其他防護機制。本文揭露了多種繞過給定安全控制的方法，希望這篇文章可以給Android應用程序的安全研究人員提供一些有用幫助。