A few weeks back, a vulnerability dubbed as ‘Android Master key vulnerability’ was revealed. 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 leverage of this vulnerability and exploit it. The news is already out that there are apps currently in the market which are taking advantage of this vulnerability. So let’s find out what the issue is, how hackers can exploit it and what needs to be done to fix it.
How Android apps work?
Android applications are .APK files (Android Packages) which are nothing but a collection of ZIP archives. For easy understanding let us try to open an APK file for an application and find out the same. Consider the application MyFirstApp.apk application which is signed by own my certificate. Before we go ahead, let us spend some time on android’s signing process.
It is mandatory that all installed applications in android be digitally signed with a certificate whose private key is held by the application’s developer. The Android system uses this 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. Hence after building an application and signing it with a certificate, you have an apk file at the end.
Assume that MyFirstApp.apk is any 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 with .zip you will be able to see the contents of the file.
As shown in the above figure, the APK file consists of subdirectory called META-INF, which contains signed checksums for all the other files in the package. Now if you modify any of the files in this package, Android will block the package to prevent the users from harmful activities. Android does this by verifying the checksum. Now 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, extracts each file object and matches it up with the corresponding checksum mentioned in the manifest file in META-INF:
Now try to modify any of these files, for example, try to modify the launch image file present inside MyFirstApp.zip\res\drawable-hdpi , rebuild it and try to install it on the device using the adb and you will find that android rightly notices that and shows the below message.
How the attack is accomplished?
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 do 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 and observe that android accepts it this time. It runs successfully without any complaints. Observe 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. Most important thing to note is almost all version of Android are vulnerable to this attack. The impact of this vulnerability and its exploitation is only limited by imagination of an hacker. For instance he can spy on your communication or he can go a step further and send premium rate sms without the users knowledge, make background calls, take pictures and forward to mails etc.
Some of the built in apps which come along with the phone have higher privileges than the other applications which are installed from the play store. So an attacker can take leverage of this and create apps which would have system level privileges. Bluebox team has successfully demonstrated this and changed the name of the kernel etc.
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.