中通过对[1]、[2]、[3]、[4]以及[5] 在收费情况、样本测试后的扫描时间对比和漏洞项专业对比后,本篇将以各个厂商的扫描能力作为分析维度展开。
使用自己编写的测试APP测试各个扫描平台的扫描能力。这些扫描能力主要分为静态检测能力和动态检测能力。静态检测能力包括检测隐藏dex、过程间分析、较复杂漏洞检测、逆向分析;动态测试主要是指测试拒绝服务漏洞的能力,拒绝服务漏洞又可以划分为:空Intent引起的拒绝服务,强制类型转换引起的拒绝服务以及序列化对象导致的拒绝服务。由于这些检测能力决定了扫描器扫描结果的精度和准度,因此我详细分析了各个扫描平台的扫描能力。
目前很多APP通过加壳来防止自己被反编译,而扫描器都是通过在反编译的代码中进行漏洞的扫描。如果扫描器不能自动化地脱去APP加的壳,则根本无法进行有效的漏洞扫描分析。我写了一个包含五个扫描平台都有的全局文件读写漏洞的demo,通过梆梆加固之后,重签名上传到这五个扫描平台,检测结果是:阿里聚安全和百度检测出全局文件读写漏洞,而金刚、AppRisk没有检测出该漏洞。这个demo在360中没有扫描结果,所以360的脱壳能力不得而知。
目前插件化已经在Android开发中越来越普遍。很多APP会将一些独立模块打包成单独的dex文件,并存储到apk的其他目录中,如asset、lib等。如果扫描器没有检测隐藏dex文件的能力,则可能会漏报一些安全风险,造成扫描结果不准确。我编写了一个asset目录包含dex文件的应用程序,分别上传到上述五个扫描器,该dex文件中包含五家扫描器都可以检测的漏洞,结果只有阿里聚安全和百度成功扫描出隐藏dex文件中包含的漏洞。因此,可以推测阿里聚安全和百度具有扫描隐藏dex文件的能力,而360、金刚、百度和AppRisk都没有检测隐藏dex文件的能力。
五家扫描器都可以检测全局文件读写漏洞,因此我用该漏洞测试扫描器对过程间分析的能力。
openFileOutput的第二个参数可以指定文件打开的方式,如果以全局可写的方式打开会导致安全风险。这里我构造了两个测试例子。
例一, 直接对openFileOutput的第二参数设置全局可写,因此有漏洞。
例二, 通过函数的参数传递对openFileOutput的第二参数设置全局可写,也应该有漏洞。
测试代码如下:
样本一:函数内设置危险变量Context.MODE_WORLD_WRITEABLE
样本二:函数间设置危险变量Context.MODE_WORLD_WRITEABLE
样本一和样本二可以测试扫描器对过程间分析的检测能力。检测结果如表3-6所示(“√”表示扫描结果正确,“×”表示扫描结果错误。):
表3-6 函数间相互调用检测能力
阿里聚安全 | 360 | 金刚 | 百度 | AppRisk | |
---|---|---|---|---|---|
过程内检测(样本一) | √ | √ | √ | √ | √ |
过程间检测(样本二) | √ | × | × | × | × |
来源: http://www.cnblogs.com/redbricks/p/5783615.html