FIRMSCOPE: Automatic Uncovering of Privilege-Escalation Vulnerabilities in Pre-Installed Apps in Android Firmware

主要解决什么问题

android 系统固件的预装软件中有很多app存在漏洞,而且这些app权限往往比较高,所以容易造成安全威胁。本文意在自动挖掘预装app中存在的权限提升漏洞。

使用的方法

系统架构,workflow:

FIRMSCOPE0.png

1.unpack firmware

解压Android固件环节存在一个问题,各固件厂商的格式不一样。大部分厂商使用Android Sparse Image (SIMG) format 这种ext4格式的固件压缩方式,使用诸如e2tools这样的工具进行解压和挂载。但是,解压之后处理(unpack)就不是一致的了,有些厂商提供了第三方的unpack工具,比如华为的UApp格式,需要使用Splituapp进行unpack,HTC的RUU架构需要用HTC RUU DecryptTool,Sony 的.sin 架构需要用AnyXperia Dumper。一些厂商使用Sparse Data(SDAT)把image分块,分块文件可以使用Sdat2img重构回SIMG。
对于没有可用的解包工具的厂商固件,采用启发式的方法搜索一致的SIMG/ext4 头,尝试unpack。通常,镜像文件会被额外的头填充,只要剥离这些额外的头,就能得到标准镜像文件。

同时,努力寻找镜像文件中的build.prop和default.prop文件,其中可能包含了build fingerprint,os version,build configuration,exact make and model等信息。

另外,我找到一篇参考文章:Android各厂商Rom包解压方式

2.Extracting and Disassembling Apps

从unpack的image文件中找出所有DEX,ODEX,VDEX,OAT,JAR, 和APK格式文件,关于这些格式的更多信息可以参考here , 因为预装app的格式各不相同,文中将将所有提取出的app转换成APK的规范格式。对于预编译的OAT app,结合Oat2Dex和Baksmali,并参考之前提取出的framework files,把嵌入到ODEX、VDEX、OAT文件中的DEX classes提取出来,这一步输出汇编的DEX classes 或反汇编的smali。

把所有Dalvik bytecode反汇编成smali 代码,然后转换为中间表示IL(intermediate Language)Jasmin [35] and Jimple[36],我们还反编译应用程序的二进制的XML manifest文件,并提取有关应用程序及其所有声明的组件的元数据。具体来说,我们提取应用程序包的名称和版本信息,使用和声明的权限,以及所有导出的组件的全名和类型,以及所有指定访问权限的导出组件。

3.Static Taint Analysis

它首先建立了过程间控制流图inter-procedural Control-Flow Graphs(ICFG);然后,重建类层次结构并解析调用情况(第4.2.1节);推断Def-Use链,并构建过程间数据流图inter-procedural Data-Flow Graph(IDFG)(第4.2.2节);最后执行自定义的流敏感、上下文敏感、字段敏感和部分对象敏感的污点分析,以识别易受攻击的执行路径(第4.2.3节)。

ICFG和IDFG的部分跳过,来重点看看污点分析部分:(这部分先硬翻译一下😥)

根据先前IDFG架构,污点跟踪问题就转变为图遍历问题,从一个污点源到一个污点汇聚点或到多个污点汇聚点,污点源和汇聚点都是多重图中的节点。在遍历过程中,我们应用验证规则集去修剪不会到达敏感点的路径。这些上下文验证规则对于效率和精确度非常有影响,因为先前的方法在实作上在成了不必要的复杂度扩大。例如,由于无法大规模地使用call-site stack提供上下文敏感性,因为为每个call site创建stack在计算上是不可实现的 ,特别是涉及虚拟调用时,每个call site需要维护多个stack。此外,通过 字段 的流必须始终保持流敏感和上下文敏感,但是由于明显过度的开销以及跟踪和将所有这些副本链接复制到其读写整个app所在位置的复杂性,所以我们不能在每次访问该字段时就复制与该字段相应的所有节点。因此,最终,我们的分析 实现了上下文敏感,流敏感和字段敏感以及部分对象敏感:

Context-Sensitive:

我们通过将每个call指令与其自身的返回伪寄存器配对,并在污点跟踪期间保持一个调用栈覆盖在每个标记为污点路径的上方,来确保上下文敏感。

Flow- and Field-Sensitive:

我们的IDFG构造对流敏感,因为我们考虑了语句顺序并跟踪每个程序点的流。因为我们跟踪每个类字段的流,所以我们的构造也对字段敏感。

Partially-Insensitive:

确保类型兼容性使我们的分析对同级和不相关类敏感,对对象敏感,对单定义方法不敏感,对子对象和其祖先之一具有定义的虚拟方法不敏感。

Path-Insensitive:

FIRMSCOPE对路径不敏感,因为它虽然根据控制流图流动信息,但信息流动与不相关的条件分支之间可能存在的条件依赖性无关。路径敏感性是一个已知的难题,在实践中没有绝对解决方案[39]。

Detection Rules

我们开发了一套规则引擎,用YAML文件写探测规则。具体来说,我们实施了规则和插件来检测以下提权漏洞:

(i) command injection;

(ii) arbitrary app installation/removal;

(iii) code injection;

(iv) factory reset of the device;

(v) SMS injection, including accessing, sending, and manipulating text messages;

(vi) device recording, including audio, video, and screen recording;

(vii) log leakage to external storage or to other apps;

(viii) AT Command injection;

(ix) wireless settings modification;

(x) system settings modification.

结果评估

我们收集了从v4.0到v9.0的2,017个公开可用的Android固件映像(请参阅附录A以获得详细信息),总共涵盖了100多家Android供应商,其中包括全球排名前20的Android供应商。固件映像包含331,342个应用程序,具有15,144个唯一的软件包名称和39,541个唯一的软件包版本。该数据库的详细信息如表1所示。

FIRMSCOPE1.png

我们在三台服务器上部署了FIRMSCOPE,每台服务器在Intel Xeon E5-2630 v4 2.20GHz上运行64位Ubuntu 18.04,具有40个逻辑核心和150 GiB的RAM。我们使用GNU Parallel [41]实现了一个流水线来管理作业并在三个服务器上分配固件映像,并尽可能并行地分析多个应用程序,以保持最大80%的服务器负载而无内存交换。我们全面分析了每个固件映像,无论其某些应用程序是否可能出现在其他分析映像中。

表2是研究结果摘要。我们发现了850个独特的特权升级漏洞(共3,483个),占分析固件的77%。命令注入漏洞排在最前面,影响了三分之一以上的固件映像。

FIRMSCOPE2.png

我们按弱点类别按供应商提供细分:

FIRMSCOPE3.png

总结:表4中显示了AOSP与供应商应用程序中已识别的漏洞的总数。大约92%的漏洞是由供应商引入的应用程序(375个唯一的软件包名称)中,而AOSP中只有8%的漏洞(18个唯一的AOSP软件包名称)。这些结果说明,类AOSP的镜像比供应商定制的镜像更安全。供应商的修改通常会带来无法预料的漏洞

FIRMSCOPE4.png

对我有什么启发

这文章对我这个初学者来说有几方面的意义:

  • 更深入的接触到android 系统镜像
  • 对android run time(art), aot(ahead of time), oat(Ahead of time)file format, odex(Optimized Dalvik Executable file)的理解加深
  • 初次接触到taint analysis(污点分析技术)
  • CFG、DFG的构建是以后要学习的内容

这项研究的未来方向

其实我感觉它没有用很新的知识,就是把APP漏洞检测转到预装APP上做,多了一个拆包的过程,研究了一下AOSP-like的系统镜像和OEM厂商镜像中提权漏洞的类型和分布,并没有太多的创新点。

文中构建的FIRMSCOPE系统使用静态检测技术,涉及的主要技术点包括过程间CFG、过程间DFG的构建,污点分析技术。

未来,对于漏洞检测技术或许可以增加fuzzing、动态符号执行(Concoli)等动态分析技术。

ref:https://www.usenix.org/conference/usenixsecurity20/presentation/elsabagh