作者： Ioannis Gasparis, Zhiyun Qian, Chengyu Song, Srikanth V. Krishnamurthy

单位： University of California, Riverside

出处： USENIX Security 17

资料： Paper, Video

Abstract

在android平台的众多恶意软件中，最危险的一类就是包含可以root用户手机的Malware。但是同时检测这种恶意软件也是非常困难的，这是因为这样的恶意软件所包含的root exp通常针对特定的设备或者系统版本，并且恶意程序在检测到不存在预期的运行时环境时就直接停止运行。使用Google Bouncer这种模拟器很难触发并分析这种root exp。所以作者设计了一个叫做RootExplorer的原型机去检测这种包含root exp的恶意软件。这个RootExplorer会根据一些商业公司提供给用户用来一键root的APP去分析学习exp的先决条件和环境要求，然后使用这些信息构建分析真机或者虚拟机的环境去检测包含root exp的恶意软件。

1.Introduction

在本篇文章中，作者主要去通过首先分析一键root的APP，因为许多商业公司如百度，腾讯，奇虎都会提供免费的通用一键root工具给用户。这些一键root工具通常会包含上百个大量的root exp以便于方便用户直接安装就可以一键root。所以这个rootexplorer系统就可以先通过分析这些应用中的root exp，然后使用每个exp的签名去动态检测恶意软件。 但是就算这样，也很难检测exp，因为最大的问题就是几乎所有的漏洞都针对特定的Android设备型号或操作系统版本，那么可能需要成千上万的设备才能触发这些exp。为了解决这个问题，rootexplorer会事先从一键root工具中根据分析好的每个exp的相关信息去创建对应exp所期望的运行环境，从而使exp去触发执行。 整个RootExplorer包含两大部分，一是离线训练部分，二是在线检测部分。离线训练部分会通过对一键root应用的行为分析得到包含的exp的相关信息；在线检测部分会通过构建exp对应的特定的环境去检测exp。

2.Background & Related Work

2.1 Root Exploits and One-Click Root Apps

通常情况下反病毒软件的权限是一定要高于应用软件的，所以一些商业公司会提供一键root工具给用户去root自己的手机，而且各大一键root厂商都会以谁家工具root的手机种类和版本比较多未竞争，，所以这些工具会包含越来越多的root的exp，这样就会给收集exp带来很大的便利。同时，根据这个团队在CSS’15的Android root and its providers: A double-edged sword论文中的数据，有些一键root工具甚至还包含了未公开的0day。但是根据恶意软件的调查，还没有发现恶意软件包含0day，作者分析因为这些恶意软件的作者通常没有能力也没有必要去开发新的root exp。

TL;DR

因为Android硬件和操作系统的碎片化导致很有必要去构建exp相应的环境去触发检测恶意软件中的root exp。 作者把exp所需要的precondition分为两类：

• environment checks
• preparation checks

2.2 Android Malware Analysis

Static Analysis Dynamic Analysis Hybrid Analysis:

• combines static and dynamic
• static analysis guide dynamic analysis

2.3 Other Related Work

Android Emulator Evasion:

因为恶意软件的作者很容易检测出是否运行在模拟器中，所以准备使用真机和使用Morpheus定制的模拟器环境同时进行分析。

Syscall-based Behavior Modeling:

使用基于syscall行为检测去检测恶意软件的root exp攻击尝试

3 Threat Model and Problem Scope

只分析检测Google play商店或者第三方应用市场上的Android App中包含的root exp，不包括0day。并且假设这些exp已经被混淆过了，而且有可能包含反调试和虚拟机检测等检测分析环境的功能。

4 RootExplorer Overview

在训练阶段，尽可能多地收集exp。对于每个exp，1)统计其系统调用的顺序和依赖性生成每个exp的行为签名，2)确定触发exp的前提条件。 在离线分析的第一阶段，使用符号执行去分析出root exp成功执行时的执行路径。作者构建了基于IDA pro的符号执行引擎，它能够处理在利用二进制文件训练集中遇到的所有指令和libc函数。 第二步，作者从符号执行输出的可执行路径中提取系统调用的顺序和跨系统调用的依赖关系，然后用来构造这个exp的行为签名。

由于我们已经收集了在符号执行期间通过系统调用（即先决条件）从系统返回的信息的限制，所以我们只需要查询一个SMT求解器来提供满足前提条件的具体实例。

之后，系统使用exp的行为签名和前提条件直接进入动态分析阶段，准备exp所需要的的环境并满足必要的前提条件，从而触发并检测各种root exp。

作者在接下来阐述了为什么不直接从网上获取公开exp的原因：

• 它觉得公开的exp质量并没有一键root中的exp那么好
• 根据作者之前的调研显示一键root工具中中包含60中root exp
• 这些exp被打包进同一个app，那么很可能使用同一种混淆方式

Learning the expected behavior signature:

每个exp的行为签名从二进制文件中去混淆然后提取出来之后，仍然有很多种构造恶意软件签名的模型。作者选择基于syscall去做行为签名，因为root exp会通过syscall去和操作系统交互从而达到攻击漏洞的效果。这方面的工作会在第五部分具体解释。

Learning preconditions:

在前面提到exp的precondition分两种：environment相关和exploit相关。经过离线训练得到的信息，在动态分析阶段可以提供预期的Android设备信息来触发漏洞。但是很难确定哪些Android设备可以使用哪些漏洞（因为需要对真实的设备进行漏洞利用），然而一键root工具会把当前设备信息发送给后端服务器，然后得到一个当前设备能使用的二进制exp列表。作者通过逆向得到了2万个Android设备和能够利用的exp之间的映射列表。

5 Behavior Graph Analysis

因为很多恶意软件都加了很多混淆，所以动态分析是最好的方式，但是又因为每个exp要在特定的设备上才能运行，所以对于众多的exp不方便在真机上进行分析。为了解决这个问题，我们对二进制的root exp去混淆之后进行提取行为特征。

行为签名是通过将低级操作抽象为高级行为表示来构建的。 可以检查在运行时表现出类似行为的恶意软件样本，从而检测特定exp的存在。因为exp以不同的方式与内核（或设备驱动）交互从而达到利用过程。作者通过对ANUBIS进行修改之后使用syscall事件建模的方式对exp的行为进行捕捉。

Behavior graph for the “camera-isp” exploit.

Using Behavior Graphs in Detection

当离线分析得到不同的root exp对应的graph之后，作者使用一个类似Google Bouncer的在线扫描器去检测App。如果符合以下三点，那么就认为是匹配的：

1. 使用动态污点分析去跟踪恶意软件的行为，如果系统调用的顺序符合行为图中的依赖关系，并且在成程序运行中也保持；
2. 每个syscall在调用是所使用的参数与行为图中的参数相匹配；
3. syscall的返回值与行为图中的返回值相匹配。

6 Satisfying Exploit Preconditions

因为所有的应用都不是跑在真机或者模拟器上的，所以需要建立一个满足root exp运行的环境，当exp利用的过程要求运行系统环境返回某些结果的时候，环境必须返回预期的值或对象。作者使用符号执行和SMT求解器去解决的这部分问题。

在动态分析期间，作者可以通过虚拟syscall结果来提供之前的前提条件。 为了提高环境的鲁棒性（即使其更真实），作者决定使用诱饵对象为某些类型的内核对象的操作提供预期的结果。 作者只支持三种类型的诱饵对象：文件，套接字和设备驱动程序。

如果目标对象（如存在漏洞的设备驱动程序）在分析环境中不存在，那么只需创建诱饵对象。

如果对象（如/proc/iomem）已经存在环境中，那么将操作重定向到替代诱饵，而不是打开真实文件。

7 Detecting Root Exploits

这部分是整个检测系统的测试部分。

7.1 Operational Model

当开发者提交了一个App的时候，RootExplorer会首先使用静态器分析过滤判断这个App是否包含root exp。如果是，动态分析会进行分析得到这个App需要那种设备或者模拟器。动态分析器可以在真机或者模拟器中运行，也可以集成到各种恶意软件分析环境中。

7.2 Static Analyzer

Native code detector

1. 根据恶意软件病毒库判断是否包含恶意的native code
2. 是否包含能够动态加载native code的代码
3. 使用自定义的列表来确定它们是否可能包含root exp

Device detector

确定应该在扫描样的环境下进行动态分析，因为通常恶意软件也会包含针对不同手机的检测返回相应的exp

Device initiator

设备启动器监视所有应用可以获取设备和操作系统信息的接口，并通过手机到的andorid设备库返回应当返回的信息。

7.3 Dynamic Analyzer

动态检测器包含两部分，Loadable Kernel Module (LKM) 和一个后台服务进程

LKM hook 所有的kernel syscall,LKM会创建一个字符设备，并通过字符设备与user-land和kernel-land进行通信。

后台服务存储训练阶段生成的行为图和环境条件，以及当前运行的应用程序的状态。

当一个由被分析的app发起的syscall被hook之后，LKM会通过字符设备把当前syscall的参数和函数名称发送给后台服务。

后台服务根据行为图和环境条件决定返回什么样的信息给LKM。

首先，后台服务会检查行为图去判断syscall是否匹配下一个新的节点。

如果不是，那就告诉LKM继续运行，如果匹配，继续检查是否是open()或者socket()函数。

如果是，则返回一个诱饵对象，如果不是则把本来提供给诱饵对象的数据返回给已有对象。

8 Evaluation

测评的主要问题：

1. 能否检测出root exp的恶意软件
2. 会不会产生假阳性
3. 会不会遗漏恶意软件

Unit testing:

all of the exploits are successfully detected

Detecting other one-click root apps:

Detecting Exploit PoCs from the Internet:

Detecting GODLESS:

always trigger and detect its complete malicious behavior with respect to this exploit

Detecting Malware in the Antivirus malware dataset and 3rd-party Android Markets:

在1497个恶意软件样本和2000个APP样本中，相对于Virustotal，检测出来两个真阳性结果

9 Limitations and Discussion

1. 能够找到替代的攻击路径来利用相同的漏洞
2. 恶意软件作者熟悉驱动程序就有可能绕过分析环境
3. 将恶意行为分解为在多个进程中的片段，可以绕过针对单个进程行为的签名