2016-10-21

appscan

 

0x1.引子

 

前段时间盘古的同学发现了QQ手机浏览器的“虫洞漏洞”,我们同步分析了下该漏洞,目前该漏洞已经修复,我们和大家分享一下这个漏洞的分析和挖掘全过程,供大家参考。

 

0x2.样本信息

 

下载链接:http://mb.qq.com/

文件名称:qqbrowser_6.9.2.2665_20820.apk

文件md5:64FE443F770BA9433E23D689C78DAF99

versionCode: ‘6922665’

versionName: 6.9.2.2665

云盘备份地址:https://yunpan.cn/cM8JVT39xQnhw  访问密码 d7d6

 

0x3.特征定位

 

查看手机所开端口发现一处可疑端口本地未校验。

 

所以需要对本地所有dex文件进行扫描,看看此部分功能到底是在哪里,在做什么。

通过搜索端口号以及判定是打开Sokcet,我们确定此处地址。

 

 

即确定文件所在包为:

assets/dex/com.tencent.mtt.sniffer.jar

 

0x4.代码深入

 

现在我们就可以继续往下进行分析了。

我们用jeb查看一下java代码。

 

 

 

既然g.b是获取的端口8786数字,那么g类很可能就是初始化socket的类,所以我们按照代码逻辑往下看一下这个g类,发现这里this.i的数值是new j(this.a),而这个j类则包含很多数据。

如下图所示:

 

第一个红框是方法名,处理申请的访问链接流程的。

第二个红框是请求的网址,根据不同的请求执行不同的功能。

第三个红框就是执行的功能,在代码下面有很多类似结构。

这里我们先看一下/getWifiInfo这个请求。

在j.a(this.a,arg13)方法我们往后跟一下。

 

 

这里有两处需要分析的地方,一处是数据处理,即请求访问协议的数据的加密与解密;一处是Message的发送,即不同的请求走不同的方法分支。我们先看第一处红框这个位置,是将数据进行处理,this.a(v2.toString)方法我们跟进去。

 

 

可以看到执行的是e.a和e.b方法,我们看到这个,一般是可以猜测到是加解密的方法。

 

 

这样,我们就明显的确定是通过的3des进行的加解密处理。

然后密钥的获取可以直接静态分析得到。

密钥的获取:

l.b = b.b + h.c;

 

b .b = “kM7hYp8lE69U” ;

h .c = e.b + d.f;

 

e.b = “jidhlPbD9”;

d .f = “8Pm” ;

 

密钥==”kM7hYp8lE69UjidhlPbD98Pm

在寻找密钥的过程中,我们发现访问请求的数据加密,和服务器返回的数据解密,都是通过3des加密解密,然后进行Base64编码解码处理的。

所以我们整理一下思路,先对刚才的getWifiInfo请求进行测试模拟。

 

 

流程也就是先在本地进行8786端口转发一下。

然后用python写一下网络请求即可,在上面截图中的url大家可以直接看到。

 

0x5.漏洞利用

 

上一条测试通过之后,我们继续往下看,有更多的协议需要分析。

 

 

我们这里可以看到,第一条getWifiInfo协议没有判断,直接会进行请求,而后面的请求,都是基于uuid来进行判定,如果uuid存在并且合法,那么才会进行后续请求,所以主要问题在于我们如何构造uuid并且使之合法化。

我们继续分析代码,也就是上图第二个红框标识的地方,如果uuid不是空,同时本地的一个hashmap中没有记录过它,那么将会往下走if的流程,所以看到这个/bind协议,我们就可以猜测,这条协议是否是绑定uuid的呢?

跟进去看一下this.a.a(arg12);

 

 

我们看到这个红框,可以发现上文中我们在跟getWifiInfo方法的时候,也跟进去了,所以我们分析一下这个是什么意思。

 

 

经过代码流程的跟踪,我们到了这个类,发现这里是处理Message流程的地方。

当前bind走的是case 0,也就是this.a.b(arg5.obj);

再跟一下。

 

 

这里的是我们请求的v0_1,即需要post数据的json字符串,可以看到保证code有数值,或者qq有数值即可。

然后走this.a(“ok”,v0_1);是正常绑定的流程,所以我们继续跟进去。

 

 

看到这两个红框标识的位置,我们保证刚才传过去的字符串包含ok,而json数据中包含上面提到的code数值,以及uuid数值即可,这就是bind的过程,即绑定uuid的过程。测试一下。

我们简单截图一下:

 

 

下面是请求访问成功的截图。

 

 

这里绑定好uuid之后,后面的请求我们按部就班地跟着分析就行,没有什么难度了。

 

比如getapplist协议,getappInfo协议。

 

 

 

获取手机安装的app列表信息不算太可怕。

我们往下分析。

 

 

 

根据名称,我们推测一条是下载安装app的,另外一条是在手机上显示对话框的。

访问构造参数根据代码分析一下就好,这里就不贴了。

直接发一下测试结果。

 

 

 

好了,这样就测试完毕了。因为这里下载,安装,没有走su的流程,也就是没有使用静默安装的,而是调用的系统安装页面,所以是上图所示。

 

0x6.安全建议

 

1).使用RSA加密操作,对所有的请求进行RSA加密,然后本地存储RSA公钥进行身份验证。

2).去除这部分命令执行功能,使用应用层的intent实现打开网页。

3).监听0.0.0.0的端口转为127.0.0.1,或给相关执行动作加入用户安全提示,需用户允许才能打开网页。

 

0x7.关于作者

 

ggz,360信息安全部-vulpecker team

 

360 vulpecker team隶属于信息安全部,专注于研究安卓安全,研究方向重点为安卓APP安全和安卓系统安全。开发并维护了免费的在线Android应用安全扫描服务 appscan.360.cn ,方便了众多移动应用开发者。

该团队发现了安卓通用型拒绝服务漏洞,影响市面上几乎所有的安卓产品,该通用型本地拒绝服务可以造成大面积的app拒绝服务。还发现了安卓APP新型通用安全漏洞“寄生兽”,安卓系统下包括支付宝、高德、微信等超过千万个APP都可能存在这一漏洞。在kcon等安全大会上发表演讲,公开了多款手机浏览器的远程溢出漏洞和众多流行手机应用的远程攻击漏洞研究成果。