APP漏洞自動化掃描專業評測報告（中篇）

前言

上一篇中通過對阿里聚安全[1]、360App漏洞掃描[2]、騰訊金剛審計系統[3]、百度移動雲測試中心[4]以及AppRisk Scanner[5] 在收費情況、樣本測試後的掃描時間對比和漏洞項專業對比後，本篇將以各個廠商的掃描能力作爲分析維度展開。

測試方法

使用自己編寫的測試APP測試各個掃描平臺的掃描能力。這些掃描能力主要分爲靜態檢測能力和動態檢測能力。靜態檢測能力包括檢測隱藏dex、過程間分析、較複雜漏洞檢測、逆向分析；動態測試主要是指測試拒絕服務漏洞的能力，拒絕服務漏洞又可以劃分爲：空Intent引起的拒絕服務，強制類型轉換引起的拒絕服務以及序列化對象導致的拒絕服務。由於這些檢測能力決定了掃描器掃描結果的精度和準度，因此我詳細分析了各個掃描平臺的掃描能力。

3.2.1 自動化脫殼

目前很多APP通過加殼來防止自己被反編譯，而掃描器都是通過在反編譯的代碼中進行漏洞的掃描。如果掃描器不能自動化地脫去APP加的殼，則根本無法進行有效的漏洞掃描分析。我寫了一個包含五個掃描平臺都有的全局文件讀寫漏洞的demo，通過梆梆加固之後，重簽名上傳到這五個掃描平臺，檢測結果是：阿里聚安全和百度檢測出全局文件讀寫漏洞，而金剛、AppRisk沒有檢測出該漏洞。這個demo在360中沒有掃描結果，所以360的脫殼能力不得而知。

3.2.2 隱藏Dex檢測能力

目前插件化已經在Android開發中越來越普遍。很多APP會將一些獨立模塊打包成單獨的dex文件，並存儲到apk的其他目錄中，如asset、lib等。如果掃描器沒有檢測隱藏dex文件的能力，則可能會漏報一些安全風險，造成掃描結果不準確。我編寫了一個asset目錄包含dex文件的應用程序，分別上傳到上述五個掃描器，該dex文件中包含五家掃描器都可以檢測的漏洞，結果只有阿里聚安全和百度成功掃描出隱藏dex文件中包含的漏洞。因此，可以推測阿里聚安全和百度具有掃描隱藏dex文件的能力，而360、金剛、百度和AppRisk都沒有檢測隱藏dex文件的能力。

3.2.3 過程間分析能力

五家掃描器都可以檢測全局文件讀寫漏洞，因此我用該漏洞測試掃描器對過程間分析的能力。

openFileOutput的第二個參數可以指定文件打開的方式，如果以全局可寫的方式打開會導致安全風險。這裏我構造了兩個測試例子。

例一， 直接對openFileOutput的第二參數設置全局可寫，因此有漏洞。

例二， 通過函數的參數傳遞對openFileOutput的第二參數設置全局可寫，也應該有漏洞。

測試代碼如下：

樣本一：函數內設置危險變量Context.MODE_WORLD_WRITEABLE

樣本二：函數間設置危險變量Context.MODE_WORLD_WRITEABLE

樣本一和樣本二可以測試掃描器對過程間分析的檢測能力。檢測結果如表3-6所示（“√”表示掃描結果正確，“×”表示掃描結果錯誤。）：

表3-6 函數間相互調用檢測能力

	阿里聚安全	360	金剛	百度	AppRisk
過程內檢測（樣本一）	√	√	√	√	√
過程間檢測（樣本二）	√	×	×	×	×

阿里聚安全可以檢測出樣本一和樣本二，而360、金剛、百度和AppRisk都只能檢測出樣本一。

由此可以推測，360、金剛、百度和AppRisk都只能在過程內進行檢測，也就是在函數內進行檢測，阿里聚安全可以在過程間進行檢測。

3.2.4 逆向分析能力

目前漏洞掃描規則大部分是通過定位關鍵函數，根據關鍵函數的參數確定是否會觸發漏洞。這是典型的逆向分析問題，可以說逆向分析能力很大程度決定了掃描器檢測漏洞的能力。這五家掃描器都有逆向分析的能力，只是逆向分析的能力有些差別。通過掃描器對全局文件讀寫的代碼檢測結果分析掃描器逆向分析的能力。

根據全局文件讀寫漏洞的檢測規則，掃描器首先會定位openFileOutput函數，追蹤該函數的第二個參數，即打開的模式。打開模式都存儲在一個數組中。數組中下標爲0的模式沒有漏洞，而下標爲1的有漏洞。如果掃描結果正確，則說明掃描器的逆向分析能力較強，可以深入到數組等較爲複雜的結構中；如果掃描結果有錯誤，則說明掃描器的逆向分析能力較差，無法逆向追蹤到複雜的數據結構中，漏報的可能性較大。

將上述測試代碼上傳到五家掃描平臺，掃描結果如下圖所示。“√”表示掃描結果正確，“×”表示掃描結果錯誤。

表3-7 數組下標敏感性檢測結果

	阿里聚安全	360	金剛	百度	AppRisk
樣本一	√	√	√	√	√
樣本二	√	×	×	×	×

通過掃描結果可以看到，阿里聚安全正確地掃描出兩個樣本，而360、金剛、百度和AppRisk都只掃描出樣本一。因此可以說阿里聚安全的逆向掃描能力要強於其他四家，當逆向追蹤的變量進入一個數組時，阿里聚安全可以繼續在數組中進行逆向分析，而其他四家掃描器無法確定數組中各個位置代表的具體值。

我猜測當其他四家掃描器檢測全局文件讀寫漏洞時，首先會定位openFileOutput函數，由於打開方式是由數組中的元素決定，所以360、金剛、百度和AppRisk無法確定該值具體是多少，因此也就無法判斷是否存在全局文件讀寫漏洞。本着減少誤報的原則，它們都認爲不存在漏洞，所以很幸運，樣本一不存在漏洞，它們的檢測結果正確；樣本二存在漏洞，它們的檢測結果錯誤。

3.2.5檢測較複雜漏洞的能力

爲了測試掃描器檢測是否能檢測出由多個條件組合起來判斷的漏洞，我選取了Intent Scheme URL漏洞進行對比［6］，如果想避免Intent Scheme URL漏洞，parseUri函數得到的Intent必須要設置三個條件(addCategory(“android.intent.category.BROWSABLE”), setComponent(null), setSelector(null) 才能保證漏洞不會發生。

我構造了三個例子進行測試：

例一，三個條件都滿足，因此沒有漏洞的。

例二，缺少了條件setSelector(null)，存在Intent Scheme URL漏洞。

例三，雖然三個條件都滿足，但因爲沒有startActivity所以也不應該被檢測出來。

構造如下測試代碼：

代碼中一共有三個case，其中只有case 2有問題。將上述代碼打包成apk，上傳到除360和百度之外的三家掃描平臺。（360和百度不支持該掃描項，還需要使用另一種漏洞比較360、百度的檢測差異）

AppRisk認爲三個都有漏洞，通過其掃描報告可以看出，AppRisk只是判斷是否有Intent.parseUri函數的調用，如果存在，則就存在Intent Scheme URL漏洞。因此，推測AppRisk的掃描規則僅僅是簡單的特徵函數匹配，數據流跟蹤的能力幾乎沒有。在該例中僅僅匹配Intent.parseUri，而沒有其他條件進行約束，因此誤報率比較高。

金剛掃掃描出case 2和case 3，而case 3是沒有問題的，所以有一個誤報。金剛對該項的掃描比AppRisk要複雜一些，除了匹配parseUri函數外，還檢測該Intent是否做了後續的處理，如addCategory、setComponent、setSelector等，如果沒有這些函數調用，則認爲存在該漏洞。但如果僅僅把Intent構造出來，而沒有做任何啓動其他組件的操作，如case 3，也是沒有漏洞的，所以金剛沒有考慮對獲取Intent的使用操作，也容易引起誤報。

360沒有掃描這個漏洞，而其他常見的漏洞漏報也比較多。因此，對它的檢測較複雜漏洞的能力不做推測。

當檢測百度時，我使用WebView組件系統隱藏接口漏洞作爲測試用例。

測試代碼如下：

將代碼打包成apk上傳到百度移動雲測試平臺，測試百度是否僅僅測試是否有loadUrl函數調用，而不考慮是否啓用了JavaScript。從測試代碼中可以看出，case 1是有漏洞的，通過調用setJavaScriptEnabled(true)啓用了JavaScript，隨後調用loadUrl加載頁面。Case 2是沒有問題的，首先mWebView是一個全局的成員變量，當創建一個WebViewSafeCase的對象時會初始化該WebView，同時顯式調用removeJavascriptInterface移除searchBoxJavaBridge，accessibility以及accessibilityTraversal，當外部調用其內部類的方法時，mWebView會啓用JavaScript，隨後調用loadUrl。如果單從removeFromOutterClassShouldNotFound來看，case 2是有漏洞的，但是實際上mWebView在調用loadUrl之前已經移除隱藏的接口了，如果掃描器沒有追蹤mWebView這個變量的能力，則很容易誤認爲case 2是有漏洞的。

百度的掃描結果顯示case 1和case 2都包含WebView未移除隱藏接口漏洞，我推測百度沒有追蹤變量的能力，而僅僅是進行函數匹配。

3.2.6 動態檢測能力

一些運行時漏洞，如拒絕服務，只有在程序運行時纔有可能觸發。如果掃描器沒有動態檢測的能力，則會漏報一些運行時漏洞。爲了檢測掃描器是否有動態掃描的能力，我在測試APP中包含4處拒絕服務漏洞的代碼，分別是空Intent拒絕服務2個、1個強制類型轉換拒絕服務和1個對象序列化拒絕服務。掃描結果如下表所示。

表3-8 動態檢測能力掃描結果

	阿里聚安全	360	金剛	百度	AppRisk
空Intent Fuzz	2	0	1	0	0
強制類型轉換	1	0	1	0	0
對象序列化	1	0	1	0	0

從表3-8中可以看出，阿里聚安全可以掃描出所有的拒絕服務漏洞，金剛可以掃描出3處拒絕服務漏洞，漏報一處拒絕服務代碼如下：

而360、百度和AppRisk沒有掃描出拒絕服務漏洞。從這個例子我推斷除阿里聚安全和金剛外，其他掃描平臺沒有動態檢測能力。

綜上所述，阿里聚安全的綜合檢測能力最高，它不僅可以檢測隱藏dex，對數組下標敏感，還可以檢測函數相互調用引起的漏洞。除此之外，阿里聚安全還可以追蹤變量，記錄變量的一系列操作，當變量作爲sendMessage的參數被Handler發送出去時，阿里聚安全還可以追蹤到相應的處理函數中繼續追蹤；當變量作爲Intent攜帶的參數跳轉到其他組件中時，阿里聚安全還可以到對應的組件中繼續追蹤該變量。對變量的有效跟蹤可以大大提高掃描結果的可靠性，有效降低了掃描結果的誤報率。

百度可以檢測隱藏的dex文件，但它不能追蹤變量，無法處理函數間調用引起的漏洞，對數組下標也不能準確地處理，因此我推測百度的掃描規則是基於危險API所在的函數範圍內，一旦超出這個函數，百度的誤報率會大大提高。

360掃描結果讓人看不明白，分析中所有的應用一旦投入到360，不但掃描時間長，而且結果與其他四家差別很大，所以這裏不對360的掃描能力做推測。

金剛和AppRisk的掃描能力相對較差，只能通過簡單的特徵函數匹配檢測漏洞，雖然漏報相對較少，但是誤報率比較高。

掃描能力小結

以下表3-9是此次掃描能力的結果：

表3-9 掃描能力總覽

	阿里聚安全	360	金剛	百度	AppRisk
自動化脫殼	√	未知	×	√	×
靜態-檢測隱藏Dex	√	×	×	√	×
靜態-過程間分析	√	×	×	×	×
靜態-較複雜漏洞	√	×	×	×	×
靜態-逆向分析	√	√	√	√	√
動態-空Intent Fuzz	√	×	√	×	√
動態-綜合靜態分析	√	×	√	×	×
動態-複雜對象Fuzz	√	×	√	×	×

需要注意的是， 360一直沒有測試APP的掃描結果，我只好把每個檢測代碼打包成APP進行測試，然後進行統計，因此關於360的測試結果可能有誤差。

除了掃描能力以外，最後一個維度會以之前的4個第三方APP的測試結果作爲對比。爲了說明各個掃描平臺實際掃描漏洞的能力，我將WiFi萬能鑰匙、墨跡天氣、手機百度以及新浪微博上傳到五家掃描平臺。最後將以WiFi萬能鑰匙的掃描結果爲例，詳細分析一下各個平臺的掃描結果的漏報和誤報，從而評估其掃描結果的可信性。這部分內容將單獨作爲下篇進行連載，敬請期待。

Reference：

［1］阿里聚安全：http://jaq.alibaba.com/

［2］360APP漏洞掃描：http://dev.360.cn/mod/vulscan/

［3］騰訊金剛審計系統：http://service.security.tencent.com/kingkong

［4］百度移動雲測試中心：http://mtc.baidu.com/startTest/safe

［5］AppRisk Scanner：https://apprisk.newskysecurity.com

［6］ http://www.mbsd.jp/Whitepaper/IntentScheme.pdf