APP漏洞自动化扫描专业评测报告（下篇）

阅读量：5919 次

发布时间：2019-06-19

本文共 4784 字，大约阅读时间需要 15 分钟。

、回顾：通过收费情况、样本测试后的扫描时间、漏洞项对比以及扫描能力这几个方面对[1]、[2]、[3]、[4]以及[5]进行了对比分析。作为本系列的最后一篇，我将会以4个随机选取的APP的测试结果来进行对比。

四、扫描结果对比

选取的APP：说明一下这次选择的四个app是根据下载和安装量来选择，分别在网络工具类、天气、社交资讯类和搜索工具类选择了下载量和安装量最大的。出于对应用的隐私保护这里把最后选定的应用名隐去暂时叫做A应用。

评测方法：将以上4个APP分别上传到五家扫描平台，都分别得到5家平台的扫描速度和结果。除了在上篇中对比扫描时间外，这里还要对5家的扫描结果进行对比。但是实际操作下来4个APP的对比工作量实在太大，所以我最后从工作量小易于分析的原则出发，选择了A应用来最为结果对比。

下面我将以A应用的扫描结果为例，详细分析一下各个平台的扫描结果的漏报和误报，从而评估其扫描结果的可信度。

A应用的扫描结果如表4-1所示。

表4-1扫描结果总览

	阿里	360	金刚	百度	AppRisk
WebView绕过证书校验漏洞	2		2	1
WebView组件远程代码执行漏洞	2		2	3	2
中间人攻击（Allow All host name）	1			1
备份功能开启风险	1	1	1	1	1
主机名弱校验	1	1	1	1
证书弱校验	4		2	4	1
拒绝服务	3		1
Intent协议解析越权漏洞	1
AES/DES弱加密	1			15
初始化IVParameterSpec函数出错	9
PendigIntent误用风险	2			5	2
WebView明文存储密码风险	6			25	30
WebView组件系统隐藏接口漏洞	5		12	1	32
日志泄露风险	5	1		241	286
强制类型转换本地拒绝服务漏洞			6
App存在隐式意图调用		2	3
组件导出风险		22	24	23	17
Intent泄露用户敏感信息		1		1
广播信息泄露风险		2
Dex文件动态加载	0			1	9
加密哈希函数漏洞MD5					12
加密哈希函数漏洞SHA-1					1
Native动态调试	1
密钥硬编码	10
安全加固风险	1
WebView File域同源策略绕过	2

A应用只有一个dex文件，这排除了隐藏dex对结果的影响，接下来的章节中对扫描结果进行详细的对比分析。

4.1 WebView绕过证书校验漏洞

表4-3 WebView绕过证书校验漏洞分析结果

	误报	漏报
360	0	2
金刚	0	未知
阿里	0	未知
百度	0	1
AppRisk	0	2

WebView 绕过证书校验漏洞是指 onReceivedSslError 函数中调用 proceed 方法，会导 WebView 忽略校验证书的步骤。对于 WebView 绕过证书校验漏洞，经过比对，阿里和金刚定位的漏洞位置一致。因此我认为360和AppRisk漏报了2个，百度漏报了1个。我推测百度对于此类漏洞的检测规则是判断是否有onReceivedSslError 这个函数。

SslErrorHandler 这个类会代表一个请求去处理ssl error。 SslErrorHandler 会被 WebView 创立然后传给 onReceivedSslError 函数进行处理。其实真正做证书处理的函数是 SslErrorHandler 类的 proceed 函数。这个函数一般会是在 SslErrorHandler 函数里面进行调用，但是它还是可能在其他函数中被调用。因此检查proceed这个函数会更加全面。阿里与金刚应该是检查 Landroid/webkit/SslErrorHandler;->proceed()V。百度漏报的一个正好符合我的推论。

4.2 证书弱校验

表4-4 证书弱校验分析结果

	误报	漏报
360	0	4
金刚	0	2
阿里	0	未知
百度	0	未知
AppRisk	0	3

证书弱校验漏洞是在实现的 X509TrustManager 子类中 checkServerTrusted 函数没有校验服务器端证书的合法性导致的。360漏报4个，金刚漏报2个，AppRisk漏报3个。经过我的分析，一共有6处调用了checkServerTrusted，其中2处对证书进行了验证；而4处没有验证，直接返回，有两种形式，如下图所示：

我推测，漏报的原因是多了两行param导致扫描器认为对证书有校验。

4.3 WebView明文存储密码风险

表4-5 WebView明文存储密码风险分析结果

	误报	漏报
360	无检测	无检测
金刚	无检测	无检测
阿里	0	4
百度	15	未知
AppRisk	23	3

经过分析，我猜测AppRisk是通过 loadUrl 函数判断是否使用了 WebView，然后在使用 loadUrl 的类中搜索该 WebView 是否调用 setSavePassword(false) 方法。而我在反编译的代码中进行全局搜索，一共有34处调用 loadUrl；其中4处所处的类中显式调用了 setSavePassword(false) 方法，符合我的猜测，由于其他3处没有调用 loadUrl ，所以AppRisk漏报了3处。

百度的检测逻辑就比较难猜测，它不仅通过 loadUrl，还通过其他方法判断是否使用了 WebView，所以它可能没有漏报，但是误报率比较高。阿里没有检测出那些通过 findViewById 方法获得的 WebView 引起的明文密码存储风险，漏报了4处。

4.4 日志泄露风险

表4-6 日志泄露风险分析结果

	误报	漏报
360	未知	未知
金刚	无检测	无检测
阿里	未知	未知
百度	未知	未知
AppRisk	未知	未知

各个扫描平台对日志泄露风险的处理方式完全不同，在此一起讨论。

从扫描结果来看，阿里好像只检测 System.out.print 函数打印的内容。并没有过滤Log函数。实际上，Log函数也会泄露敏感的日志信息。

360认为只要存在Log日志，不管是 System.out.print 还是Log函数，都认为存在日志泄露风险。但无论日志泄露有多少，都只会给出一个存在Log日志泄露的风险，而且没有具体的漏洞位置。

百度和AppRisk对待日志泄露的态度相似，检测Log函数。

所以从我这看，阿里、360以及百度和AppRisk的出发点是不同的。结果也没有很好的可比性。能可比的，就是对待这个日志泄露风险的一个规则。

4.5 PendingIntent误用风险

表4-7 PendingIntent误用风险分析结果

	误报	漏报
360	无检测	无检测
金刚	无检测	无检测
阿里	0	3
百度	0	未知
AppRisk	0	3

百度的 PendingIntent 误用风险，不仅包括 Intent 为空的情况，还包含了隐式Intent的情况。A应用中，有2个是空Intent，有3个是隐式Intent。而阿里和AppRisk的 PendingIntent 误用风险监测可能只包括Intent为空的情况，所以只检测出2处漏洞，漏报了3个隐式的Intent。如果从两者的检测内容上看，阿里、百度和AppRisk都没有误报的情况。

4.6 WebView远程代码执行漏洞

五个扫描都具有扫描WebView远程代码执行漏洞，但是给出的结果却不一样。扫描结果如下表所示：

表 4-8 WebView远程代码执行漏洞分析结果

	误报	漏报
360	0	3
金刚	0	1
阿里	0	1
百度	0	未知
AppRisk	0	1

在WebView远程代码执行漏洞检测中，经过人工分析，确认阿里、金刚以及AppRisk各漏报1个，360漏报3个。阿里没有识别 findViewById 方法实例化的 WebView，因而漏报了1个。

4.7 Dex文件动态加载

只有阿里、百度和AppRisk这三个扫描器包含该扫描项。

阿里的检测规则（猜测）：

1) 检测特征函数 DexClassLoader 以及 PathClassLoader 的构造函数。

2) 检测该特征函数的传入参数（加载路径）是否包含“sdcard”字符串

百度的检测规则（猜测）：

1) 检测特征函数 DexClassLoader 以及 PathClassLoader 的构造函数

AppRisk的检测规则（猜测）：

2) 检测 DexClassLoader 中 loadClass 调用

我在反编译的代码中进行全局搜索 “DexClassLoader;->loadClass”，一共有9处，故猜测AppRisk的检测规则为检测 loadClass 函数的调用。

由于检测点不一样无法判断具体的漏报和误报。

4.8 AES/DES弱加密

表4-9 AES/DES弱加密分析结果

	误报	漏报
360	0	1
金刚	无检测	无检测
阿里	0	未知
百度	14	未知
AppRisk	0	1

该项金刚不会检测，而360和AppRisk都没有检测出 AES/DES 弱加密风险，都漏报了1个。而百度却检测出15个弱加密风险。经过分析，我猜测百度只是检测是否包含AES或者DES，并没有判断加密模式是否为ECB，使用其他加密模式是不存在安全隐患的。而阿里正确检测出1个，因此我的结论是百度误报14个漏洞，360和AppRisk漏报1个。

4.9 WebView组件系统隐藏接口漏洞

表4-10 WebView组件系统隐藏接口漏洞分析结果

	误报	漏报
360	0	未知
金刚	9	2
阿里	0	未知
百度	0	4
AppRisk	27	3

360没有扫描出WebView隐藏接口漏洞，原因未知。

金刚误报了9个，而且还有2个漏洞漏报；百度漏报了4个漏洞，只正确找出1个。通过之前的扫描能力分析我可知，金刚可能仅仅是寻找是否有使用了 WebView，而没对WebView是否启用了 JavaScript 进行检查，所以误报率很高。百度没有误报，但漏报很多，可能是百度没有判断 WebView 是否启用了 JavaScript，所以本着减少误报的原则，只报告百分之百确定的漏洞。

AppRisk的检测规则可能非常简单粗暴，仅仅检查 loadUrl 来确定是否使用了 WebView，因而误报率很高。

阿里可能首先判断 WebView 是否允许 JavaScript 运行。只有在 JavaScript 允许运行时移除隐藏接口才有意义；然后如果 JavaScript 开启，那么就判断 WebView 是否移除了 “searchBoxJavaBridge_”、“accessibilityTraversal”以及“accessibility” 这3个接口。如果都移除了才安全。所以阿里漏报和误报都很低。