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

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

四、掃描結(jié)果對比

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

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

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

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

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

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

4.1  WebView繞過證書校驗漏洞

表4-3  WebView繞過證書校驗漏洞分析結(jié)果

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

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

4.2  證書弱校驗

表4-4  證書弱校驗分析結(jié)果

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

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

4.3  WebView明文存儲密碼風(fēng)險

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

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

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

4.4  日志泄露風(fēng)險

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

各個掃描平臺對日志泄露風(fēng)險的處理方式完全不同，在此一起討論。

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

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

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

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

4.5  PendingIntent誤用風(fēng)險

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

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

4.6  WebView遠(yuǎn)程代碼執(zhí)行漏洞

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

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

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

4.7  Dex文件動態(tài)加載

只有阿里、百度和AppRisk這三個掃描器包含該掃描項。

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

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

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

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

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

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

• 檢測DexClassLoader中l(wèi)oadClass調(diào)用

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

由于檢測點不一樣無法判斷具體的漏報和誤報。

4.8  AES/DES弱加密

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

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

4.9  WebView組件系統(tǒng)隱藏接口漏洞

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

360沒有掃描出WebView隱藏接口漏洞，原因未知。

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

AppRisk的檢測規(guī)則可能非常簡單粗暴，僅僅檢查loadUrl來確定是否使用了WebView，因而誤報率很高。

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

五、總結(jié)和展望

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

相對來說， AppRisk掃描速度最快，掃描結(jié)果展示更加專業(yè)；360和金剛作為老牌的掃描器，盡管掃描速度慢了一點，但掃描能力和結(jié)果展示也比較不錯；阿里聚安全的掃描項覆蓋廣一些，漏報和誤報率較低，檢測結(jié)果更加可信一點。百度作為其中唯一一家收費的掃描平臺，在某些掃描項的掃描能力上處于領(lǐng)先位置，掃描速度也比較快。總之，五家掃描平臺在競爭中互相學(xué)習(xí)，取長補(bǔ)短。

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

Sunnieli