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

前言

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

測試方法

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

3.2.1 自動化脫殼

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

3.2.2 隱藏Dex檢測能力

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

3.2.3 過程間分析能力

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

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

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

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

測試代碼如下：

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

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

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

表3-6 函數(shù)間相互調(diào)用檢測能力

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

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

3.2.4 逆向分析能力

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

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

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

表3-7 數(shù)組下標敏感性檢測結(jié)果

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

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

3.2.5檢測較復雜漏洞的能力

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

我構(gòu)造了三個例子進行測試：

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

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

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

構(gòu)造如下測試代碼：

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

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

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

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

當檢測百度時，我使用WebView組件系統(tǒng)隱藏接口漏洞作為測試用例。

測試代碼如下：

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

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

3.2.6 動態(tài)檢測能力

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

表3-8 動態(tài)檢測能力掃描結(jié)果

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

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

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

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

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

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

掃描能力小結(jié)

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

表3-9 掃描能力總覽

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

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

Reference：

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

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

［3］騰訊金剛審計系統(tǒng)：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