Android Master Key Vulnerability—PoC

August 28, 2013 by

Rorot

The recently discovered master key vulnerability in Android has given a jolt to the Android team and other parties involved. This vulnerability allows attackers to inject malicious code into legitimate Android applications without invalidating the digital signature. It's very easy for hackers and attackers to take advantage of this vulnerability and exploit it. The news is already out that there are apps currently on the market that are exploiting this vulnerability. This was revealed at the recent Black Hat Conference 2013, although some researchers were able to publish the news a week before. So let's look into what the issue is, how hackers can exploit it, and what needs to be done to fix it.

How Does Android Code Signing Work?

Learn Vulnerability Management

Get hands-on experience with dozens of courses covering vulnerability assessments, tools, management and more.

Start Learning

Android applications are .APK files (Android Packages), which are nothing but a collection of ZIP archives. For easy understanding, let us open up an APK file for an application and find out the same. Consider the application MyFirstApp.apk application which is signed by my certificate. Let us talk a little bit more about this signing process before we go ahead and understand the underlying issue.

Android requires that all installed applications be digitally signed with a certificate whose private key is held by the application's developer. Why would you want to sign the piece of code? For two reasons basically—authenticity and integrity. Before installing any application, I want to make sure that the application isn't tampered with (integrity checking) and that it was created by the right person (authenticity checking). The Android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications. The Android system will not install or run an application that is not signed. So, after building and application and signing it with a certificate, you basically have an APK file at the end.

MyFirstApp.apk

MyFirstApp.apk is a simple application (just a random application) and looks like this when installed on the emulator.

APK files are nothing but collection of zip files. So if you rename an .apk extension as .zip you will be able to see the contents of the file.

As you can see, the APK file consists of a subdirectory called META-INF, which contains signed checksums for all the other files in the package. The main manifest file (MANIFEST.MF) has entries with the file name and digest-value of each file in the archive. Now, if you modify any of the files in this package, Android will block the installation of the package to prevent the users from harmful activities. Android does this by verifying the checksum. In order to verify the checksum of each of these files, Android has to extract each of these files from the APK archive. This is accomplished using the Java unzipping library, which will parse the ZIP-format APK file, extract each file object, and match it up with the corresponding checksum mentioned in the manifest file in META-INF:

Now try to modify any of these files; for example, modify the launch image file inside MyFirstApp.zipresdrawable-hdpi folder, rebuild it, and try to install it on the device using the adb and you will find that Android rightly notices it and shows this message:

How Is the Attack Accomplished?

The vulnerability is based on the exploitation of the way in which Android verifies and installs the application. This helps in inserting code into the application without modifying the cryptographic signature. The attack successfully bypasses this verification process and installs the application with any changes the hacker embeds in the code. The attack is based on the concept of placing two different files in the APK archive with the same name. Regular ZIP software generally does not allow you to have two files with the same name in one archive. But the ZIP format itself doesn't prevent duplicated filenames, and you can take advantage of this to create an archive with repeated file names as shown below. The ic_launcher.png file is something that I have added to the existing file and created a new APK file named HackedFile.zip.

Now rename this file to HackedFile.apk and try to install it; you will observe that Android accepts it this time. It runs successfully without any complaints. Note that I was able to replace the launch image successfully without using any certificate and Android happily accepts the same.

How Is This Even Possible?

This is possible because Android verifies the first version of any file in archive but the installer verifies and extracts the last version of the file. Thus the legitimate file is checked by the cryptographic verifier and the one added by the hacker is installed by the installer. In simple words, what gets installed is a fake but what gets verified for signature is legitimate part.

What Are the Implications?

The implications are huge. The most important thing to note is that almost all versions of Android are vulnerable to this attack. The impact of this vulnerability and its exploitation is only limited by the imagination of a hacker. For instance, he can spy on your communication or he can go a step further and send premium rate SMS without the user's knowledge, make background calls, take pictures and forward to mail, etc. Some of the built-in apps that come along with the phone have higher privileges than the other applications which are installed from the play store, so an attacker can take advantage of this and create apps that have system-level privileges. A Trojan application that is installed from a device application can access the entire Android system and their applications and their data. As explained by Jeff Forristal, an attacker can then create a botnet with the always internet connected mobile phones. The Bluebox team has successfully demonstrated this and changed the name of the kernel, etc.

Symantec researchers have already discovered that the bug is being exploited in the wild by attackers by publishing popular games in third-party sites. Google has already released patches for this but, as everyone knows, it will certainly take some time for the handset makers to update all of their models. Google is now verifying all the applications in the play store to check for the master key vulnerability. But the other third-party stores and the side loading of apps aren't going to help the cause.

What Precautions Could Help Users to Stay Away from This?

1. It's important to download the apps only from the Google Play Store and, even while downloading from the play store, make sure that you verify the author of the application before downloading it. Do not install applications from untrusted sources or other Android stores. Similarly, say "No" to side loading of applications. In short, make sure you identify the publisher of the application before you install one.
2. Google has already rolled out patches for this. Make sure you update your mobile with the latest patches available.

Apart from these, an application also released in Play Store, "Blue Box Security Scanner," will scan your device and let you know whether it is vulnerable to this Android master key vulnerability. Here is one screenshot of the program.

Video

Here is the video link that practically demonstrates how this can be accomplished:

Learn Vulnerability Management

Get hands-on experience with dozens of courses covering vulnerability assessments, tools, management and more.

Start Learning

http://www.youtube.com/watch?v=lUou23KN6qM