Android移動應用風險控制系統的研究

2022-03-27 23:00:47劉龍錦張志杰梁世民

中國新通信 2022年1期

劉龍錦張志杰梁世民

【摘要】? ? 截止至2020年6月，Android系統占據了手機系統74.6%市場份額，剩余26.4%市場份額由其他系統瓜分，絕對優勢的市場占有率造就了繁榮的Android生態及數量龐大的開發者。開發者水平的高低則給Android開發帶來了許多安全性問題。本文將從Android應用抓包防護，Java代碼防護，So代碼防護，簽名加密算法，服務端校驗方面進行研究，為應用的風險控制方案設計提供理論依據。

【關鍵詞】? ? Android? ? 抓包? ? 反編譯? ? 服務端

引言：

保護用戶數據，保護信息安全是每一個開發者，每一家互聯網公司都應該重點布防的區域。一套完整高效的風險控制方案，是開發者或公司開發實力的體現，也是高效保護用戶數據，信息安全，人人公平的重要手段。目前國內外在應用安全方面都比較著重，市場上也有阿里云、360、數美、數盟等安全服務廠商為Android應用提供安全加密服務。僅僅只靠第三方廠商提供的安全防護是遠遠不足的，我們需要控制用戶操作的完整鏈路，才能設計出一套優秀的風險控制系統。

一、防護方式

多數Android應用的操作邏輯為：客戶端進行操作，系統發送請求到服務器，服務端校驗請求合法及參數并返回數據，客戶端根據服務端返回數據進行相應界面展示。在這套操作邏輯中，客戶端的操作及數據發送部分存在風險。攻擊者通過反編譯Apk包，逆向出Android應用與服務端的通信協議，偽造非法請求攻擊。針對上述的攻擊方式，開發者會在Android應用的通信協議層進行防護，提高攻擊者抓包的難度，在請求中嵌入加密算法。收集設備信息，如設備型號，網卡地址，系統版本，IP地址等，綜合判斷本次請求是否合法。

二、抓包防護

抓包是研究應用程序的開始，通過抓包獲取數據進行分析，確認目標請求的地址、參數、加密字段等。主流的Android應用與服務端之間使用HTTPS/TLSv1.2協議通信，某些Android應用使用QUIC/Http3并強制使用TLSv1.3協議。隨著Android系統的版本更新，系統層面強制要求開發者使用HTTPS協議進行通信，開發者也重視數據傳輸過程中的安全，攻擊者對應用的抓包越發困難。

抓包通常采用中間人方式，常用抓包軟件有Fiddler、Charles等。中間人方式抓包需要解決兩個問題：如何偽裝Server、如何偽裝Client。以Fiddler軟件為例子，偽裝Server時需要安裝根證書到系統根目錄，偽裝Client則客戶端需要安裝Fiddler的自簽證書。Android系統將CA證書分為用戶CA與系統CA證書，系統CA證書擁有的權限較高但需要設備擁有root權限才可進行添加和刪除操作。

在擁有root權限的設備上，抓包非常容易實現。電腦端步驟：安裝Fiddler，安裝Fiddler根證書到系統，配置解密通道。手機端步驟：設置代理到電腦，安裝Fiddler自簽證書，安裝Xposed框架，安裝JustTrustMe插件，配置完成，即可抓取大多數應用數據包。對于抓包的防護，防護辦法有以下幾種：應用targetSdkVersion設置為大于24、雙向SSL認證、使用SSL重協商、使用其他通信協議。無論使用那種方式都不可能避免不被抓包，對于Android系統的限制可降低Android版本，證書固定方式可以Hook移除相關代碼，雙向SSL認證可逆向拿到私鑰進行破解抓包。開發者盡可能的提高抓包難度，增大攻擊者抓包的成本即可。

三、Java代碼防護

Android應用與服務端通信時，在請求中嵌入Token或者加密的字段是常見的方式。高級的風險控制系統還會收集用戶的操作行為日記上傳到服務器，通過分析用戶的操作行為日記來判定本次請求是否有效。在請求中嵌入加密字段需要開發者在Java代碼層進行代碼編寫，由于Android開源的特性，經過開發工具編譯生成的Apk安裝包如若未經過任何技術處理，使用Jadx工具進行反編譯即可查看得到與源程序匹配度高達95%的代碼。對于攻擊者而言，能查看到程序的源碼能夠極大的加快破解的速度，為了延緩攻擊者得到Android應用在Java層的算法，通常采用以下手段進行防護：

（一）代碼混淆

使用Proguard-rules工具進行代碼混淆，加大攻擊者閱讀難度，延緩破解算法的速度。代碼混淆方法僅僅只能延緩算法被破解的速度，可以把一些水平較低的破解者攔在門外，對于編程功底較為深厚攻擊者，此方法終究會被破解。

（二）Apk簽名校驗

進行APK打包操作時，開發人員要進行簽名操作。簽名文件是開發者獨有的，攻擊者通常不可能有相同的文件，可以使用Android SDK中PackageManager類的getPackageInfo簽名校驗方法保護Apk。

（三）重打包對抗

對Apk進行重打包，修改代碼實現抓包也是常用的攻擊方式。重打包常用的工具是ApkTool，ApkTool對Png文件會按照Png格式處理，將一個非Png格式的文件修改為Png格式，ApkTool打包時會出錯，可以在Apk的資源文件放入一些非法文件干擾ApkTool工具。

（四）調試器檢測

防止Apk被動態調試，可以檢測是否有調試器鏈接，使用Application類的isDebuggerConnected方法檢測，有調試器鏈接則采取防護措施。

（五）Dex文件校驗

重編譯Apk安裝包會重新編譯Dex文件，生成的Dex文件的Hash值就會發生改變，記錄軟件初始發布時Dex文件哈希值與客戶端運行時Hash值進行對比判斷應用是否被修改過。

（六）加殼保護

第三方廠商提供的加殼程序對Apk進行加殼也是一種有效的方式。但Apk加殼是在Java層代碼實現的，被反編譯的風險仍然很大。

四、So代碼防護

由于Android系統開源的特性，在Java層進行的防護都會被破解。Google為開發者提供了So文件的支持。So文件是Unix操作系統的動態鏈接庫，相當于Windows下的Dll文件，它由Native C/C++代碼編譯而來，在Android系統中充當JNI與Java交互的角色，能被Android Runtime加載并能被Java層調用。對比Java語言，C/C++在效率方面，混淆后的閱讀方面及加殼破解難度方面都有較大的提升。加密算法以及網絡通信協議在寫在so層是目前主流的做法，但So層的代碼也不是不能被破解的，只是破解的難度相較Java層的代碼會有一個較大的提升。反編譯So文件的主流軟件是Ida Pro，使用Ida軟件反編譯可以得到So文件的內容。為了加大攻擊者閱讀So文件的難度，需要對So文件進行加固以及混淆。So文件是可以被單獨調試的，所以需要對So文件進行反調試的保護，對So層的保護主要有以下幾種方式：

（一）代碼混淆

基于LLVM的混淆，通過指令替換、控制流扁平化和虛假控制等方法混淆。增加了虛假控制流、指令替換和控制流平坦化的處理。基于LLVM的混淆比較靈活，根據不同的安全需求策略，混淆程度越高，則性能影響越大，文件膨脹越多。

（二）調試檢測

Ida軟件具有動態調試So文件的功能，可以方便的還原出So層的算法。在So文件的JNI_Onload方法中加入調試檢測的代碼防止So文件被Ida軟件動態調試，可以在一定程度上防止算法被還原。

（三）防止調用

So文件可以作為一個庫單獨運行，確定了關鍵函數的地址后，直接調用即可得到返回值，為了防止被直接調用，應該在So文件中置入代碼，通過檢測上下文環境參數確認函數是被自身調用，防止直接調用攻擊。

（五）加殼保護

使用加殼程序對So文件進行加殼，由于So層的加殼程序使用C/C++編寫，執行的效率相對比Java層更高，代碼復雜度也比Java語言復雜一些，對應的脫殼難度也更高，可以更有效的提升應用安全。

五、簽名加密算法

除了常規Token認證之外，在每一個請求中都會對請求的參數進行簽名加密。加密得到的字符串嵌入在請求中參數中，服務端接收到數據后根據雙方約定好的算法對參數計算得到加密字符串，再與客戶端傳輸的字符串進行對比，如果雙方計算結果相同則暫時認為請求是合法的。

加密算法寫在Java層代碼非常容易遭到破解，大部分應用都會將加密算法寫在So層。常用的加密算法有MD5，AES，HMAC_MD5，RSA等，通常會使用多種加密算法結合計算以提升加密強度。加密算法無論是寫在Java層還是So層，都是可以被逆向出來的，寫在So層只是能延緩攻擊者破解的速度，對So文件進行脫殼修復，去LLVM混淆化，將So層的代碼邏輯進行修復后可以得到對應的加密算法。

六、服務端檢驗

客戶端發出的請求最終都由服務端校驗處理，Android應用無法做到完全隱藏程序代碼，對于客戶端的請求，服務端應該從多個方面進行校驗，校驗通過之后才能判定本次請求有效。服務端主要從以下方面進行判斷：

（一）簽名加密算法

服務端與客戶端通過雙方約定好的算法分別對數據進行加密后得到的字符串進行對比，對比不通過則代表本次請求為惡意請求，直接返回錯誤。

（二）IP地址來源

對從云服務器廠商發出的請求、同一個IP在某個時間段內頻繁發出的請求、頻繁更換IP地址進行訪問的請求進行一定的限制。如果是需要登錄的應用，可以在登錄時記錄對應的IP地址，后續發出的請求如果超過登錄IP的范圍，在環境校驗失敗之后應該做一定的請求限制。

（三）設備環境信息

判斷設備的型號、品牌、系統版本等信息生成對應權重的設備ID。對系統版本較低，設備已經Root，安裝有Xposed框架的設備適當降低權重或者將其直接風控。

（四）用戶操作行為

上傳某個時間段內用戶的操作信息，綜合判斷該操作是否有效。

七、結束語

Android應用的風險控制系統的設計需要進行多方面綜合考慮，它對開發者的專業技術提出了更高的要求，需要在與攻擊者的對抗中不斷進行完善，不斷進行優化。