Oldboot：Android平台的第一个bootkit

看看大神的记录，膜拜一下，(*^__^*) 嘻嘻……

转载自：奇虎360科技有限公司（NYSE: QIHU）

肖梓航，董清，张昊，蒋旭宪

——

近日，我们发现了一个Android木马采用全新的攻击方法修改设备的boot分区和启动配置脚本，在系统启动的早期创建系统服务和释放恶意软件。由于boot分区的RAM disk特性，全球所有的反病毒软件都无法彻底将其清除。我们将这个木马家族命名为Oldboot。据我们所知，这是Android平台发现的第一个bootkit。

根据360手机卫士的统计，在过去六个月，中国已经有超过50万台Android设备感染了该木马。我们已经开发了新的专杀工具（下载），可以有效地检测和防御这个bootkit。

Oldboot的结构和行为

当一台Android设备感染了Oldboot，用户会发现系统中经常出现一些自己没有安装过的软件，这些软件中通常含有大量广告。此外，在已安装软件列表中，可以发现名为GoogleKernel的系统应用软件，它无法被手工卸载。使用360手机安全卫士等杀毒软件，可以检测到该软件为恶意代码（图 1），但是在清除之后，再次重启手机，前面两个现象会再次出现。

事实上，Oldboot一共由四个代码和配置文件组成，包括：

• /init.rc，是Android系统启动的配置脚本，已经被Oldboot修改；
• /sbin/imei_chk，是一个ARM架构ELF格式可执行文件；
• /system/app/GoogleKernel.apk，是一个被安装为系统应用的Android应用软件；
• /system/lib/libgooglekernel.so，是GoogleKernel.apk的本地库文件。

图 1 反病毒软件检测到GoogleKernel是恶意代码

这四个文件之间存在复杂的调用关系，如图 2所示：

• Android系统在启动时，会读取init.rc中的配置，将imei_chk启动为系统服务并打开socket端口；
• imei_chk释放libgooglekernel.so文件到/system/lib目录下；
• imei_chk释放GoogleKernel.apk文件到/system/app目录下；
• 系统启动后，GoogleKernel.apk成为系统软件，它周期性地调用libgooglekernel.so中本地代码触发恶意行为；
• libgooglekernel.so生成配置参数或恶意的系统命令，通过JNI将它们传给GoogleKernel.apk中的Java代码；
• GoogleKernel.apk将这些命令通过本地socket发送给imei_chk，后者以root权限执行这些命令。

图 2 Oldboot的组件结构及其关系

下面是对这些文件的进一步逆向分析。

在init.rc文件的结尾处，存在这样几行配置：
service imei_chk /sbin/imei_chk
class core
socket imei_chk stream 666
根据上述配置，在Android系统的启动过程中，init进程会以root权限启动名为imei_chk的系统服务，并创建同名的本地socket。

在打开socket端口之前，imei_chk会执行一段代码，从自己的只读数据节中读出两块数据，并释放为如下两个文件（图 3）：

• /system/lib/libgooglekernel.so
• /system/app/GoogleKernel.apk

图 3 imei_chk释放出so和APK文件

另一方面，imei_chk会打开一个socket，监听所有发来的数据。这些收到的数据会按照一定的格式被解析为Linux系统命令，并以root权限执行（图 4）。

图 4 imei_chk接收命令并执行

在被感染的设备中，可以看到imei_chk这个socket正以root权限运行，并且接收任何其他进程发来的数据。请注意这个socket设备的访问属性是666，且拥有setuid标志位（图 5）。这个全局可写的属性会导致一个严重的安全漏洞：在被感染的设备上，任何第三方软件都可以向这个socket设备发送系统命令，这些命令会以root权限被执行。

图 5 imei_chk通过socket接收任何进程发来的命令

Android系统在启动时会检查/system/app下的所有APK文件是否已经安装，如果没有，会将其安装为系统软件（又叫预装软件）。因此，被释放出来的GoogleKernel.apk会被安装为系统软件，它所依赖的本地库libgooglekernel.so也已经被释放到了合适的位置。

由于此前所有的Android反病毒软件在清除普通Android恶意代码时，只会卸载和删除恶意APK和so文件，因此，系统再次启动时，未被清除掉的imei_chk会再次释放出GoogleKernel.apk。事实上，这些反病毒软件也无法有效地删除imei_chk文件，我们会在后面进一步讨论。

先分析GoogleKernel.apk的行为。它申请了许多系统级的或危险的权限，并且指定自己要以system用户身份运行：


<uses-permission android:name="android.permission.MOUNT_UNMOUNT_FILESYSTEMS" />
<uses-permission android:name="android.permission.INSTALL_PACKAGES" />
<uses-permission android:name="android.permission.DELETE_PACKAGES" />
<uses-permission android:name="android.permission.CLEAR_APP_USER_DATA" />
<uses-permission android:name="android.permission.WRITE_SECURE_SETTINGS" />
……
<application android:allowBackup="true" android:allowClearUserData="false" android:killAfterRestore="false" android:label="GoogleKernel" android:persistent="true" android:process="system">

这个APK软件仅包含一个名为Dalvik的service，以及名为BootRecv和EventsRecv的两个receiver，没有任何activity，因此没有用户界面。它的主要行为包括搜集系统信息、更改网络设置，以及定期触发下列恶意行为：

• 连接到控制服务器（图 6），下载配置文件；
• 连接到控制服务器，取回系统命令，并以root权限运行；
• 下载APK文件（图 7），将其安装为系统软件（图 8）；
• 卸载指定的系统软件。

从一些尚未开发完成的函数名称来看，Oldboot的作者还计划实现向任意号码发送短信的功能（图 10）。

图 6 libgooglekernel.so将C&C服务器的URL保存到全局配置

图 7 libgooglekernel.so下载APK文件并安装

图 8 下载的APK文件会被安装为系统软件

图 9 libgooglekernel.so尝试发送短信，但Java部分代码未完成

在实现这些恶意功能时，Oldboot的作者专门做了精心的设计，将每一个主要的恶意行为分为多个不同的执行阶段，在不同的组件中实现。

首先，GoogleKernel.apk会周期性地激活自身，调用so文件暴露的JNI接口来触发恶意行为（阶段1）。

如果是要连接控制服务器，so文件中的代码会构造URL，然后又通过JNI回调APK文件中的Java代码（阶段2）。APK文件会发起到服务器的HTTP连接，并将请求结果返回给so文件（阶段3）。so文件再对结果进行格式解析，获得其中的指令、配置或者数据（阶段4）。

如果是要将APK文件安装为系统软件，或者卸载系统软件，除了经历上述阶段下载APK文件外，so文件还会构造一系列安装或卸载的命令（包括remount系统分区和pm install/uninstall），然后通过JNI接口将这些命令发给APK部分代码（阶段5）。APK文件将这些命令通过本地socket发给imei_chk服务（阶段6，见图 10和图 11）。最后，imei_chk会执行这些指令（阶段7）。

图 10 GoogleKernel.apk建立与imei_chk的本地socket连接

图 11 GoogleKernel.apk向socket发送系统命令

新的感染方法

Oldboot与以往Android恶意代码最大的区别在于它修改了init.rc文件和/sbin目录。

在Android系统中，根目录和/sbin目录位于一个RAM disk中。该RAM disk是一个只读的、位于内存中的文件系统，从设备磁盘的boot分区加载而来，但是运行时发生的变化不会被物理地写回去。因此，在系统运行期间，如果将这些目录重新挂载为可写，再删除其中的文件，由于删除操作并不会真正被写回磁盘，在设备重启后，这些文件会再次从磁盘的boot分区中被加载到内存。

在以往的Android恶意代码中，DroidKungfu会将恶意文件写入到/system目录下。但是/system目录并不具有上述特性，因此，无论是恶意代码将这些文件写入，还是杀毒软件将其删除，都不存在技术上的困难。

而面对Oldboot，即便杀毒软件意识到imei_chk也是一个需要删除的恶意文件，采用以往的清除方法也无法将其彻底删除，因为那种remount的方法只会删掉内存中的/sbin/imei_chk拷贝，而不会对磁盘中的分区内容造成实质性的影响。

那么，攻击者又是如何将imei_chk释放到/sbin目录下，并成功地修改了init.rc文件呢？我们认为，至少有两种方法可以做到：

1. 攻击者此前曾物理地接触到被感染设备，并将包含了恶意文件的boot.img镜像文件刷到设备的boot分区中；
2. 在系统运行期间，获得root权限之后，可以通过dd工具将恶意文件强行地写入到磁盘的boot分区中。

在Oldboot这个攻击中，我们更倾向于认为攻击者采用的第一种方法（但我们不能排除第二种攻击方法的可能）。

首先，我们发现的被感染设备购买于中关村的某大型IT卖场，并非购买于官方渠道。在此之前，我们已经多次发现中关村的部分经销商会将包含恶意代码的Android系统镜像刷到他们销售的手机或平板电脑中。

其次，我们发现的被感染设备（Galaxy Note II）安装了Samsung官方的Android系统，其中的普通系统软件均包含有效的Samsung官方签名，但是recovery分区已经被替换为一个第三方的ROM。此外，boot分区下的所有文件都拥有相同的时间戳（2013-05-08 17:22）。

最后，基于360的云安全技术，我们对所有被感染设备的型号进行了统计，发现其中超过一半都不是流行的大众机型。而如果采用第二种攻击方法进行远程感染，目标是随机不可控的，被感染设备型号分布应该更接近于Android设备的市场分布情况。

关联样本

Oldboot释放的APK文件使用了一个自签名的证书，我们发现另外两个恶意代码样本也使用了该证书。

第一个样本伪装成常用的安全软件，在运行时动态地注册一个ContentObserver，监控短信收件箱的变化。每当收到新的短信时，它会检查其中是否包含“QQ号”、“密码”等内容（图 12）。如果存在，则将这条短信删除，并将其内容发送到指定的服务器。在早期，腾讯公司曾提供通过短信找回QQ密码的服务，这个恶意代码在当时可以窃取用户的QQ账户。这个恶意代码还使用了与Oldboot的APK文件中同名的receiver和service。

图 12 Oldboot的关联样本窃取QQ密码

第二个样本的软件名为GoogleDalvik，其主要的代码结构与Oldboot释放的APK文件及so文件几乎完全一致。GoogleDalvik和GoogleKernel.apk唯一的区别是，它并没有建立与imei_chk的socket通信，对于安装和卸载系统软件的请求，它在Java层直接执行了相关命令（图 13）。

图 13 GoogleDalvik与Oldboot的主要差异

我们认为，这个GoogleDalvik是Oldboot的一个早期的、不包含bootkit部分代码的版本。GoogleDalvik和Oldboot均使用了androld666.com和androld999.com等域名作为控制服务器URL，这是我们将该家族命名为Oldboot的主要原因之一。

解决方案

目前，我们已经独家发布了全球首个Oldboot专杀工具，下载地址是：

http://msoftdl.360.cn/mobilesafe/shouji360/360safesis/OldbootKiller_20140117.apk

该专杀工具可以对Android设备进行深度地精确扫描，判断其中是否存在Oldboot及其变种。我们在其中开发了全新的防御技术，可以有效拦截Oldboot的各类恶意行为。

在使用该专杀工具以外，我们的安全建议还包括：

1. 定期检查该专杀工具的更新，我们将逐步增加对Oldboot后续变种的检测和查杀能力；
2. 在专杀工具检测到Oldboot后，将的机型信息和样本上报给我们，可以帮助我们更好地发现新的变种；
3. 您可以将手机重新刷写为设备厂商官方提供的系统ROM，彻底刷机后，Oldboot应该已经被清除了；
4. 由于只有系统被经过篡改的手机设备才会感染Oldboot，如果使用我们专杀工具检测到Oldboot，您也可以直接联系手机的经销商，协商售后事宜；
5. 安装360手机安全卫士，开启云查杀功能，保护手机和平板电脑的安全。

讨论

在Oldboot出现之前，Android平台最著名的被认为是rootkit的恶意代码是DroidKungfu家族的一个变种，它利用系统漏洞获得root权限，重新挂载system分区，替换其中的一些可执行文件，并且改写系统配置文件，同样尝试实现在系统启动的早期运行其恶意代码并且防止被反病毒软件清除。

与DroidKungfu相比，Oldboot有许多不同之处。首先，它的感染方式不再是简单地重新挂载系统分区并写入文件，而必须通过（刷机或者dd工具来）物理上操作磁盘。其次，Oldboot无法在运行时通过文件系统级别的操作就清除和修复好。最后，这种利用boot分区的RAM disk特性的攻击方法还可以被进一步扩展，实现更高级的文件系统级隐藏。

我们认为，Oldboot创造了Android平台一种全新的恶意代码攻击方法。通过物理接触或磁盘操作，将自身写入boot分区，并改写init.rc脚本，恶意代码可以获得极早地启动优先级和最高的运行权限，可以有效地避免被杀毒软件清除，并可以更有效地隐藏自身。作为Android平台的第一个bootkit，Oldboot具有标志性的意义。我们将继续紧密关注这类攻击方法的发展并提供安全保护方案。