摘要：上篇中篇回顧通過(guò)收費(fèi)情況樣本測(cè)試后的掃描時(shí)間漏洞項(xiàng)對(duì)比以及掃描能力這幾個(gè)方面對(duì)阿里聚安全漏洞掃描騰訊金剛審計(jì)系統(tǒng)百度移動(dòng)云測(cè)試中心以及進(jìn)行了對(duì)比分析。我推測(cè)百度對(duì)于此類(lèi)漏洞的檢測(cè)規(guī)則是判斷是否有這個(gè)函數(shù)。

上篇、中篇回顧：通過(guò)收費(fèi)情況、樣本測(cè)試后的掃描時(shí)間、漏洞項(xiàng)對(duì)比以及掃描能力這幾個(gè)方面對(duì)阿里聚安全[1]、360App漏洞掃描[2]、騰訊金剛審計(jì)系統(tǒng)[3]、百度移動(dòng)云測(cè)試中心[4]以及AppRisk Scanner[5]進(jìn)行了對(duì)比分析。作為本系列的最后一篇，我將會(huì)以4個(gè)隨機(jī)選取的APP的測(cè)試結(jié)果來(lái)進(jìn)行對(duì)比。

選取的APP：說(shuō)明一下這次選擇的四個(gè)app是根據(jù)下載和安裝量來(lái)選擇，分別在網(wǎng)絡(luò)工具類(lèi)、天氣、社交資訊類(lèi)和搜索工具類(lèi)選擇了下載量和安裝量最大的。出于對(duì)應(yīng)用的隱私保護(hù)這里把最后選定的應(yīng)用名隱去暫時(shí)叫做A應(yīng)用。

評(píng)測(cè)方法：將以上4個(gè)APP分別上傳到五家掃描平臺(tái)，都分別得到5家平臺(tái)的掃描速度和結(jié)果。除了在上篇中對(duì)比掃描時(shí)間外，這里還要對(duì)5家的掃描結(jié)果進(jìn)行對(duì)比。但是實(shí)際操作下來(lái)4個(gè)APP的對(duì)比工作量實(shí)在太大，所以我最后從工作量小易于分析的原則出發(fā)，選擇了A應(yīng)用來(lái)最為結(jié)果對(duì)比。

下面我將以A應(yīng)用的掃描結(jié)果為例，詳細(xì)分析一下各個(gè)平臺(tái)的掃描結(jié)果的漏報(bào)和誤報(bào)，從而評(píng)估其掃描結(jié)果的可信度。

A應(yīng)用的掃描結(jié)果如表4-1所示。

表4-1掃描結(jié)果總覽

A應(yīng)用只有一個(gè)dex文件，這排除了隱藏dex對(duì)結(jié)果的影響，接下來(lái)的章節(jié)中對(duì)掃描結(jié)果進(jìn)行詳細(xì)的對(duì)比分析。

表4-3 WebView繞過(guò)證書(shū)校驗(yàn)漏洞分析結(jié)果

WebView 繞過(guò)證書(shū)校驗(yàn)漏洞是指 onReceivedSslError 函數(shù)中調(diào)用 proceed 方法，會(huì)導(dǎo) WebView 忽略校驗(yàn)證書(shū)的步驟。對(duì)于 WebView 繞過(guò)證書(shū)校驗(yàn)漏洞，經(jīng)過(guò)比對(duì)，阿里和金剛定位的漏洞位置一致。因此我認(rèn)為360和AppRisk漏報(bào)了2個(gè)，百度漏報(bào)了1個(gè)。我推測(cè)百度對(duì)于此類(lèi)漏洞的檢測(cè)規(guī)則是判斷是否有onReceivedSslError 這個(gè)函數(shù)。

SslErrorHandler 這個(gè)類(lèi)會(huì)代表一個(gè)請(qǐng)求去處理ssl error。 SslErrorHandler 會(huì)被 WebView 創(chuàng)立然后傳給 onReceivedSslError 函數(shù)進(jìn)行處理。其實(shí)真正做證書(shū)處理的函數(shù)是 SslErrorHandler 類(lèi)的 proceed 函數(shù)。這個(gè)函數(shù)一般會(huì)是在 SslErrorHandler 函數(shù)里面進(jìn)行調(diào)用，但是它還是可能在其他函數(shù)中被調(diào)用。因此檢查proceed這個(gè)函數(shù)會(huì)更加全面。阿里與金剛應(yīng)該是檢查 Landroid/webkit/SslErrorHandler;->proceed()V。百度漏報(bào)的一個(gè)正好符合我的推論。

表4-4 證書(shū)弱校驗(yàn)分析結(jié)果

證書(shū)弱校驗(yàn)漏洞是在實(shí)現(xiàn)的 X509TrustManager 子類(lèi)中 checkServerTrusted 函數(shù)沒(méi)有校驗(yàn)服務(wù)器端證書(shū)的合法性導(dǎo)致的。360漏報(bào)4個(gè)，金剛漏報(bào)2個(gè)，AppRisk漏報(bào)3個(gè)。經(jīng)過(guò)我的分析，一共有6處調(diào)用了checkServerTrusted，其中2處對(duì)證書(shū)進(jìn)行了驗(yàn)證；而4處沒(méi)有驗(yàn)證，直接返回，有兩種形式，如下圖所示：

我推測(cè)，漏報(bào)的原因是多了兩行param導(dǎo)致掃描器認(rèn)為對(duì)證書(shū)有校驗(yàn)。

表4-5 WebView明文存儲(chǔ)密碼風(fēng)險(xiǎn)分析結(jié)果

經(jīng)過(guò)分析，我猜測(cè)AppRisk是通過(guò) loadUrl 函數(shù)判斷是否使用了 WebView，然后在使用 loadUrl 的類(lèi)中搜索該 WebView 是否調(diào)用 setSavePassword(false) 方法。而我在反編譯的代碼中進(jìn)行全局搜索，一共有34處調(diào)用 loadUrl；其中4處所處的類(lèi)中顯式調(diào)用了 setSavePassword(false) 方法，符合我的猜測(cè)，由于其他3處沒(méi)有調(diào)用 loadUrl ，所以AppRisk漏報(bào)了3處。

百度的檢測(cè)邏輯就比較難猜測(cè)，它不僅通過(guò) loadUrl，還通過(guò)其他方法判斷是否使用了 WebView，所以它可能沒(méi)有漏報(bào)，但是誤報(bào)率比較高。阿里沒(méi)有檢測(cè)出那些通過(guò) findViewById 方法獲得的 WebView 引起的明文密碼存儲(chǔ)風(fēng)險(xiǎn)，漏報(bào)了4處。

表4-6 日志泄露風(fēng)險(xiǎn)分析結(jié)果

各個(gè)掃描平臺(tái)對(duì)日志泄露風(fēng)險(xiǎn)的處理方式完全不同，在此一起討論。

從掃描結(jié)果來(lái)看，阿里好像只檢測(cè) System.out.print 函數(shù)打印的內(nèi)容。并沒(méi)有過(guò)濾Log函數(shù)。實(shí)際上，Log函數(shù)也會(huì)泄露敏感的日志信息。

360認(rèn)為只要存在Log日志，不管是 System.out.print 還是Log函數(shù)，都認(rèn)為存在日志泄露風(fēng)險(xiǎn)。但無(wú)論日志泄露有多少，都只會(huì)給出一個(gè)存在Log日志泄露的風(fēng)險(xiǎn)，而且沒(méi)有具體的漏洞位置。

百度和AppRisk對(duì)待日志泄露的態(tài)度相似，檢測(cè)Log函數(shù)。

所以從我這看，阿里、360以及百度和AppRisk的出發(fā)點(diǎn)是不同的。結(jié)果也沒(méi)有很好的可比性。能可比的，就是對(duì)待這個(gè)日志泄露風(fēng)險(xiǎn)的一個(gè)規(guī)則。

表4-7 PendingIntent誤用風(fēng)險(xiǎn)分析結(jié)果

百度的 PendingIntent 誤用風(fēng)險(xiǎn)，不僅包括 Intent 為空的情況，還包含了隱式Intent的情況。A應(yīng)用中，有2個(gè)是空Intent，有3個(gè)是隱式Intent。而阿里和AppRisk的 PendingIntent 誤用風(fēng)險(xiǎn)監(jiān)測(cè)可能只包括Intent為空的情況，所以只檢測(cè)出2處漏洞，漏報(bào)了3個(gè)隱式的Intent。如果從兩者的檢測(cè)內(nèi)容上看，阿里、百度和AppRisk都沒(méi)有誤報(bào)的情況。

五個(gè)掃描都具有掃描WebView遠(yuǎn)程代碼執(zhí)行漏洞，但是給出的結(jié)果卻不一樣。掃描結(jié)果如下表所示：

表 4-8 WebView遠(yuǎn)程代碼執(zhí)行漏洞分析結(jié)果

在WebView遠(yuǎn)程代碼執(zhí)行漏洞檢測(cè)中，經(jīng)過(guò)人工分析，確認(rèn)阿里、金剛以及AppRisk各漏報(bào)1個(gè)，360漏報(bào)3個(gè)。阿里沒(méi)有識(shí)別 findViewById 方法實(shí)例化的 WebView，因而漏報(bào)了1個(gè)。

只有阿里、百度和AppRisk這三個(gè)掃描器包含該掃描項(xiàng)。

阿里的檢測(cè)規(guī)則（猜測(cè)）：

1) 檢測(cè)特征函數(shù) DexClassLoader 以及 PathClassLoader 的構(gòu)造函數(shù)。

2) 檢測(cè)該特征函數(shù)的傳入?yún)?shù)（加載路徑）是否包含“sdcard”字符串

百度的檢測(cè)規(guī)則（猜測(cè)）：

1) 檢測(cè)特征函數(shù) DexClassLoader 以及 PathClassLoader 的構(gòu)造函數(shù)

AppRisk的檢測(cè)規(guī)則（猜測(cè)）：

2) 檢測(cè) DexClassLoader 中 loadClass 調(diào)用

我在反編譯的代碼中進(jìn)行全局搜索 “DexClassLoader;->loadClass”，一共有9處，故猜測(cè)AppRisk的檢測(cè)規(guī)則為檢測(cè) loadClass 函數(shù)的調(diào)用。

由于檢測(cè)點(diǎn)不一樣無(wú)法判斷具體的漏報(bào)和誤報(bào)。

表4-9 AES/DES弱加密分析結(jié)果

該項(xiàng)金剛不會(huì)檢測(cè)，而360和AppRisk都沒(méi)有檢測(cè)出 AES/DES 弱加密風(fēng)險(xiǎn)，都漏報(bào)了1個(gè)。而百度卻檢測(cè)出15個(gè)弱加密風(fēng)險(xiǎn)。經(jīng)過(guò)分析，我猜測(cè)百度只是檢測(cè)是否包含AES或者DES，并沒(méi)有判斷加密模式是否為ECB，使用其他加密模式是不存在安全隱患的。而阿里正確檢測(cè)出1個(gè)，因此我的結(jié)論是百度誤報(bào)14個(gè)漏洞，360和AppRisk漏報(bào)1個(gè)。

表4-10 WebView組件系統(tǒng)隱藏接口漏洞分析結(jié)果

360沒(méi)有掃描出WebView隱藏接口漏洞，原因未知。

金剛誤報(bào)了9個(gè)，而且還有2個(gè)漏洞漏報(bào)；百度漏報(bào)了4個(gè)漏洞，只正確找出1個(gè)。通過(guò)之前的掃描能力分析我可知，金剛可能僅僅是尋找是否有使用了 WebView，而沒(méi)對(duì)WebView是否啟用了 JavaScript 進(jìn)行檢查，所以誤報(bào)率很高。百度沒(méi)有誤報(bào)，但漏報(bào)很多，可能是百度沒(méi)有判斷 WebView 是否啟用了 JavaScript，所以本著減少誤報(bào)的原則，只報(bào)告百分之百確定的漏洞。

AppRisk的檢測(cè)規(guī)則可能非常簡(jiǎn)單粗暴，僅僅檢查 loadUrl 來(lái)確定是否使用了 WebView，因而誤報(bào)率很高。

阿里可能首先判斷 WebView 是否允許 JavaScript 運(yùn)行。只有在 JavaScript 允許運(yùn)行時(shí)移除隱藏接口才有意義；然后如果 JavaScript 開(kāi)啟，那么就判斷 WebView 是否移除了 “searchBoxJavaBridge_”、“accessibilityTraversal”以及“accessibility” 這3個(gè)接口。如果都移除了才安全。所以阿里漏報(bào)和誤報(bào)都很低。

通過(guò)此次評(píng)測(cè)，我基本了解了目前國(guó)內(nèi)移動(dòng)安全掃描平臺(tái)的發(fā)展?fàn)顩r，了解了主流掃描平臺(tái)的檢測(cè)能力，包括掃描項(xiàng)、漏洞的檢測(cè)規(guī)則等。我發(fā)現(xiàn)沒(méi)有一家掃描平臺(tái)可以覆蓋所有的安全漏洞和風(fēng)險(xiǎn)。

相對(duì)來(lái)說(shuō)， AppRisk掃描速度最快，掃描結(jié)果展示更加專(zhuān)業(yè)；360和金剛作為老牌的掃描器，盡管掃描速度慢了一點(diǎn)，但掃描能力和結(jié)果展示也比較不錯(cuò)；阿里聚安全的掃描項(xiàng)覆蓋廣一些，漏報(bào)和誤報(bào)率較低，檢測(cè)結(jié)果更加可信一點(diǎn)。百度作為其中唯一一家收費(fèi)的掃描平臺(tái)，在某些掃描項(xiàng)的掃描能力上處于領(lǐng)先位置，掃描速度也比較快?？傊?，五家掃描平臺(tái)在競(jìng)爭(zhēng)中互相學(xué)習(xí)，取長(zhǎng)補(bǔ)短。

Reference：

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

［2］360APP漏洞掃描 http://dev.360.cn/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...