Qihoo 360 Technology Co. Ltd. (NYSE: QIHU)
Zihang Xiao, Qing Dong, Hao Zhang and Xuxian Jiang
Jan 17, 2014
——
A few days ago, we found an Android Trojan using brand new method to modify devices’ boot partition and booting script file to launch system service and extract malicious application during the early stage of system’s booting. Due to the special RAM disk feature of Android devices’ boot partition, all current mobile antivirus product in the world can’t completely remove this Trojan or effectively repair the system. We named this Android Trojan family as Oldboot. As far as we know, this’s the first bootkit found on Android platform in the wild.
According to our statistics, as of today, there’re more than 500, 000 Android devices infected by this bootkit in China in last six months. We’ve released a new security tool (download) which can accurately detect and defines it.
Construction and behaviors of Oldboot
While an Android device be infected by Oldboot, its user will find some new applications which contain lots of advertisement frequently being installed to the system. In the installed applications list, the user will find a system application named GoogleKernelwhich can’t be uninstalled manually. Antivirus products, such as 360 Mobile Security, will classify this application as malware (Figure 1). However, after removing it and rebooting the device, the two previous phenomenon will occur again.
Oldboot is constituted by four executable or configuration files:
- /init.rc, the configuration script for Android system’s booting which has been modified by Oldboot
- /sbin/imei_chk, an ELF executable file for ARM architecture
- /system/app/GoogleKernel.apk, an Android application which is installed as system application
- /system/lib/libgooglekernel.so, the native library used by the GoogleKernel
Figure 1 Antivirus product classify the GoogleKernel as a malware
These four files have complex calling relationship (Figure 2):
- When Android system is booting, it will read the init.rc, launch the imei_chk as system service and open related local socket;
- The imei_chk will then extract the libgooglekernel.so into /system/lib;
- The imei_chk will also extract the GoogleKernel.apk into /system/app;
- After system’s booting finished, the GoogleKernel.apk was installed as system application. It will periodically execute native code in the libgooglekernel.so to trigger malicious behaviors;
- The libgooglekernel.so will generate configurations or malicious commands, and pass them to Java code in the GoogleKernel.apk;
- The GoogleKernel.apk sends commands to the imei_chk through socket. These commands will be executed by the imei_chk at last.
Figure 2 Components of Oldboot and their relationship
Below is more detailed analysis to these files.
At the tail of the init.rc’s content, we found these lines:
service imei_chk /sbin/imei_chk
class core
socket imei_chk stream 666
According to this, when Android system’s booting, the init process will launch a new system service named imei_chk with root permission, and will create a local socket with the same name.
Before creating socket and listening, the imei_chk will execute some code which read two data blocks from its read-only data segment and then extract them to these two files (Figure 3):
- /system/lib/libgooglekernel.so
- /system/app/GoogleKernel.apk
Figure 3 The imei_chk extracts so and APK files
On the other side, the imei_chk will create a socket to receive all coming data. These data will be parsed to Linux system commands which will be executed with root permission at last (Figure 4).
Figure 4 The imei_chk receives commands and executes them
In the infected device, we found the imei_chk socket is running with root permission and is listening to receive data from any other process. Please note that the access property of this socket device is 666 with the setuid flag (Figure 5). This world-writable property will lead to a serious security vulnerability: In the infected devices, any other applications can send this socket device some Linux commands which will be executed with root permission later.
Figure 5 The imei_chk socket device can be written by any process
When Android system is booting, it will check whether all APK files under /system/app are installed. If not, it will installed them as system applications (or so called pre-installed applications). Thus, the GoogleKernel.apk will be installed as system application, while the libgooglekernel.so, its reliant native library, has been extracted to correct place.
When removing normal Android malware, all previous Android antivirus products will only uninstall and delete malicious APK and so files. Thus, when the device rebooting, the undeleted imei_chk will extract GoogleKernel.apk again. In fact, these antivirus product not only won’t, but also can’t effectively remove the imei_chk. We’ll discuss on this later.
Let’s have a deeper look into the GoogleKernel.apk. It declares many system or dangerous level permissions in the AndroidManifest.xml, and specifies itself running by the system user:
……
The application has only one service named Dalvik and two receivers named BootRecvand EventsRecv, without any activity as well as user interface. Its main behaviors include collecting system information, changing network settings, and periodically triggering other malicious behaviors such as:
- Connecting to its C&C Server (Figure 6) to download configuration file;
- Connecting to its C&C Server to get back system commands, and executing with root permission;
- Downloading APK files (Figure 7) and installing as system applications (Figure 8)
- Uninstalling specified system applications.
From some unfinished functions’ name, it seems that the author of Oldboot was planning to implement sending SMS to any specified phone number (Figure 9).
Figure 6 The libgooglekernel.so stores C&C servers’ URL to its global config
Figure 7 The libgooglekernel.so downloads APK files and install them
Figure 8 The downloaded APK files are installed as system applications
Figure 9 The libgooglekernel.so tries to send SMS, but related Java code isn’t finished
The author of Oldboot intentionally designed malicious behaviors’ implementation. All main malicious behaviors are split to many different execute phases which are implemented in different components:
The GoogleKernel.apk will periodically activate itself to call JNI interfaces of the so file to trigger malicious behaviors (Phase 1).
If the behavior is to connect with C&C servers, the so file will construct servers’ URLs and call Java code in the APK file through JNI again (Phase 2). The APK file will start HTTP connection to servers and return request result to the so file (Phase 3). The so file then parses result’s format to get commands, configuration or data (Phase 4).
If the behavior is to install APK files, or to uninstall system application, after downloading APK files through the above phases, the so file will construct system commands (including remount the system partition and pm install/uninstall) for installation or uninstallation and pass them to the APK file through JNI (Phase 5). The APK file will send these commands to the imei_chk service through local socket (Phase 6, see Figure 10 and Figure 11). At last, the imei_chk will execute these commands with root permission (Phase 7).
Figure 10 The GoogleKernel.apk initializes connection with local socket imei_chk
Figure 11 The GoogleKernel.apk send system commands to the socket
New infection methods
Differ from previous malware on Android, the main specialty of Oldboot is its modification to the init.rc file and the /sbin directory.
In Android, the root directory and the /sbin directory locate in the RAM disk which is loaded from the boot partition of device’s disk. This RAM disk is a read-only in-memory file system. And any runtime changing on it will never be physically written back to the disk. Thus, during system’s running, even we remount the partition to writeable, and delete some files in these directories, the deleting operations won’t really apply to the disk. After the device rebooting, these files will appear again.
Previous Android malware, such as DroidKungfu, may extract malicious files to the /system partition. But the /system partition doesn’t have the above feature, which means, there’s no any technical difficult on both malware’s file writing and antivirus’ file deleting.
However, when facing Oldboot, even the antivirus products know the imei_chk is a malicious which need to be deleted, they can’t really completely delete it by previous traditional method since this “remount” method will only delete the copy of /sbin/imei_chk in memory but won’t affect the disk partition.
The problem is, how the attacker put the imei_chk into /sbin directory and successfully modified the init.rc script? We believe there’re at least two ways to achieve it:
- The attacker has a chance to physically touch the devices, and flash a malcious boot.img image files to the boot partition of the disk;
- During system’s running, after gaining root permission, forcibly write malicious files into boot partition through the dd utility.
In Oldboot’s case, we’re more likely to believe that the attacker chose the first way (But we still can’t exclude possibility of the second one). Here’re reasons:
Firstly, we found the infected device is bought from a big IT mall in Zhongguancun, which is a famous and the biggest consumer electronics distributing center in Beijing. In the past, we’ve found some retailers here flashing system images which contain malware into mobile phone or tablet them selling.
Secondly, the infected device (the Galaxy Note II) contains Samsung’s stock system; all normal system applications in it has Samsung’s official signature. However, the recovery partition has been replaced by a third-party recovery ROM, and the timestamp of all files in the boot partition are the same (2013-05-08 17:22).
Thirdly, based on Qihoo’s cloud security technology, we counted models of all known infected devices. More than half of them are not well-known popular models. If the attacker used the second way to infect devices remotely, the attack targets will be randomly and out of control which should be distributed more close to the real market distribution of Android devices.
Related samples
The APK file extracted by Oldboot uses a self-signed certification. We found two other malware used the same certification.
The first malware disguises as normal security application. It will dynamically register aContentObserver to observe any changes of the SMS inbox. Every time a new SMS is coming, it will check if its content contains words such as “QQ number” or “password” in Chinese (Figure 12). If these words exist, it will delete this SMS, and upload the content to some specified severs. In the past, the Tencent provided service to recover QQ password through SMS. Thus, this malware can steal user’s QQ account at that time. The malware also uses receivers and service with the same name as in Oldboot’s APK file.
Figure 12 The Oldboot’s related sample will steal QQ’s password
The second related malware was named GoogleDalvik. Its code structures, including JNI interfaces and entry classes, are almostly the same as Oldboot,. The only difference between the GoogleDalvik and GoogleKernel.apk is, the previous doesn’t communicate with the imei_chk through socket. For installation or uninstallation system application, it just execute commands in its Java code (Figure 13).
Figure 13 The Only difference between Oldboot and its previous version
We believe, the GoogleDalvik is an earlier version of Oldboot, a version without bootkit component. The GoogleDalvik and Oldboot all use domains such as androld666.comand androld999.com as their C&C servers’ URL, this is the main reason we named this family as Oldboot.
Solutions
Now, we’ve released the first special security tool for Oldboot. You can download it from:
http://msoftdl.360.cn/mobilesafe/shouji360/360safesis/OldbootKiller_20140117.apk
This tool will deeply and precisely scan Android devices to find the existence of Oldboot and its variants. We’ve developed a new defines method in it which can effectively disable all malicious behaviours of Oldboot.
Besides of using our security tool to detect and defines it, we also suggest the users:
- Checking this tool’s updating regularly. We may add more ability to detect or clean its further variants.
- If it finds Oldboot on your phone, please report your phone’s information and the samples to us. This will help us a lot.
- You can also try to re-flash your device with its origin stock ROM. After flashing, the Oldboot should be completely removed.
- Since only modified devices will infect Oldboot, if you’ve find it by our tool, you can also directly contact with your reseller to take customer service.
- We also suggest you to install the 360 Mobile Security application and using its cloud detection ability to protect your mobile phone and tablet.
Discussion
Before we found Oldboot, the most famous Android malware which is widely considered as rootkit is a variant of the DroidKungfu family. It gains root permission by system vulnerabilities, remounts system partition, replaces some executable files in it, and rewrites system configuration files. It also tries to run malicious code in the early stage of system’s booting to prevent be cleaned by antivirus applications.
However, there’re many differences between DroidKungfu and Oldboot. Firstly, Oldboot’s infection method isn’t simply remounting system partition and changing files like DroidKungfu, but physically operating device’s disk (through flash or dd). Secondly, Oldboot can’t been removed or repaired in the file system level, but DroidKungfu can be. At last, this attack method, which exploits boot partition’s RAM disk feature, can be easily developed to implement more advanced file system level hidden.
We believe Oldboot creates a totally new malware attack method on Android. Through physically touch or disk level operation, the further Android malware can similarly write themselves to the boot partition and modify the init.rc script to gain very earlier launch priority with high running permission to avoid being cleaned by antivirus solutions, as well as to effectively hide themselves. As the first found bootkit on Android, the Oldboot has symbolic significance. We will closely follow further development of this kind of attack.
——
(media contacts: [email protected])