ParseDroid: Targeting The Android Development & Research Community

Research By: Eran Vaknin, Gal Elbaz, Alon Boxiner, Oded Vanunu

Latest research from the Check Point Research Team has revealed several vulnerabilities, that puts each and every organization that does any type of Java/Android development at great risk of a threat actor exploiting these vulnerabilities and penetrating them.

The vulnerabilities in question are the developer tools, both downloadable and cloud based, that the Android application ecosystem, the largest application community in the world, is using. This includes the tools that all Java/Android programmers use to build their companies business applications and that security analysts and reverse engineers use to do their work.

Through our own research we have found several vulnerabilities that affect the most common Android IDEs – Google’s Android Studio and JetBrains’ IntelliJ IDEA and Eclipse, as well as the major reverse engineering tools for Android applications such as APKTool and more.

Our research below illustrates how we exploited these tools to gain access to internal files. Since this research, Check Point reported the discovery to APKTool developers and the other IDE companies back in May 2017. In turn, Google and JetBrains have verified and acknowledged the security issues and have since effectively deployed a fix.

Technical Details – From XXE to RCE: Attacking The Second Layer

The first stage of our research was focused on APKTool, (Android Application Package Tool).

As the most popular tool for reverse engineering third party Android apps, APKTool is used for supporting custom platforms, analyzing applications and much more, including the decoding and rebuilding of resources.

The two main features of the APKTool are:
1. Decompiling an APK file.
2. Building an APK file.

From our research we found that APKTool is vulnerable in both of these main features.

By looking at the source code of APKTool, we managed to identify an XML External Entity (XXE) vulnerability, due to the fact that the configured XML parser of APKTool does not disable external entity references when parsing an XML file within the program.

The vulnerable function is called loadDocument and it is being used in both core functionalities –  ‘Build’ and ‘Decompile’ – of APKTool.

The vulnerability exposes the whole OS file system of APKTool users, and as a result, attackers could then potentially retrieve any file on the victim’s PC by using a malicious “AndroidManifest.xml” file that exploits an XXE vulnerability, that could then be sent to a remote attacker server. And this attack scenario is just one of many possible XXE attack techniques that could lead to harmful outcomes.

Realizing the enormity of this vulnerability to the Android developer and researcher community, we extended our research to the vulnerable XML parser called “DocumentBuilderFactory”, which is being used in APKTool project.

Vulnerabilities in Developer Tools

This led us to find multiple vulnerable implementations of the XML parser within other projects. Moreover, we identified that the most popular IDEs that are used for building Android applications are affected – including Intellij, Eclipse, and Android Studio.

By simply loading the malicious “AndroidManifest.xml” file as part of any Android project, the IDEs starts spitting out any file configured by the attacker.

To demonstrate this vulnerability, we have uploaded a malicious project library to GitHub and cloned it to an Android Studio project.

Example of a Malicious Github Project With The XXE Payload:

Cloned to Android Studio:

Result: The attack was delivered successfully, and the protected file was stolen and sent to the presented attacker’s server without the user being aware of it – See image below:

Furthermore, we have found another attack scenario that can be used in the wild to attack a massive range of Android developers by injecting a malicious AAR (Android Archive Library) containing our XXE payload into repositories.

It is possible, for example, to upload an infected AAR to a public repository such as the central Maven repository, though for demonstration purposes we have uploaded an infected AAR to a local repository. Cloning the infected AAR from the repository by the victim would allow the attacker to steal sensitive files such as configuration files, source code, company digital proprietary and much more from the OS file system.

Uploading a Malicious AAR to Local Repository:

Adding the AAR to Android Studio Project:

Result: The attack was delivered successfully, and the protected file was stolen and sent to the presented attacker’s server without the user being aware of it:

Further research of the APKTool then led us to find an additional vulnerability that allows us to execute OS commands on a victim’s PC.

For advance use of APKTool there is a configuration file named “APKTOOL.YML”.

This file contains an interesting section called “unknownFiles”, which allows users to include a non-standard file location that will be placed correctly on the rebuild process of an APK. The selected files are saved on the filesystem in the ‘Unknown’ folder.

A legitimate “APKTOOL.YML” file structure looks like this:

By manipulating the path of the “unknownFiles” section inside the “APKTOOL.YML” file, it is possible to inject arbitrary files anywhere on the file system (Path Traversal). This is due to the fact that the APKTool does not validate the path of which the unknown files will be extracted from the packed APK.

Indeed, injecting arbitrary files anywhere in the filesystem leads to full Remote Code Execution (RCE) – meaning that any APKTool user/service that will try to decode a crafted malicious APK is vulnerable to RCE.

For demonstration purposes, we have created a Web Application similar to the official online APK decoder (https://apk.tools).

APKTool will extract the malicious file (in this case we used a PHP web shell) to the wwwroot folder of that server:

After building the APK with the modified configuration file, the result is a compressed APK with our malicious file inside the malformed path.

Uploading the APK to the demo site allows the attacker to execute OS commands on the web application server. This attack could thus be launched against any online/offline service that decodes APKs behind the scenes using APKTool.

The way we chose to demonstrate this vulnerability of course is just one of many possible attack methods that can be used to achieve full RCE. Indeed, the Path Traversal method lets us copy any file to any location on the file system, making the attack surface wide and various.

All the attacks methods demonstrated above are cross-platform and generic and, as the APKTool is designed to work on top of several operating systems, it is also possible to attack any system on which it operates without restriction or limitation.

It is impossible to estimate the number of users of this well-known open source project. Yet, knowing that among them are some large services and companies (e.g. https://apk.tools, http://www.javadecompilers.com/APKTool, https://www.apkdecompilers.com/, http://undroid.av-comparatives.info, Cuckoo droid and many more), we contacted APKTool developer and IDE companies and are pleased to report that they all fixed the security issues and released updated and improved versions of their products.