Exploit (& Fix) Android "Master Key"

[Nytro]

Exploit (& Fix) Android "Master Key"

Earlier this year, Bluebox Security announced that they had found a bug in Android that could be used to modify the contents of any application package (including ones distributed as part of the system software) without affecting the attached cryptographic signatures; details to be disclosed at Black Hat USA 2013.

However, enough detail was disclosed in the abstract of the talk that others were able to find this bug. Later, a patch was applied to the popular open-source Android ROM CyanogenMod, making the issue both public and obvious: there are now proof-of-concepts for how this bug might be used in concrete form.

In this article, I describe a different approach to the exploitation of bug #8219321 that does not fall prey to the limitations of previous descriptions (specifically, the packages being attacked do not need to have an existing "classes.dex" file inside, which is not actually common on production devices).

This technique is simple enough that it can be performed by hand; this article walks the user through the process, allowing a full understanding of how the exploit is performed. However, an automated tool called Impactor is also introduced that is capable of performing this process on virtually any Android device.

Finally, details of how the underlying bug behind this exploit can be patched using the Cydia Substrate code modification framework are provided, along with a concrete implementation that can be installed on any device supported by Substrate. In the process, an overview of existing work in this area is provided.

Many people reading this article will be doing so only to learn about how to use Cydia Impactor to exploit their device. The download links are: Mac OS X and Windows. This article includes instructions (using local.prop) under "Obtaining Root" that work up through approximately Android 4.1, including Glass and Google TV.

Background Information

A few months ago, the schedule for the yearly Black Hat USA conference was posted. With a catchy title and a powerful abstract, one talk in particular caught the eye of many people browsing the conference: Android: One Root to Own Them All. The abstract is as follows, discussing an undisclosed vulnerability.

This presentation is a case study showcasing the technical details of Android security bug 8219321, disclosed to Google in February 2013. The vulnerability involves discrepancies in how Android applications are cryptographically verified & installed, allowing for APK code modification without breaking the cryptographic signature; that in turn is a simple step away from system access & control.

A lot of discussion occurred regarding this bug, but few details were available past that abstract and a couple cryptic posts to Twitter by Bluebox Security, the company whose founders were giving the talk. It was over a month later that further information was published by Jeff Forristal, the discoverer of the bug.

In their blog post, Uncovering Android Master Key that Makes 99% of Devices Vulnerable, a rather bleak picture was painted of the threat posed by this discovery, and in the weeks that followed, the story generated a lot of press, being covered by everything from TechCrunch to the LA Times.

Play Store Safety

On Android, all applications are signed by their developers using private cryptographic keys; it is by comparing the certificates used to verify these signatures that Android's package manager determines whether applications are allowed to share information, or what permissions they are able to obtain.

Even the system software itself is signed by the manufacturer of the device; applications signed by that same key are thereby able to do anything that the system software can. Normally, this is only possible if you are the manufacturer; however, using bug #8219321, anyone could steal those signatures for their own.

A key concern this raises is that applications in the wild might be signed with the system keys of your device; while you think you are just installing a harmless game, that application would look to the package manager as if it came from the manufacturer, giving it elevated and dangerous system permissions.

Thankfully, in the CIO article Vulnerability allows attackers to modify Android apps without breaking their signatures, we learn from Forristal that when Google was made aware of this bug by Bluebox Security, they did not find packages exploiting this bug in their Android application market, the Play Store.

Using Google Play to distribute apps that have been modified to exploit this flaw is not possible because Google updated the app store's application entry process in order to block apps that contain this problem, Forristal said. The information received by Bluebox from Google also suggests that no existing apps from the app store have this problem, he said.

Another potential exploit vector are packages that have the permission to install other packages. Interestingly, and as noted in H-Online's article Android's code signing can be bypassed, "Google blocked non-Play-Store updating in April this year". That policy being a workaround for this security issue is a compelling thought.

Responsible Disclosure

Of course, as many of my readers are keenly aware, there are non-malicious reasons to be interested in such vulnerabilities. Many users have devices that are locked down by manufacturers or carriers for any number of dubious reasons. To free these devices, exploits are often used to empower the user.

The result is that many times, bugs like this are hoarded and used by groups such as evad3rs without any warning or notice to those who might be affected, for the purpose of accessing locked up devices. This is, of course, a dangerous game to play; but, it is one that some of us feel we must attempt.

With bug #8219321, Bluebox Security made a point that they felt "responsible disclosure" was important, notifying Google about the bug well before Black Hat, when the bug was to be disclosed to the public. (Jeff Forristal is reportedly even "responsible for the first publicized responsible security disclosure policy".)

However, there was an abstract posted that explained that there was a signature vulnerability; a few of us in the security community were able to find this bug based on this information alone: knowing where to look and knowing there's something there to find makes the process of discovery much much easier.

Finding the Bug

In my case, I had previously looked at the handling of zip files while commenting on a bug someone had found in 2012, Ice Cream Sandwich: why native code support sucks. In my comment, I described the hashtable used to read an archive; so, when I looked at the code used to verify the archive, the bug was quite clear.

Once I had found the bug, I was posed with a moral quandary: do I release a tool that helps people use and patch this vulnerability, or do I wait until it is disclosed to the public at Black Hat? After some consultation with other security researchers on IRC, I purchased a ticket to Black Hat, tentatively deciding to wait.

In the end, however, Bluebox Security made a point

about drumming up more press about the issue, which led to more speculation and more eyeballs. While frankly, we should assume that the truly scary adversaries had the bug within hours of the Black Hat schedule being posted, now it was nigh-unto public knowledge.

To demonstrate just how easily this could be found, someone commenting on Hacker News managed to figure it out using only idle speculation based on reading a description of the jar signing algorithm; in ctz's comment, he describes two possibilities, the first one being the same bug found by Bluebox Security.

The zip format doesn't structurally guarantee uniqueness of names in file entries. If the APK signature verification chooses the first matching file entry for a given name, and unpacking chooses the last then you're screwed in the way described.

Soon thereafter, an issue was filed against CyanogenMod (an open-source alternative distribution of Android), Patch for Android bug security bug 8219321?; and coming right on its heels was a patch for the bug posted to their revision control system, Remove support for duplicate file entries. The bug is now public.

APK Verification

To some extent, I don't really need to describe the bug anymore, as this has been done by others; one highly-detailed blog even posted an entire series of articles (seven so far) documenting the bug called The Great Android Security Hole Of ’08 ?. However, as the way I exploit the issue is different, I will need to re-document the bug.

The core issue is that Android package (APK) files are parsed and verified by a different implementation of "unzip a file" than the code that eventually loads content from the package: the files are verified in Java, using Harmony's ZipFile implementation from libcore, while the data is loaded from a C re-implementation.

The way that these two implementations handle multiple files with the same name occurring in the zip file differs. The way the Java implementation reads the file is that it goes through the "central directory" and adds each entry to a LinkedHashMap. The key the entry is stored using is the name of the file.

....

Articol complet:

http://www.saurik.com/id/17