V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
redbricks
V2EX  ›  Android

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

  •  
  •   redbricks · 2016-09-19 14:02:47 +08:00 · 8535 次点击
    这是一个创建于 2989 天前的主题,其中的信息可能已经有所发展或是发生改变。

    上篇中篇回顾:通过收费情况、样本测试后的扫描时间、漏洞项对比以及扫描能力这几个方面对阿里聚安全[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 扫描结果总览

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

    4.1 WebView 绕过证书校验漏洞

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

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

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

    4.2 证书弱校验

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

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

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

    4.3 WebView 明文存储密码风险

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

    经过分析,我猜测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 日志泄露风险分析结果

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

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

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

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

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

    4.5 PendingIntent 误用风险

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

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

    4.6 WebView 远程代码执行漏洞

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

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

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

    4.7 Dex 文件动态加载

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

    阿里的检测规则(猜测):

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

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

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

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

    AppRisk 的检测规则(猜测):

    1. 检测 DexClassLoader 中 loadClass 调用

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

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

    4.8 AES/DES 弱加密

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

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

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

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

    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

    4 条回复    2016-09-23 19:24:00 +08:00
    GordianZ
        1
    GordianZ  
    MOD
       2016-09-19 15:31:56 +08:00
    下次不要发到问与答版面。
    cctvsmg
        2
    cctvsmg  
       2016-09-19 15:33:09 +08:00
    楼主可以发到 testerhome
    这个是优质文章,自动化 app 测试大有可为
    redbricks
        3
    redbricks  
    OP
       2016-09-23 17:16:50 +08:00
    @GordianZ 这不是安卓技术版面吗
    GordianZ
        4
    GordianZ  
    MOD
       2016-09-23 19:24:00 +08:00
    @redbricks 你的文章都是我转移的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3520 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 11:19 · PVG 19:19 · LAX 03:19 · JFK 06:19
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.