鑽石舞台

目 錄

一、前言

二、Android App漏洞掃描的難點

三、個人掃描器和商業化漏洞掃描器的區別

四、半自動化和自動化漏洞掃描的區別

五、基於文本匹配的半自動化靜態漏洞掃描器介紹及優化

六、基於靜態污點分析的半自動化漏洞掃描器介紹及優化

七、研究經驗總結

八、未來優化方向

一、前 言

在Android應用層安全研究領域，研究人員大多採用人工審計加腳本的方式進行漏洞挖掘。針對某個新的攻擊面，對手機廠商上千款的預置App開展批量的漏洞挖掘時，短時間內很難產出結果，漏洞挖掘效率低。

在2021年7月上旬，啟明星辰ADLab基於開源工具二次開發，編寫了一套半自動化靜態漏洞掃描工具以輔助漏洞挖掘。在2021年8月底，僅3天時間，用這套工具在小米手機上挖掘到10餘處高危漏洞及若干中危漏洞，位列小米SRC 2021 TOP1。

本文主要介紹半自動化漏洞挖掘關鍵技術以及一些研究經驗總結。

二、Android App漏洞掃描的難點

由於Java的語言特性，掃描器在某些情況下存在漏報、誤報。此外很多App漏洞都屬於邏輯漏洞，和代碼邏輯強相關。與棧溢出等安全漏洞不同，我們很難直接通過掃描逆向後的App代碼得到準確的結果，基本都需要研究員介入做最後的漏洞確認。典型的場景就是Webview Jsbridge漏洞。掃描器確實可以掃描出從外部輸入被解析到輸入數據被Webview加載的代碼執行路徑，但Jsbridge漏洞最關鍵的域名校驗策略有多種寫法，代碼實現完全取決於開發者。掃描器在處理這種漏洞時只能承擔輔助作用，即幫助研究員定位哪些代碼路徑可觸發Webview Jsbridge函數，而不能直接得到『存在Webview Jsbridge漏洞』的結果。

同時Android系統誕生的時間足夠長且代碼開源，故市面上已經存在非常成熟且開源的漏洞掃描工具，內卷極其嚴重。很多時候比的不是掃描邏輯，而是比誰的漏洞模板和數據建模更優秀。

三、個人掃描器和商業化掃描器的區別

根據不同的掃描目的（如企業使用、個人使用），掃描器可分為個人掃描器和商業化掃描器。主要存在以下4個區別：

四、半自動化和自動化漏洞掃描的區別

半自動化漏洞掃描指的是需要在掃描過程中或掃描結束後人工參與的漏洞掃描。大多數情況下是指掃描結束後需要研究員二次確認漏洞是否真實存在。Android應用層漏洞因其特性，存在很多邏輯漏洞，所以對於個人研究者而言，半自動化掃描器會是更好的選擇。

五、基於文本匹配的半自動化靜態漏洞掃描器介紹及優化

5.1 實現原理

首先利用反編譯工具（如jadx）將dex轉換為Java源碼並保存到本地，然後執行文本掃描，可簡化為執行grep（正則匹配），最後按照掃描模板中定義的漏洞點識別文本，一旦匹配則保留結果。

其中，掃描模板決定了該漏洞掃描器的漏洞發現率。只要漏洞模板定義得足夠好，可以保證大部分的漏洞類型不出現漏報。但該掃描策略顆粒度太大，一定會存在誤報，需要研究員人工確認。

5.2 開源工具MobSF

MobSF[1]是目前許多文本匹配掃描器的始祖。其核心實現（文本匹配）邏輯簡單，大量類品只是基於該框架增刪改UI、增加漏洞掃描模板等。為避免重複造輪子浪費時間，我們最終選擇了MobSF，在此基礎上進行拓展優化目標。

圖2展示的ISSUE僅為使用MobSF的『預置漏洞模板』得到的結果，並非實際可用漏洞，僅用作界面展示。

當用戶點擊FILES標籤下的代碼文件，如`xx /xx/common/xx.java`後，程序會自動打開並加載目標源文件。

MobSF掃描器以yaml格式解析漏洞掃描模板[2]:

MobSF的優點：

MobSF的缺點：

占用磁盤空間大。以小米手機為例，300個預裝App分析後占用的磁盤大小為40G~60G。

5.3 拓展和優化

本節主要介紹對該框架進行拓展以及優化時使用到的技術及思考。

六、基於靜態污點分析的半自動化漏洞掃描器介紹及優化

6.1 污點分析的基本介紹

污點分析分為靜態和動態，這裡介紹靜態的污點分析。污點分析的原則是：

跟蹤和污點數據相關的信息的流向，根據特定的規則判斷它們是否會影響某些代碼邏輯，進而挖掘程序漏洞。

6.2 邏輯梳理

如果現在要編寫基於靜態污點分析的掃描器來分析App是否存在Webview jsbridge攻擊點（Intent轉發漏洞也一樣），先梳理一下思維：

因此核心在於：

那如何知道這個Android App中哪些Activity是導出的？又該怎麼獲得方法和方法之間的調用關係呢？我們可以藉助Androguard[3]。這款工具是現在很多Android靜態分析工具的核心，它會分析dex並完全解析其中的類、方法，生成相關的Python類，在Androguard分析完後，某個類/方法調用了誰，誰調用了它，全都保留在內存里。而研究人員只需要進行正序或者逆序的溯源即可（即在Androguard上做二次開發，添加自己的邏輯）。

這裡以逆序的溯源為例：

至此，掃描器就找到了一條外部可控的攻擊路徑，接着研究員便可執行漏洞的可利用分析。

6.3 開源工具Jandroid

與『基於文本匹配的半自動化掃描器』一樣，『基於靜態污點分析』的半自動化漏洞掃描器也存在很好的開源實現。Jandroid[4]掃描器於2019年年底公開。

Jandroid掃描模板[5]：

Jandroid掃描結果為可視化的節點：

『基於靜態污點分析』的優點：較之於文本匹配，該掃描策略掃描速度更快。無需轉換dex為java源碼，速度是文本匹配掃描器的2~4倍。採用基於調用關係依賴的掃描策略，所以只要模板定義得好，誤報率會很低，在掃描『ZIP包路徑穿越』、『Intent轉發』、『命令注入』等漏洞時有奇效。且不占用太多磁盤空間。

『基於靜態污點分析』的缺點：經研究發現，這種分析策略因Java的語言特性限制存在很大不足，導致漏報率較高，只能當作輔助審計的工具，故將其擱置。例如，作為一個瀏覽器App，基本都會有導出且具備Browable屬性的Activity，同時該Activity會調用webview.loadUrl打開指定網頁。但令人驚訝的是，我們使用該掃描策略掃描了3款主流瀏覽器應用，卻只掃出1款瀏覽器存在少許符合條件的Activity。同時經人工確認，該款App也不止具備這幾個符合條件的Activity，該掃描策略的漏報率極高。

6.4 漏報原因以及解決方案

Java是一個面向對象的語言，擁有4大特性：封裝、繼承、多態、抽象。Java也存在反射機制。為了實現『一次編譯，多平台共用』的目的，在程序語言和機器語言中間布置了一個中間層即JVM。JVM擁有自己的堆用於存放生成的對象，也有自己的堆管理策略。

以Java的接口舉例。在Java中，如果要創建一個接口的實例，就需要使用一個類來實現這個接口，並使用new關鍵詞（或者其他實例化的方法）標記以便JVM將其實例化，而JVM在運行時才會為對象分配內存並調用其構造函數。故只有在運行時程序才能知道該對象具體的類型是什麼，才能進一步去尋找需要調用的目標函數。

前面我們已經提到，Androguard在靜態分析時會梳理方法和方法之間的調用關係並構建調用鏈。但如果目標方法依賴的是一個接口，而接口的具體實現又只能在運行時才會實例化，這就會導致Androguard在靜態分析時無法定位這個接口的真實實例，從而導致調用鏈的斷開。

同時，基於Java的語言特性，Android開發者們有很多花哨的代碼寫法，很典型的便是EventBus、Rxbus。以事件總線舉例，可以將其簡單地理解為一個隊列Queue。

前面介紹到了，『調用關係依賴』的漏洞掃描策略是利用方法和方法之間的顯式調用關係來生成回溯鏈的。在這種情況下，事件的發出方只知道調用了事件管理類Manager的event_in函數，但在靜態的情況下不知道到底被哪個註冊者的event_handle函數處理了，所以也就沒有辦法繼續維護該回溯鏈，從而導致漏報（即多態導致漏報）。

在2019年底接觸到這種掃描策略後，就考慮過如何解決這個問題。結論是，如果能加上一些語法分析以及機器學習，便能部分解決這個問題。當然，動態分析也能解決這個問題。

但對個人安全研究者而言，這種解決方案成本太高，個人研究者並沒有必要死磕。編寫漏洞掃描工具的本意就是為了更高效地挖洞。如果編寫漏洞挖掘工具的成本是人工審計加腳本挖掘的幾倍甚至幾十倍，那也就沒有編寫漏洞掃描器的意義了（如果是商業掃描器，或者企業內部的掃描器，自然有必要解決這個問題）。

另外我們相信，不能過於依賴掃描器的準確率。作為掃描器而言，如果這個掃描器的掃描結果有效率是99.9%，那也仍有0.1%的概率漏報。以數學的概念理解，0.1%和99.9%相比太小，完全可以忽略。但如果這0.1%中恰好包含嚴重漏洞呢？出現『前99.9%的漏洞總價值100美元，這0.1%的漏洞價值20萬美元』的情況也是可能的。故我們認為個人研究員在編寫掃描器時除了準確率外還需要有兜底策略，即防禦漏報。因彼時（2019年底）的研究重心並不在移動安全，故未再深入研究。

2021年7月，在編寫『基於文本匹配的半自動化漏洞掃描器』時，我們想到可以結合這兩個掃描器，將他們的優勢互補，便可很大程度彌補各自的缺陷。此時我們編寫的並非商業化掃描器，而是個人掃描器，因此無需一個技術點上死磕。只要能解決問題，那就是好辦法。

『基於靜態污點分析的掃描器』確實會存在漏報，但『基於文本匹配的掃描器』並不會。即使某些漏洞使用『基於文本匹配的掃描器』掃描也不能得到確切的結果，但至少可以拋出問題，避免出現『遺漏漏洞』的情況，此時只需結合人工審計即可覆蓋所有的攻擊點。

同時『基於靜態污點分析的掃描器』也會在一定程度上彌補『基於文本匹配的掃描器』容易誤報的問題。只需編寫一個Bridge合併它們掃描的數據和結果即可。

這樣，研究員便能以很小的代價得到一個相對好的結果。

2021年7月，我們在編寫這款漏洞掃描器1.0時，只花了不到2周時間（大部分時間用於微調UI和優化輸出），就得到了很好的結果。後續的2.0優化，也不過1周多的時間。

七、研究經驗總結

八、未來優化方向

將結合Android框架層的機制挖掘OEM App的一些獨特攻擊面，並考慮結合動態分析。因目前的掃描器已能完成大部分的任務，故未來再根據實際需求對其進行相應優化。

參考鏈接：