Many people underestimate the possibilities a remote attacker has who managed to exploit a remote code execution vulnerability on Android devices.

On Windows systems, it is widely accepted that a vulnerability in one software can lead to the compromise of other software and, ultimately, to the infection of the whole system. The same is, in fact, also possible for Android, even though many people believe the attacker would be confined to the vulnerable app’s context (in the Android file system and UID/GID sandboxing sense).

In this blog post we will show how a vulnerability in one single app can lead to the permanent (and virtually irreversible) infection of an Android device with malware. To this end we will walk the reader through the single steps that lead from a vulnerability in a third-party browser to full remote control with root provileges of the device and permanent infection with malware.


The steps are roughly as follows:

  1. The victim of the attack has a vulnerable app with a remote code execution vulnerability installed.
  2. The attacker exploits the vulnerability remotely.
  3. The attacker uploads a root exploit and a malicious app to the victim’s smartphone.
  4. The attacker triggers execution of the root exploit.
  5. The root exploit installs the attacker’s malware.

Some readers may be thinking now: Wait, this is no rocket science. And you are right, this isn’t rocket science! It is a typical sequence of attack steps that lead from initial compromise over privilege escalation to permanent infection. The purpose of this blog post is to show how this can be done in practice by walking the reader through the steps.

The Attack

Step 1: Getting a Foot in the Door

Once in a while remote code execution vulnerabilities pop up in Android apps. They enable an attacker to run their own code in the context of the vulnerable app. A famous recent example for this are the StageFright vulnerabilities. For this blog post however, we will exploit the addJavaScriptInterface vulnerability [1] – one that can be found in some apps that render web content, for example browsers. For this vulnerability to be exploited, the victim only needs to navigate to a website that contains malicious code. This can happen for a number of reasons:

  • The victim opened a malicious link he received via email, instant message, SMS, on a social network…
  • The victim is in a WiFi and subject to a man in the middle attack during which the attacker injects the exploit code into active connections.
  • The attacker manages to deliver exploit code on benign websites through advertising networks.
  • The attacker exploits a vulnerability in a web server to include his own code in the website, e.g. through persistent XSS or SQL injection.

If an attacker manages any of the above, he is able to hijack the vulnerable app’s process and execute his own code – for example a remote shell.

For now however, this remote shell will only have the same access the vulnerable app has. Let’s change that!

Step 2: Uploading a Root Exploit and Payload

Now that the attacker has a remote shell he can upload files to the vulnerable app’s working directory, for example root exploits:

Step 3: Execution of the Root Exploit

Trivially, the attacker can now execute the root exploit to gain root privileges:

Step 4: Infection of the Device

The attacker now has two options to infect the device: A simpler one, which will install the attacker’s malware as a regular app (which the victim would be able to uninstall). The second one is a bit more evil: Without rooting their device the victim will be completely incapable of removing the attacker’s malware.

The first option is very straightforward. After uploading his malware, the attacker will now issue this command in his root shell:

This will perform a regular app installation.

The second option first remounts the /system partition as writable (usually, it is only readable). Then, it writes the malware to /system/app. This folder contains system and preinstalled apps. Now, the attacker can remount the /system partition as read-only and finally reboot the system, which will trigger an “installation” of the attacker’s malware:

Step 5: The End

That’s it. The attacker managed to place an app in /system/app silently, without the user noticing. The attacker can thus use almost any Android permissions which exist and the victim will be completely incapable of uninstalling the app. The victim has silently been infected with (almost) unremovable malware which now has widespread privileges on the system. In fact by using the root exploit utilized before, the app can maintain permanent root access.

Of course this whole process can also be automated.


Mobile devices and their vulnerabilities are underestimated, when in fact they can just be as dangerous as typical Windows software vulnerabilities. They exploited and leveraged for permanent, silent infection with malware just like their desktop counterparts.