Hackers don’t need root exploits

Authors: Mengmeng Li, Tianfang Guo, Jinjian Zhai

lightsabers-clash-850x560

“Root as a Service”

RaaS – Root as a Service is a phrase used to describe the methodology of malware launching a root exploit with server side support, in which the client side will dynamically request exploits specified for its hardware and OS version from the server. This implementation gives more confidentiality and upgrade flexibility to the exploits.

In recent months, an increasing number of RaaS malwares have been reviewed, such as “GhostPush” and “Kemoge”. These malwares are capable of downloading root exploits from their command & control server, and rooting the victim’s phone. They then take advantage of the root privilege to install 3rd party apps, and remove antivirus apps which prevents them from being uninstalled.

image02
RaaS: the attack procedure

Using similar root exploits, the root tool (PC or Android based), on the other hand, becomes a necessity for some Android users who want to have total control of their phones. Driven by user demand, even the largest players in the industry have published their own root tools, which are designed to be used as easily as one-click ordering. Those vendors have certainly considered the safety of their root exploits, and have utilized protection mechanisms – such as anti-debugging and data-encryption, to protect their exploit binaries.

On the ACM-CCS conference, researchers from University of California, Riverside published a paper “Android Root and its Providers:A Double-Edged Sword” about the analysis of popular root tools. According to the paper, most of the exploits from rooting tools could be extracted and reverse engineered. And those tools are like double edged swords – once the exploits are leaked, no one can guarantee they will not be used for evil purposes.

After reading this paper, we decided to further explore a possibility: with the root vendors exposing their backend APIs, is it doable to forge the client side requests, abuse the vendors’ service, and root someone’s phone in the background (say, make a “root SDK” that can be integrated into malwares) without preparing a single root exploit?

Case study

We started with a popular root tool A. Because this tool has utilized strong code obfuscation, we did our analysis by dynamic execution in our sandbox, and analyzed the events after the large “Root” button was clicked.

Its RaaS implementation is quite clear:

  • Upload user’s device info to the server, such as phone type, OS build info, and kernel version.
  • The server will respond a JSON, containing the download link of a “root solution”, usually a native library
  • The app will then download the library file, load it, and let the root exploit do its job
  • Remove all the downloaded config files and exploits

Initial Request to the root server with phone info:

image03

The returned JSON file is encrypted by the AES algorithm. However, the decryption algorithm and key are all implemented locally. It cannot hide from our dynamic analysis:

image00

The decrypted JSON looks like this:

image07

Using the download link from the JSON file, the real exploit will be downloaded and renamed with an unpredictable number, and stored in the app’s private folder.

image05

The last step is to load the library and trigger the exploit:

image04

The exploit library file has been modified with some anti-debugging mechanisms, such as corrupting its Section Header Table and adding overlapping instructions. However, those efforts only added difficulties on static and dynamic analysis, not loading and execution. We can launch the exploit by loading this library, execute its entrance function and root the target phone.

image06
image08
Corrupted ELF header prevents static analysis. But can be easily repaired

Another rooting tool, B, used a similar architecture as A, and also proved vulnerable against forging requests. Its configure file downloaded from the server has not been encrypted:

image01

The jar file in the figure (…1111.jar) is a compressed file containing some tools for rooting as shown in the figure below:

image09

The root tool B will drop the corresponding root exploit and the related tools in a directory named by a three digit number. It is possible for an attacker to exhaust all the possible device info combinations to steal all the exploits from that vendor.

The dropped exploit is not protected and can be decompiled easily. We learned the way it works, how it exploits the Android system, and the corresponding CVE or non-CVE vulnerabilities involved. More detailed analysis will be included in a later blog post.

Conclusion

The root tool is a double edged sword. Although the vendors tried their best to prevent the exploits being abused, the nature of RaaS makes it difficult to detect whether the client request is forged, nor can the vendors protect their exploits from being abused by someone else. As long as their “root service” is enabled, the possibility of their backend being abused by hackers exists.

We have more research on rooting tools coming up. Stay tuned!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s