APP漏洞自动化扫描专业评测报告（下篇）
上篇、中篇回顾：通过收费情况、样本测试后的扫描时间、漏洞项对比以及扫描能力这几个方面对阿里聚安全[1]、360App漏洞扫描[2]、腾讯金刚审计系统[3]、百度移动云测试中心[4]以及AppRisk Scanner[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个接口。如果都移除了才安全。所以阿里漏报和误报都很低。
五、总结和展望
通过此次评测，我基本了解了目前国内移动安全扫描平台的发展状况，了解了主流扫描平台的检测能力，包括扫描项、漏洞的检测规则等。我发现没有一家扫描平台可以覆盖所有的安全漏洞和风险。相对来说， AppRisk扫描速度最快，扫描结果展示更加专业；360和金刚作为老牌的扫描器，尽管扫描速度慢了一点，但扫描能力和结果展示也比较不错；阿里聚安全的扫描项覆盖广一些，漏报和误报率较低，检测结果更加可信一点。百度作为其中唯一一家收费的扫描平台，在某些扫描项的扫描能力上处于领先位置，扫描速度也比较快。总之，五家扫描平台在竞争中互相学习，取长补短。
Reference：
［1］ 阿里聚安全 http://jaq.alibaba.com/
［2］ 360APP漏洞扫描 http://dev.360.cn/mod/vulscan/
［3］ 腾讯金刚审计系统 http://service.security.tencent.com/kingkong
［4］ 百度移动云测试中心 http://mtc.baidu.com/startTest/safe
［5］ AppRisk Scanner https://apprisk.newskysecurity.com
APP漏洞自动化扫描专业评测报告（下篇）的更多相关文章
- APP漏洞自动化扫描专业评测报告
一.前言 目前在业界有很多自动化检测APP安全性的在线扫描平台.为了了解目前国内移动APP在线漏洞扫描平台的发展情况,我进行了一次移动安全扫描平台的评测分析:主要从漏洞项对比.扫描能力对比以及扫描结果 ...
- APP漏洞自动化扫描专业评测报告（中篇）
前言 上一篇中通过对阿里聚安全[1].360App漏洞扫描[2].腾讯金刚审计系统[3].百度移动云测试中心[4]以及AppRisk Scanner[5] 在收费情况.样本测试后的扫描时间对比和漏洞项 ...
- APP漏洞自动化扫描专业评测报告（上篇）
一.前言 随着Android操作系统的快速发展,运行于Android之上的APP如雨后春笋般涌现.由于一些APP的开发者只注重APP业务功能的实现,对APP可能出现安全问题不够重视,使得APP存在较多 ...
- 移动APP漏洞自动化检测平台建设
移动APP漏洞自动化检测平台建设 前言:本文是<移动APP客户端安全笔记>系列原创文章中的第一篇,主要讲的是企业移动APP自动化漏洞检测平台建设,移动APP漏洞检测发展史与前沿技术,A ...
- 安全基线自动化扫描、生成报告、加固的实现（以Tomcat为例）
一.背景说明 当前在服务上线前,安全部门都会对服务基线配置进行把关,整个流程可以分为扫描.生成报告.修复三步. 在执行这一流程时当前普遍的做法是半自动化的,扫描和生成报告是自动化的,执行扫描.执行生成 ...
- 国内APP漏洞扫描收费情况调查
概述 上一次分享了应用加固的评测后,很多人想看看漏洞扫描相关的对比数据.其实在选择市面上这些移动安全类的产品时,经常为各种复杂的数据而感到疑惑,不知道怎么来评判各自的性能以及价格,从而选择出一款性价比 ...
- APP漏洞扫描器之本地拒绝服务检测详解
APP漏洞扫描器之本地拒绝服务检测详解 阿里聚安全的Android应用漏洞扫描器有一个检测项是本地拒绝服务漏洞的检测,采用的是静态分析加动态模糊测试的方法来检测,检测结果准确全面.本文将讲一下应用漏洞 ...
- APP漏洞扫描用地址空间随机化
APP漏洞扫描用地址空间随机化 前言 我们在前文<APP漏洞扫描器之本地拒绝服务检测详解>了解到阿里聚安全漏洞扫描器有一项静态分析加动态模糊测试的方法来检测的功能,并详细的介绍了它在针对本 ...
- APP漏洞扫描用地址空间随机化【转】
转自:http://www.cnblogs.com/alisecurity/p/6141575.html 前言 我们在前文<APP漏洞扫描器之本地拒绝服务检测详解>了解到阿里聚安全漏洞扫描 ...
随机推荐
- 洛谷P1040 加分二叉树(区间dp)
P1040 加分二叉树 题目描述 设一个n个节点的二叉树tree的中序遍历为(1,2,3,…,n),其中数字1,2,3,…,n为节点编号.每个节点都有一个分数(均为正整数),记第i个节点的分数为di, ...
- JS中对象按属性排序（冒泡排序）
在实际工作经常会出现这样一个问题:后台返回一个数组中有i个json数据,需要我们根据json中某一项进行数组的排序. 例如返回的数据结构大概是这样: { result:[ {id:,name:'中国银 ...
- C99C新增内容
继上一篇复合文字之后,今天我们继续谈一谈C99C的新特性. C99标准是继C89标准之后的第二个C语言官方标准,于1999年12月1日正式发布,其中对数据类型(增加了对_Bool),关键字(增加了in ...
- 记录一个MySQL的问题
昨天做asp.net mvc程序,用mysql.data.entity.ef6做数据连接. 程序都是正常的,但就是提交数据的时候总是提示 Specified key was too long; max ...
- EmguCV学习——视频与图片互转
其实视频转图片在上篇文章中已经有些眉目了,其实就是按帧读取视频,然后把帧保存就ok.然后自己再加个进度条美化一下...这代码简单易懂,还是直接上代码吧. 视频转图片 /// <summary&g ...
- HTTPS 为什么更安全，先看这些
HTTPS 是建立在密码学基础之上的一种安全通信协议,严格来说是基于 HTTP 协议和 SSL/TLS 的组合.理解 HTTPS 之前有必要弄清楚一些密码学的相关基础概念,比如:明文.密文.密码.密钥 ...
- html5与css3入门知识点精炼
<meta name = "keywords" content="…………"/>(网页搜索时要输入的关键字) <meta name = &qu ...
- 闰年or平年判断
<script type="text/javascript">var year = prompt("请输入一个年份");if(year!=null) ...
- session 存入redis 或 memcache 的方法
Session简介 session,中文经常翻译为会话,其本来的含义是 指有始有终的一系列动作/消息,比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session.有时候我们 ...
- SLAM: SLAM的发展历程（WIKI）
参考维基百科: https://en.wikipedia.org/wiki/Simultaneous_localization_and_mapping 你们叫他SLAM,我还是习惯叫他三维重建.... ...