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

前言

上一篇中通过对阿里聚安全[1]、360App漏洞扫描[2]、腾讯金刚审计系统[3]、百度移动云测试中心[4]以及AppRisk Scanner[5] 在收费情况、样本测试后的扫描时间对比和漏洞项专业对比后，本篇将以各个厂商的扫描能力作为分析维度展开。

测试方法

使用自己编写的测试APP测试各个扫描平台的扫描能力。这些扫描能力主要分为静态检测能力和动态检测能力。静态检测能力包括检测隐藏dex、过程间分析、较复杂漏洞检测、逆向分析；动态测试主要是指测试拒绝服务漏洞的能力，拒绝服务漏洞又可以划分为：空Intent引起的拒绝服务，强制类型转换引起的拒绝服务以及序列化对象导致的拒绝服务。由于这些检测能力决定了扫描器扫描结果的精度和准度，因此我详细分析了各个扫描平台的扫描能力。

3.2.1 自动化脱壳

目前很多APP通过加壳来防止自己被反编译，而扫描器都是通过在反编译的代码中进行漏洞的扫描。如果扫描器不能自动化地脱去APP加的壳，则根本无法进行有效的漏洞扫描分析。我写了一个包含五个扫描平台都有的全局文件读写漏洞的demo，通过梆梆加固之后，重签名上传到这五个扫描平台，检测结果是：阿里聚安全和百度检测出全局文件读写漏洞，而金刚、AppRisk没有检测出该漏洞。这个demo在360中没有扫描结果，所以360的脱壳能力不得而知。

3.2.2 隐藏Dex检测能力

目前插件化已经在Android开发中越来越普遍。很多APP会将一些独立模块打包成单独的dex文件，并存储到apk的其他目录中，如asset、lib等。如果扫描器没有检测隐藏dex文件的能力，则可能会漏报一些安全风险，造成扫描结果不准确。我编写了一个asset目录包含dex文件的应用程序，分别上传到上述五个扫描器，该dex文件中包含五家扫描器都可以检测的漏洞，结果只有阿里聚安全和百度成功扫描出隐藏dex文件中包含的漏洞。因此，可以推测阿里聚安全和百度具有扫描隐藏dex文件的能力，而360、金刚、百度和AppRisk都没有检测隐藏dex文件的能力。

3.2.3 过程间分析能力

五家扫描器都可以检测全局文件读写漏洞，因此我用该漏洞测试扫描器对过程间分析的能力。

openFileOutput的第二个参数可以指定文件打开的方式，如果以全局可写的方式打开会导致安全风险。这里我构造了两个测试例子。

例一， 直接对openFileOutput的第二参数设置全局可写，因此有漏洞。

例二， 通过函数的参数传递对openFileOutput的第二参数设置全局可写，也应该有漏洞。

测试代码如下：

样本一：函数内设置危险变量Context.MODE_WORLD_WRITEABLE

样本二：函数间设置危险变量Context.MODE_WORLD_WRITEABLE

样本一和样本二可以测试扫描器对过程间分析的检测能力。检测结果如表3-6所示（“√”表示扫描结果正确，“×”表示扫描结果错误。）：

表3-6 函数间相互调用检测能力

	阿里聚安全	360	金刚	百度	AppRisk
过程内检测（样本一）	√	√	√	√	√
过程间检测（样本二）