Authors: Mengmeng Li, Tianfang Guo, Jinjian Zhai
“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.
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?
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:
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:
The decrypted JSON looks like this:
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.
The last step is to load the library and trigger the exploit:
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.
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:
The jar file in the figure (…1111.jar) is a compressed file containing some tools for rooting as shown in the figure below:
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.
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!