摘要：前言上一篇中通過對(duì)阿里聚安全漏洞掃描騰訊金剛審計(jì)系統(tǒng)百度移動(dòng)云測(cè)試中心以及在收費(fèi)情況樣本測(cè)試后的掃描時(shí)間對(duì)比和漏洞項(xiàng)專業(yè)對(duì)比后，本篇將以各個(gè)廠商的掃描能力作為分析維度展開。表示掃描結(jié)果正確，表示掃描結(jié)果錯(cuò)誤。

上一篇中通過對(duì)阿里聚安全[1]、360App 漏洞掃描[2]、騰訊金剛審計(jì)系統(tǒng)[3]、百度移動(dòng)云測(cè)試中心[4]以及AppRisk Scanner[5] 在收費(fèi)情況、樣本測(cè)試后的掃描時(shí)間對(duì)比和漏洞項(xiàng)專業(yè)對(duì)比后，本篇將以各個(gè)廠商的掃描能力作為分析維度展開。

使用自己編寫的測(cè)試 APP 測(cè)試各個(gè)掃描平臺(tái)的掃描能力。這些掃描能力主要分為靜態(tài)檢測(cè)能力和動(dòng)態(tài)檢測(cè)能力。靜態(tài)檢測(cè)能力包括檢測(cè)隱藏 dex 、過程間分析、較復(fù)雜漏洞檢測(cè)正向分析、逆向分析；動(dòng)態(tài)測(cè)試主要是指測(cè)試拒絕服務(wù)漏洞的能力，拒絕服務(wù)漏洞又可以劃分為：空 Intent 引起的拒絕服務(wù)，強(qiáng)制類型轉(zhuǎn)換引起的拒絕服務(wù)以及序列化對(duì)象導(dǎo)致的拒絕服務(wù)。由于這些檢測(cè)能力決定了掃描器掃描結(jié)果的精度和準(zhǔn)度，因此我詳細(xì)分析了各個(gè)掃描平臺(tái)的掃描能力。

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

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

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

openFileOutput 的第二個(gè)參數(shù)可以指定文件打開的方式，如果以全局可寫的方式打開會(huì)導(dǎo)致安全風(fēng)險(xiǎn)。這里我構(gòu)造了兩個(gè)測(cè)試?yán)印?/p>

例一， 直接對(duì) openFileOutput 的第二參數(shù)設(shè)置全局可寫，因此有漏洞。

例二， 通過函數(shù)的參數(shù)傳遞對(duì) openFileOutput 的第二參數(shù)設(shè)置全局可寫，也應(yīng)該有漏洞。

測(cè)試代碼如下：

樣本一：函數(shù)內(nèi)設(shè)置危險(xiǎn)變量 Context.MODE_WORLD_WRITEABLE

樣本二：函數(shù)間設(shè)置危險(xiǎn)變量 Context.MODE_WORLD_WRITEABLE

樣本一和樣本二可以測(cè)試掃描器對(duì)過程間分析的檢測(cè)能力。

檢測(cè)結(jié)果如表 3-6 所示（“√”表示掃描結(jié)果正確，“×”表示掃描結(jié)果錯(cuò)誤）

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

由此可以推測(cè)， 360 、金剛、百度和 AppRisk 都只能在過程內(nèi)進(jìn)行檢測(cè)，也就是在函數(shù)內(nèi)進(jìn)行檢測(cè)，阿里聚安全可以在過程間進(jìn)行檢測(cè)。

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

根據(jù)全局文件讀寫漏洞的檢測(cè)規(guī)則，掃描器首先會(huì)定位 openFileOutput 函數(shù)，追蹤該函數(shù)的第二個(gè)參數(shù)，即打開的模式。打開模式都存儲(chǔ)在一個(gè)數(shù)組中。數(shù)組中下標(biāo)為 0 的模式?jīng)]有漏洞，而下標(biāo)為 1 的有漏洞。如果掃描結(jié)果正確，則說明掃描器的逆向分析能力較強(qiáng)，可以深入到數(shù)組等較為復(fù)雜的結(jié)構(gòu)中；如果掃描結(jié)果有錯(cuò)誤，則說明掃描器的逆向分析能力較差，無法逆向追蹤到復(fù)雜的數(shù)據(jù)結(jié)構(gòu)中，漏報(bào)的可能性較大。

將上述測(cè)試代碼上傳到五家掃描平臺(tái)，掃描結(jié)果如下圖所示?！啊獭北硎緬呙杞Y(jié)果正確，“×”表示掃描結(jié)果錯(cuò)誤。

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

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

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

我構(gòu)造了三個(gè)例子進(jìn)行測(cè)試。

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

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

例三，雖然三個(gè)條件都滿足，但因?yàn)闆]有 startActivity 所以也不應(yīng)該被檢測(cè)出來。

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

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

AppRisk 認(rèn)為三個(gè)都有漏洞，通過其掃描報(bào)告可以看出， AppRisk 只是判斷是否有 Intent.parseUri 函數(shù)的調(diào)用，如果存在，則就存在 Intent Scheme URL 漏洞。因此，推測(cè) AppRisk 的掃描規(guī)則僅僅是簡(jiǎn)單的特征函數(shù)匹配，正向分析幾乎沒數(shù)據(jù)流跟蹤的能力幾乎沒有。在該例中僅僅匹配 Intent.parseUri ，而沒有其他條件進(jìn)行約束，因此誤報(bào)率比較高。

金剛掃掃描出 case 2 和 case 3 ，而 case 3 是沒有問題的，所以有一個(gè)誤報(bào)。金剛對(duì)該項(xiàng)的掃描比 AppRisk 要復(fù)雜一些，除了匹配 parseUri 函數(shù)外，還檢測(cè)該 Intent 是否做了后續(xù)的處理，如 addCategory 、 setComponent 、 setSelector 等，如果沒有這些函數(shù)調(diào)用，則認(rèn)為存在該漏洞。但如果僅僅把 Intent 構(gòu)造出來，而沒有做任何啟動(dòng)其他組件的操作，如 case 3 ，也是沒有漏洞的，所以金剛沒有考慮對(duì)獲取 Intent 的使用操作，也容易引起誤報(bào)。

360 沒有掃描這個(gè)漏洞，而其他常見的漏洞漏報(bào)也比較多。因此，對(duì)它的正向分析能力不做過多推檢測(cè)較復(fù)雜漏洞的能力不做推測(cè)測(cè)。

當(dāng)檢測(cè)百度的正向分析能力時(shí)，我使用 WebView 組件系統(tǒng)隱藏接口漏洞作為測(cè)試用例。

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

百度的掃描結(jié)果顯示 case 1 和 case 2 都包含 WebView 未移除隱藏接口漏洞，我我們推測(cè)百度沒有追蹤變量的能力，而僅僅是進(jìn)行函數(shù)匹配。而阿里聚安全可以追蹤 mWebView 這個(gè)變量，并記錄這個(gè)變量所做的操作，在該例中可以記錄 mWebView 顯式的移除了三個(gè)可能引起遠(yuǎn)程代碼執(zhí)行的接口，當(dāng) mWebView 調(diào)用了 loadUrl 時(shí)，阿里聚安全可以確定該調(diào)用不存在隱藏接口未移除的漏洞。

一些運(yùn)行時(shí)漏洞，如拒絕服務(wù)，只有在程序運(yùn)行時(shí)才有可能觸發(fā)。如果掃描器沒有動(dòng)態(tài)檢測(cè)的能力，則會(huì)漏報(bào)一些運(yùn)行時(shí)漏洞。為了檢測(cè)掃描器是否有動(dòng)態(tài)掃描的能力，我在測(cè)試 APP 中包含 4 處拒絕服務(wù)漏洞的代碼，分別是空 Intent 拒絕服務(wù) 2 個(gè)、 1 個(gè)強(qiáng)制類型轉(zhuǎn)換拒絕服務(wù)和 1 個(gè)對(duì)象序列化拒絕服務(wù)。掃描結(jié)果如下表所示。

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

而 360 、百度和 AppRisk 沒有掃描出拒絕服務(wù)漏洞。從這個(gè)例子我我們推斷除阿里聚安全和金剛外，其他掃描平臺(tái)沒有動(dòng)態(tài)檢測(cè)能力。

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

百度可以檢測(cè)隱藏的 dex 文件，但它不能追蹤變量，無法處理函數(shù)間調(diào)用引起的漏洞，對(duì)數(shù)組下標(biāo)也不能準(zhǔn)確地處理，因此我們推測(cè)百度的掃描規(guī)則是基于危險(xiǎn) API 所在的函數(shù)范圍內(nèi)，一旦超出這個(gè)函數(shù)，百度的誤報(bào)率會(huì)大大提高。

360 掃描結(jié)果讓人看不明白，分析中所有的應(yīng)用一旦投入到 360 ，不但掃描時(shí)間長(zhǎng)，而且結(jié)果與其他四家差別很大，所以這里不對(duì) 360 的掃描能力做推測(cè)。

金剛和 AppRisk 的掃描能力相對(duì)較差，只能通過簡(jiǎn)單的特征函數(shù)匹配檢測(cè)漏洞，雖然漏報(bào)相對(duì)較少，但是誤報(bào)率比較高。

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

需要注意的是， 360 一直沒有測(cè)試 APP 的掃描結(jié)果，我只好把每個(gè)檢測(cè)代碼打包成 APP 進(jìn)行測(cè)試，然后進(jìn)行統(tǒng)計(jì)，因此關(guān)于 360 的測(cè)試結(jié)果可能有誤差。

除了掃描能力以外，最后一個(gè)維度會(huì)以之前的 4 個(gè)第三方 APP 的測(cè)試結(jié)果作為對(duì)比。為了說明各個(gè)掃描平臺(tái)實(shí)際掃描漏洞的能力，我將 WiFi 萬能鑰匙、墨跡天氣、手機(jī)百度以及新浪微博上傳到五家掃描平臺(tái)。最后將以 WiFi 萬能鑰匙的掃描結(jié)果為例，詳細(xì)分析一下各個(gè)平臺(tái)的掃描結(jié)果的漏報(bào)和誤報(bào)，從而評(píng)估其掃描結(jié)果的可信性。
這部分內(nèi)容將多帶帶作為下篇進(jìn)行連載，敬請(qǐng)期待。

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

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

［ 3 ］ 騰訊金剛審計(jì)系統(tǒng) http://service.security.tence...

［ 4 ］ 百度移動(dòng)云測(cè)試中心 http://mtc.baidu.com/startTes...

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

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