摘要：前言上一篇中通過對阿里聚安全漏洞掃描騰訊金剛審計系統百度移動云測試中心以及在收費情況樣本測試后的掃描時間對比和漏洞項專業對比后，本篇將以各個廠商的掃描能力作為分析維度展開。表示掃描結果正確，表示掃描結果錯誤。

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

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

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

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

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

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

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

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

測試代碼如下：

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

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

樣本一和樣本二可以測試掃描器對過程間分析的檢測能力。

檢測結果如表 3-6 所示（“√”表示掃描結果正確，“×”表示掃描結果錯誤）

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

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

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

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

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

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

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

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

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

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

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

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

但由于 360 和百度不支持該掃描項，還需要使用另一種漏洞比較 360 、百度在正向分析能力上的差異。
構造如下測試代碼：

代碼中一共有三個 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 未移除隱藏接口漏洞，我我們推測百度沒有追蹤變量的能力，而僅僅是進行函數匹配。而阿里聚安全可以追蹤 mWebView 這個變量，并記錄這個變量所做的操作，在該例中可以記錄 mWebView 顯式的移除了三個可能引起遠程代碼執行的接口，當 mWebView 調用了 loadUrl 時，阿里聚安全可以確定該調用不存在隱藏接口未移除的漏洞。

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

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

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

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

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

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

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

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

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

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

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

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

［ 3 ］ 騰訊金剛審計系統 http://service.security.tence...

［ 4 ］ 百度移動云測試中心 http://mtc.baidu.com/startTes...

［ 5 ］ AppRisk Scanner https://apprisk.newskysecurit...

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