记一次Android后门分析实战

2018-12-18 17:19:046801人阅读

背景

 

在分析某android设备时,偶然发现一处后门,净查证,应该是360的雷电OS中的一个组件,顺便分析一波


01后门功能

system权限的app

提供诸多高危接口如:命令执行、静默安装/卸载应用、设置GPS信息、任意删除文件等操作;hook了众多framework函数如startService、getContentProvider、bindService等,监听交互流程;


02 发现

在系统里偶然发现一个system进程如下: 

 1.png

将其应用拖出来,解压之后目录如下:

2.png


 

这里主要分析ChiMaster.apk和chimahelper.apk

 

 

03 ChiMaster.apk分析

 

先分析其Manifest.xml文件:


 3.png

 

可以看到其注册了广播BootReceiver监听开机android.intent.action.BOOT_COMPLETED,猜其是开机自启,并启动恶意服务,跟进该广播:

 4.png

 

 

其作用是启动一个action为com.chima.android.policy.IPolicyService的服务,查看Manifest可知,该服务对应的是DaemonService,跟进该服务,找到其onCreate函数:

5.png 

其中除了正常的初始化流程之外,还有一个a.a函数,跟进下该函数,发现该函数的作用是初始化了NewPolicyService这个类,如下:

6.png  

  

继续跟进NewPolicyService这个类: 

7.png

 

 发现是IPolicyService的一个实现,我们看下IPolicyService,发现其是一个AIDL接口,并提供诸多高危函数:

 

8.png

 

9.png

 

而回到DaemonService,发现如下:


 10.png

 

并通过onBind进行返回:

11.png


因此可以确定,DaemonService对外提供服务,通过IPolicyService定义的AIDL接口进行,而真正的实现函数在NewPolicyService这个类中,这里我们分析其中的两个函数executeCmdInShell和forceStopPackage

 

签名校验


 原本以为这些接口可以随意利用提权,结果发现了签名校验函数

12.png

 

跟进如下:

13.png

可以看到获取了调用者的Uid,v0是签名校验成功与否的标志位,该函数通过反射的方式调用了checkSignPermissionByAPI,并将调用接口的名称和调用者的uid传入了进去,直接找到checkSignPermissionByAPI的实现

14.png

 

经过重重调用,最终定位到了其签名白名单

15.png


  因此第三方app无法调用,因此也无法提权,这里我做了下验证:


if (binder != null) {

Log.e(Tag, "start");

Parcel _data = Parcel.obtain();

Parcel _reply = Parcel.obtain();

try {

_data.writeInterfaceToken("com.chima.android.policy.

IPolicyService");

binder.transact(2, _data, _reply, 0);// getversion

Log.e(Tag, "" + _reply.readInt());

} catch (Exception e) {

e.printStackTrace();

}

} else {

Log.e(Tag, "binder is null");

}

Intent intent8 = new Intent();

intent8.setAction("com.chima.android.policy.IPolicyService");

intent8.setPackage("com.chima.vulcan");

bindService(intent8,connection,BIND_AUTO_CREATE);

 

果然是签名校验失败:

16.png

 

 


froceStopPackage

 

从命名来看应该是强制关停某应用的,跟进其实现,这里中间绕过了一些细节:

17.png


可以看到是通过反射了ActivityManager中的forceStopPackage函数来实现的,这个只是一个代表,其中很多接口都是反射系统接口实现的

 


executeCmdInShell

 

该接口从命名来看是执行shell命令的,跟进关键部分:

18.png

 

 

继续跟进,中间省略几处跳转,最终跟到了下面,v6_1是最终构造的参数,c是一个OutputStream


 

19.png

这里困惑了,执行shell命令为何会向OutputStream中写入?我们需要跟进这个c的赋值处:


  20.png



这里我理解了,是一个本地的socket,执行shell命令的是一个native程序,通过localsocket进行通信,继续跟进通信的this.b的赋值处


21.png 

也就是应该存在chima这样一个程序,通过localsocket执行shell命令,这里我并没找到chima这个程序,关于localsocket的介绍参考:

 

https://www.cnblogs.com/bastard/archive/2012/10/09/2717052.html

 

因此这个执行shell命令的接口是通过接受签名白名单中应用的输入,然后通过localsocket与chima进行交互。

 


04 chimahelper.apk

 

这个apk并没有被动态加载,因此怀疑ChiMaster是个裁剪过的后门,也或者是本菜鸡并未分析出其加载的位置

 

chimahelper.apk主要是对一些framwork函数进行hook,hook方法应该是借鉴了Legend的免root,hook方法,其hook的方法如下:

 

1.  getContentProvider;

2.  bindService;

3.  deletePackage;

4.  installPackageAsUser;

5.  startService;

 

hook的主要作用是用来做自我保护,不让任何非白名单的应用来启动服务,这里分析startService函数:

22.png


 

首先就是获取调用者的uid和pid,这里直接跳到关键位置:

  

23.png

跟进shouldBlock这个函数,应该是阻断函数:

24.png


isChimasterCalling函数

25.png

 

isOnForeGround函数

26.png

 应该也是一个提供给第三方调用的stub,并不太清楚

 


isExistInBlackList函数

 

黑名单函数 

27.png

 

是从policyprovider中去读的黑名单packagename

 


isAppAlive函数

 

确定是否是运行着的进程

 

 

05 总结

 

1.  该样本应该是个裁剪过的样本,比如自我保护apk并没有动态加载到主进程中,我执行bindservice也并没有阻断;

2.  该样本的基本功能是作为一个后门程序供白名单app使用,由于我测试的设备并未获取root权限,部分分析是处于猜测,并为实际验证;

3.  命令执行的chima代理也并未找到(权限不够),也无法查询init.rc来看是否真正定义;

4.  分析还略微糙,本菜鸡还需努力

样本下载:ChiMaster.apk.zip


本文由百度安全合作作者(ID:三胖子日了猫了)提供,如需转载需注明出处及本文链接

0
现金券
0
兑换券
立即领取
领取成功