码迷,mamicode.com
首页 > 移动开发 > 详细

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

时间:2016-09-19 16:17:35      阅读:321      评论:0      收藏:0      [点我收藏+]

标签:漏洞   评测   漏洞扫描   移动安全   安全平台   

上篇中篇回顾:通过收费情况、样本测试后的扫描时间、漏洞项对比以及扫描能力这几个方面对阿里聚安全[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这个类会代表一个请求去处理sslerror。

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”字符串

百度的检测规则(猜测):

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

AppRisk的检测规则(猜测):

  • 检测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


Sunnieli

本文出自 “11195759” 博客,转载请与作者联系!

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

标签:漏洞   评测   漏洞扫描   移动安全   安全平台   

原文地址:http://11205759.blog.51cto.com/11195759/1854044

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!