如何分析APK安全及自動化審計

一、 閒聊

說到行動安全，可能大家比較陌生，因為這方面的研究是在最近幾年才逐漸火起來的。那什麼是行動安全呢？首先，我們知道，行動安全無非是ios平台和安卓平台上的一些安全性的問題，包括平台系統系統本身的一些問題和應用層面上的問題。當然在客戶端和服務端在進行互動的時候還需要涉及一些通訊協議，主要是http及https協議，當然還有一些其他的協議，像是websocket等等。這些協定本身的缺陷我們就不做過多的關注了，我們需要關注的是資料包在傳輸的過程中是否有進行必要的加密，服務端是否有對用戶的操作權限進行控制，服務端的一些業務邏輯處理是否有缺陷等等，這一方面的思路基本上和web滲透差不多，但也有些不同。

二、木馬攻擊

說到移動安全，當然少不了病毒和木馬的攻擊，常見的遠控木馬有droidjack、SpyNote等等，還有前一段時間如雨後春筍般湧現的鎖機軟體。

圖1Droidjack

#圖2 鎖機軟體

攻擊者可以利用Droidjack這類軟體，產生木馬程序，這種惡意的木馬程序一般存在於一些三流的apk市場裡。一般來說，攻擊者會在這些apk中投放一些帶有誘惑性的信息，比如免費觀看某某美女視頻，某某視頻免廣告客戶端，某某爽圖瀏覽器等等。攻擊者將這些帶有誘惑性信息的apk發佈到網絡上後，會在遠程伺服器上起一個服務端程序，一旦用戶安裝運行了這個惡意程序，黑客就可以在遠程服務端對用戶手機進行操控，監視用戶的各種行為，進而竊取用戶隱私資訊。

歸根結底，這些木馬病毒層面的攻擊，主要還是由於用戶安全意識方面太薄弱，就不做為主要的討論對象了，我們主要還是針對安卓的應用層面的安全性進行一些討論。

三、App服務端漏洞挖掘

那我們該如何進行app漏洞的挖掘呢？首先，對於從web安全轉戰行動端漏洞挖掘的安全工作者而言，當然想挖一挖和自己所在領域比較相近的漏洞，而app的服務端基本和web安全領域的服務端差不多，只是web程序它的客戶端更多的是瀏覽器，而行動應用程式它一般都有一個可以安裝在行動裝置上的app程式。所以，對於app服務端漏洞的挖掘上面，我們照樣可以憑藉以往的web經驗，對其中的一些xss，ssrf，sql注入，任意文件讀取等漏洞進行挖掘。

在對web應用程式進行漏洞進行挖掘時，我們可以透過在瀏覽器配置代理，來對我們web應用進行抓包分析，那麼對移動端應用我們該怎麼進行資料包分析呢？ 

其實，安卓應用程式的封包分析也是要基於代理的，但代理的設定相對複雜點罷了。我們在burptsuit或fiddler中配置相應的代理後就可以使用他們進行資料包的截取和重播操作了。具體的步驟這裡就不做詳細闡述，網路上都有教程，各位可自行查閱。

這裡，對於xss，sql注入等一些經典的漏洞我就不做多說了，也沒什麼好說的，這裡主要說下移動應用的越權漏洞。我們知道，web安全性裡，越權漏洞一般時由於服務端沒有對用戶請求進行權限校驗，只憑用戶id就執行了用戶請求而導致的。那麼正確認證方式是一種什麼樣的過程呢？用文字簡單的描述就是:使用者在登陸認證成功後，服務端會將標識使用者權限寫進cookie，然後回傳給瀏覽器，瀏覽器保留下這個cookie；使用者在之後發起的請求包中帶上這個cookie ，服務端對資料包中的cookie做校驗，從而識別使用者權限，執行對應權限的操作。

圖3 cookie認證流程

當然，還有一種認證方式是session認證。 Session認證和cookie認證都可以對使用者的身分進行認證，那麼，Session認證和cookie認證方式的差別什麼呢？   

#

簡單來說，cookie存放在客戶端，而session存放在服務端。從安全的角度來說的話，cookie相對不安全，而session相對安全些，因為cookie是存放在客戶端的，攻擊者可以在客戶端獲取cookie，如果用於標識用戶身份的字段沒有進行加密，容易被枚舉，那麼，攻擊者就可以對cookie進行偽造，進而進行越權操作。而如果啟用了session認證，那麼客戶端登入成功後獲得的只是對應的session的id。這個id是一串加密的字串，是無法被遍歷的。

那麼它的認證過程又是什麼樣的呢？首先我們要知道，session認證也需要依賴cookie的，用戶在登陸成功後，服務端會將用戶對應的session寫進服務端的數據庫中，session中帶有用戶的一些身份標識等信息，然後服務端會將這個session對應的id傳送給客戶端，所以客戶端中的cookie的內容一般就只有一串sessionid=xxxxxx這樣的字串。用戶在之後發起的請求中需要帶上這個sessionid，服務端通過識別sessionid，然後查詢數據庫，獲得相應的用戶權限信息，然後再判斷用戶是否有權限執行響應的操作。

顯然，session機制要相對安全一些，但安全的另一面也是需要付出代價的，相對cookie來說，session機制會更消耗伺服器的效能。

圖4 Session認證流程

但是，在行動端，使用者身分認證是不用cookie的，而是基於token進行辨識。那麼它又是一種什麼樣的認證方式呢？用簡要的文字表述的話，它的認證過程一般是這樣的，客戶端登陸驗證成功後，服務端會返回一個token字符串，這個字符串就是該用戶的會話憑證，用戶在此後與服務端進行交互時，都要帶上這個token，這樣才能對使用者身分進行辨識。

圖5 Token認證流程

如果我們在分析封包的時候，發現有請求是不帶token的，那麼這個封包很有可能就存在越權漏洞，當然也得結合具體的場景進行分析，判斷是否對業務邏輯有影響。這是我們在行動端挖掘越權漏洞的一般姿勢。但是，這種姿勢未免太弱智，沒什麼門檻，基本上是誰碰到都能挖。

針對越權漏洞，還有一種挖掘姿勢，說起來，感覺也比較奇葩，這種越權漏洞的產生根本原因是由於認證策略本身的失誤。記得在很久以前，對一款直播軟體進行過一次協議的分析，發現其認證邏輯是這樣的：用戶登錄校驗成功後，服務端返回用戶id，然後本地生產用戶token，在此後的請求中，帶上這個token作為使用者身分的憑證。這個顯然是有bug的，因為這個用戶id是可以遍歷的，而token的生成算法是在本地，所以攻擊者只要獲取到其他用戶的id然後將本地的token生成算法摳出來，就可以自己計算token ，然後偽造用戶登陸了。

當然這種越權漏洞的挖掘難度還是比較大的，這要求漏洞挖掘者有比較深的逆向分析能力和編碼能力。但是，作為開發者，絕不能因為這種難度而放鬆對應用安全方面的加固，特別是用戶認證這種非常重要的功能模組，一定要做好安全方面的防護。

四、Apk客戶端漏洞挖掘

1、常用工具介紹

至於客戶端的漏洞，主要是透過反編譯工具對app客戶端進行反編譯，取得源碼，然後結合一些經驗及安全知識進行靜態源碼審計。常見的反編譯工具有apkide，jeb，apktools等。下面給大家截個圖，了解一下：

圖6 改之理

##圖7 Jeb

當然我最喜歡用的還是android逆向助手，非常實用。

圖8android逆向助手

結合jeb使用，基本上可以滿足日常逆向分析。

安卓應用平台主要分為native層和java層。 Java層的話，我們可以使用以上工具來分析，而native層的話，則要藉助ida來進行分析。 Ida是一款非常好用的反彙編工具，我們可以透過ida對apk的so檔案進行反彙編，然後利用其f5功能，將arm彙編程式碼轉換為c 偽程式碼，並對其中的邏輯演算法進行分析。它還支援動態調試，可遠端調試apk應用，我們可以利用ida動態調試，bypass掉一些so層中的校驗，如二次打包校驗，或者進行動態調試脫殼。

2、應用脫殼簡介

說到應用脫殼，這在apk分析過程中是很有必要的。在說脫殼之前，我們先來了解下什麼是加殼。加殼即在應用程式運作之前優先獲得程式的控制權，之後再把程式的控制權交給原來的程式。在安卓平台上的加殼實作是將原本的dex檔案加密並隱藏起來，然後透過殼程式取得原本的dex檔案再還原回去；還有一種是將函數指令抽取出來，在運行的時候，透過hook相應的類別載入函數，將指令填入。

對於加殼後的應用，原程式的邏輯基本面目全非了，我們無法透過加殼後的程式來進行安全分析。所以，我們需要對應用進行脫殼處理。常見的自動化脫殼工具有drizzledump和dexhunter。 Dexhunter很好用，但需要刷機，而且很多加密廠商都對其進行了檢查，所以直接用是行不通的，需要做一些修改，bypass一些檢測。至於詳細的使用方式，大家可以自行上網找教程，這裡就不做贅述了。如果工具不能用，那最後只好上ida了。

3、靜態原始碼審計

下面我們來詳細看一下針對原始碼層面的安全性偵測需要注意的問題。

元件安全性

首先是元件方面的安全性問題，我們知道安卓應用程式有四大元件，分別是：activity，service，content provider，broadcast receiver。這些元件如果不是很有必要，應該將其匯出屬性即exported設定為false，即禁止匯出。如果設定為true的話就會被外部應用程式調用，可能造成資訊洩露，權限繞過等漏洞。另外，在使用Intent.getXXXExtra() 取得或處理資料的時候，如果沒有做   try…catch進行異常處理的話，就可能出現拒絕服務漏洞，這些異常包括但不限於：空指標異常、型別轉換異常、陣列越界存取異常、類別未定義異常、序列化反序列化異常。

像是上面提到的元件安全，我們一般都是透過分析安卓的androidManifest.xml檔案來判斷的。 AndroidManifest.xml是Android應用的入口文件，它描述了package中暴露的元件（activities, services, 等等），他們各自的實作類，各種能被處理的資料和啟動位置。除了能宣告程式中的Activities, ContentProviders, Services, 和Intent Receivers,還能指定permissions和instrumentation（安全控制和測試）。透過分析這個manifest.xml文件，我們還可以發現例如應用資料備份和應用可調式這些漏洞。當然這些漏洞一般屬於比較低危險的漏洞，即對程式的業務邏輯不會造成太大的影響。而且應用可調式這個漏洞，其實即使設定了debuggable禁止攻擊者調試該應用，也不能夠阻止攻擊者對應用程式進行調試，因為開發者只能控制應用程式本身不受調試，但控制不了用戶的系統。攻擊者只要設定下記憶體中的屬性即可對系統中的所有應用程式進行偵錯，無論應用程式是否設定可被調試。但，這裡還是有必要做下這個禁止調試的設定的，因為並不是所有的逆向分析者都知道能夠繞過這個設定的。

webview安全性問題

要說安卓用戶端應用程式中比較嚴重的漏洞，那肯定是webview的漏洞了。現在很多App裡都內建了Web網頁，比如說很多電商平台，淘寶、京東、聚划算等等，如下圖：

圖9 webview展示圖

其實這些都是android中的一個元件webview實作的。 WebView是一個基於webkit引擎、展現web頁面的控件，它的作用是顯示和渲染web頁面，直接使用html文件作佈局，與javascript互動調用。 Webview可以單獨使用，也可以結合其他子類別一起使用。 Webview最常用的子類別有WebSettings類別、WebViewClient類別、WebChromeClient類別。這裡就不做太多介紹了，如果對安卓程式有興趣的，可以百度找更多資料。

Webview這個元件可謂是一個兩面刀，一方面，它的出現可以減輕客戶端開發的負擔，將程式的主要邏輯放到服務端上進行實現，本地只要使用webview載入對應的網頁即可，但如果配置不恰當，就可能有遠端命令執行漏洞。相關的cve有cve-2012-6636，cve-2014-1939，cve-2014-7224。

cve-2012-6636這個漏洞是源自於程式沒有正確限制使用WebView.addJavascriptInterface方法。遠端攻擊者可透過使用Java Reflection API    利用此漏洞執行任意Java    物件的方法。

cve-2014-1939 這個漏洞是由於java/android/webkit/BrowserFrame.java 使用 addJavascriptInterface API    並創建了SearchBoxImpl類別的對象，攻擊者可透過存取searchsearchJavaBridge_ 介面利用該    pl  程式碼執行任意漏洞執行任意漏洞。

cve-2014-7224 攻擊者主要是利用了accessibility和accessibilityTraversal 這兩個    Java Bridge來執行遠端攻擊程式碼。

Webview遠端指令執行的產生還需要依賴java的反射機制。 Webview    中的addJavascriptInterface方法可以往 WebView裡注入了一個    Java Object,  而這個Jave Object 的方法可以被Javascript 存取。之所以提供        addJavascriptInterface， 是為了WebView中的Javascript可以和本地的            App 通訊。這確實是一個很強大的功能，這麼做的好處在於本地App邏輯不變的情況下，不需要升級App                對程式進行更新，而修改對應的 Web頁面即可了。但在Android 的早期版本並沒有對可存取的方法做限制，利用                    Java  的反射機制，任意呼叫任意物件的任方法，這就是WebView  漏洞     

apk更新包攻擊(中間人攻擊)

上面提及的幾個漏洞是安卓應用程式中比較常見也是影響比較大的漏洞，還有一些漏洞相對影響較輕，但如果利用得當它的危害還是比較嚴重的。例如中間人攻擊，它需要攻擊者和受害者處於同一個區域網路下，受害者的流量受到攻擊者的控制。中間人攻擊能做什麼？彈個xss嗎？取得用戶    cookie？當然這裡顯然取得用戶cookie沒有用，應該是token    資訊。在行動端攻擊中，中間人攻擊利用得當甚至可以導致遠端命令執行。例如控制應用程式更新時下載的更新包，將其替換為惡意的攻擊資料包，應用程式沒有對更新包做必要的簽名校驗就執行了這個被攻擊者改造後的返回包中的更新程序，這就可能導致惡意程式程式被執行。

五、Apk漏洞靜態掃描工具實作

1、專案介紹

#對於客戶端的漏洞偵測，目前沒有什麼好的掃描引擎。前陣子調研了下某數位公司，某梆，某加密的apk安全掃描工具，效果一般，基本上差不多，都是基於反編譯後的源碼進行的簡單漏洞驗證。那我們是否也可以自己寫一個自動化檢測工具呢？我之前也自己寫了一個    apk自動化漏掃工具。

下面我來講一下我的實作思路，首先我們知道，我們主要的分析對像是AndroidManifest.xml和dex 文件，但這兩個都是編譯後的二進位文件，我們需要將他們反編譯出來。反編譯    AndroidManifest.xml需要用到的工具是AXMLPrinter.jar，而反編譯 dex檔案需要用到的檔案是        baksmali.jar。其實這兩個jar包也是一些逆向工具常用的 jar包。我們來看看           android逆向助手這款反編譯工具的程式目錄：

圖10 安卓反向助理程式目錄

這個名叫android反向助手的反向工具主要就是用了這兩個工具實現對AndroidManifest 和   dex檔案進行反編譯的。

我們的自動化漏掃工具中只要編寫對應的邏輯，呼叫這兩個工具將AndroidManifest和dex 檔案反編譯出來後，我們就可以透過匹配一些漏洞特徵，對漏洞進行偵測了。

以下是專案目錄結構的簡單介紹：

#圖11 Apk漏洞掃描專案目錄及簡介

首先我們需要應用的包名，然後對application的一些設定進行檢測，如是否允許備份，是否可調式等；然後獲得acvitiy ，    service，content provider，broadcast receiver 這四個組件的一些配置信息，判斷是否可導出；然後取得應用程式申請的權限，判斷其是否過於敏感；取得應用程式自身建立的權限，判斷下它是否做好了權限限制。

接下來對反編譯後的smali檔案進行漏洞特徵檢測。這主要是依賴與我們事先收集好的漏洞特徵。這裡我把漏洞特徵寫到了一個xml 檔中，在啟動漏洞掃描的時候，載入到記憶體中，供程式呼叫。我們可以自訂這些漏洞特徵，讓我們的程式可以掃描到更多的漏洞。目前漏洞特徵的定義支援字串和正規形式。這個項目目前還在維護，不過基本功能都已經實現，可以滿足日常的掃描檢測，只要稍微對掃描結果進行一些排誤即可。

2、目前軟體支援的漏洞偵測類型

1、任何檔案讀寫漏洞

2、金鑰硬編碼漏洞

# 3.強制類型轉換本機拒絕服務漏洞

4、系統元件本機拒絕服務漏洞

5、Intent Schema URL漏洞

6、Content Provider元件本機SQL        注入漏洞

7、程式碼動態載入安全偵測

8、憑證弱校驗

#9、主機名稱弱校驗

10、HTTPS敏感資料劫持漏洞

11、Hash演算法不安全

12、AES弱加密

13、Locat洩漏隱私資訊

14、日誌外洩風險

15、PendingIntent誤用風險

16、Intent隱式呼叫

17、資料庫檔案任意讀寫

18、WebView系統隱藏介面漏洞偵測

19、WebView元件遠端程式碼執行漏洞偵測

20、WebView忽略SSL憑證錯誤偵測

21、WebView明文儲存密碼

22、SharedPreferences任意讀寫入

23、任意檔案讀寫

24、隨機數使用不安全

25、元件權限檢查

26、應用程式是否可調式檢查

27、應用程式權限檢查

28、應用自訂權限檢查

#30、套用備份漏洞檢查

3、使用方法

1、將需要掃描的apk檔案放到workspace/apk        目錄下方

2、AndroidCodeCheck.exe或執行python AndroidCodeCheck.py      

##4、報告輸出

報告輸出路徑在report下

1）txt格式

算是程式的執行日誌吧，也可以作為掃描結果參考。

2）html格式

html格式的報表有目錄，點選目錄中的漏洞名稱即可跳到對應的漏洞類型說明。在類型說明處可點選返回目錄返回漏洞目錄列表，方便漏洞審閱。

最後給一個漏洞掃描的報告截圖，有點簡陋，後期會逐步完善。

            圖12 報表目錄首頁

圖13 漏洞詳情

#5、專案位址

Apk靜態原始碼漏掃工具項目位址：

https://github.com/zsdlove/ApkVulCheck

以上是如何分析APK安全及自動化審計的詳細內容。更多資訊請關注PHP中文網其他相關文章！