Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

安全论文每日读 2015.02.21

今天继续介绍Mobile Security的论文,论文名字叫做:Design and Implementation of an Android Host-based Intrusion Prevention System 发表在ACSAC 2014学术会议上。这篇论文提出了Android平台上基于主机的入侵防御系统(HIPS)的一种设计,并实现了一个称为Patronus的HIPS,Patronus不用修改系统,并且可以动态根据运行时信息检测已知恶意软件。

论文slides:https://appsrv.cse.cuhk.edu.hk/~mssun/pub/acsac14patronus_slides.pdf

论文作者:Mingshen Sun, Min Zheng, John C.S. Lui, Xuxian Jiang

单位:The Chinese University of Hong Kong,NC State University & Qihoo 360

introduction

静态的杀毒软件已经无法满足需要,无法检测出恶意软件变种。而HIPS可以以软件形式装在设备上,动态监控系统信息,如金山毒霸,LBE,360等。他们无非有三种方式,system patching,重打包app,API hook。这三种方式各有利弊。而Patronus不要修改系统和app,动态检测malware。

background

主要讲了Binder机制,一个client和server的模型,负责Android上sandbox里的app之间的通信,以及与系统服务的通信。

HIPS

三种HIPS架构。

  • system patching:第三方的vendor做的系统镜像如华为的,还有第三方ROM,如cyanogenmod,PDroid等,官方例如app ops就是一种。这种第三方ROM需要适配机型,且无法有效防止malware,另外Android 4.3之前都没有
  • app重打包:重打包删除权限如app shield,重打包监控敏感API如aurasium。重打包有很多局限性,另外敏感API也很难找全,无法禁止malware
  • API Hooking:API hooking需要做到:1,得到root或system权限。2,注入so到目标进程。3,对目标API做hook。4,执行策略。一般来说都是加载个native so文件,ptrace到进程上,用dlopen和dlsym来注入一个so,在中断的API前面先去调用so里的方法,再回到原来的API。使用gDvm里的insns可以得到原来方法的指针,修改这个值就能调用so里的方法了。像LBE,金山,xiaomi自带的,都是这样,主要都是用Binder里的client端的hooking,对驱动之前的最底层的native API hooking即可。这种方式因为hook还在app的沙盒里,所以malware本身可以阻止这种行为。先看自己的maps,如果有其他进程的so或者jar之类,就能确定是不是被注入了。然后到敏感API的地方,直接改写insns,或者实现自己的Binder方法,不使用被hook的系统本身的binder方法。

Patronus

Patronus 架构

设计要点

  • app用ptrace去注入到system service以及进行client端的注入。并且有用户界面。
  • service是个sticky service,用来监控恶意软件安装之类。并且拦截Binder中的数据传输,并可读写policy,根据policy来做enforcement。
  • injected files包括client和server的,client和之前一样。server端的hook主要是hook system service的execTransact函数。
  • policy database:用XML文件来管理每种binder通信的transaction。用户可以操作管理。\

当发现例如偷发短信,获取地理位置信息时,就会弹窗告知用户。首先会在client端做检查,但由于client端可能可以绕过,因此server端如果发现一个行为Client端没有检查和告知过,就会弹窗告知。能抵御之前说的对现有的HIPS的bypass。

还能检测恶意软件。通过对恶意程序抓取transation信息,来做出footprint,之后检测时在运行过程中生成动态的各种向量,来求相关性和footprint的匹配,做malware的检测。

Evaluation

作者测试了500个正常程序,200多个basebridge,15个mobiletx和9个fakeAV。同时性能损耗比较少。具体的评估结果可以参考论文。