淺談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文件作佈局，與java交互調用。Webview可以單獨使用，也可以結合其他子類一起使用。Webview最常用的子類有WebSettings類、WebViewClient類、WebChromeClient類。這裏就不做過多介紹了，如果對安卓編程感興趣的，可以百度查找更多資料。

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

cve-2012-6636這個漏洞是源於程序沒有正確限制使用WebView.addJavaInterface方法。遠程攻擊者可通過使用Java Reflection API利用該漏洞執行任意Java對象的方法。

cve-2014-1939這個漏洞是由於java/android/webkit/BrowserFrame.java 使用addJavaInterface API並創建了SearchBoxImpl類的對象，攻擊者可通過訪問searchBoxJavaBridge_接口利用該漏洞執行任意Java代碼。

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

Webview遠程命令執行的產生還需要依賴java的反射機制。Webview中的addJavaInterface方法可以往WebView裏注入了一個Java Object, 而這個Jave Object 的方法可以被Java 訪問。之所以提供addJavaInterface，是爲了WebView中的Java可以和本地的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、應用備份漏洞檢查