Anatomy of a security hole – Google’s “Android Master Key” debacle explained


This month’s “computer security elephant in the room” story is the news of a gaping security hole in Android application security.

If you’ve seen the headlines, you’d be forgiven for thinking that someone just pulled off a giant feat of cryptographic cracking.

Actually, the headlines are down to a smart PR coup (albeit a slighty naughty one) by self-styled mobile security startup Bluebox.

The company published a blog article with a URL that unashamedly proclaimed: bluebox-uncovers-android-master-key.

Bigger still was a headline that unrelentingly bellowed the words UNCOVERING ANDROID MASTER KEY THAT MAKES 99% OF DEVICES VULNERABLE:

It turns out that the headline is entirely metaphorical, since no keys were actually recovered from anywhere.

What really happened, it seems, is that Bluebox found a way to modify Android installation packages so that the operating system fails to spot that they’ve changed.

Android still carries out a cryptographic verification, and it still sees the right bytes to pass that check; it’s just that it doesn’t check the right parts of the file.

Android package files

Apps for Android are delivered as .APKs (Android Packages), which are actually just ZIP archives with a special extension.

Inside each APK file is a subdirectory called META-INF, containing signed checksums for all the other files in the package.

The theory is that if you tamper with either the META-INF files or the app itself, for example to replace files in the package with malware-infected imposters, Android will block the package to protect you from catastrophe.

At this point, you ought to be asking yourself, “How does Android extract each file from the APK archive in order to verify its checksum?”

The answer is that it uses a Java unzipping library to parse the ZIP-format APK file, extracting each file object and matching it up with the corresponding checksum listed in the manifest file in META-INF:

The manifest checking seems to work.

For example, I easily modified and rebuild the APK, using a bog-standard ZIP utility:

But when I tried to install the modified APK (I used the Android emulator and the Android Debug Bridge, better known as adb), Android correctly spotted the modified files and the hacked package was blocked:

So far, so good.

Malformed APK archives

What you might think of asking next (as the Bluebox techies did) is the slightly more devious question, “What would happen if there were two different files in the APK archive with the same name?”

Regular ZIP utilities generally prevent you from having two files with the name in one archive: it doesn’t make sense, since you wouldn’t know which one to choose when unzipping.

But the ZIP format itself doesn’t preclude duplicated filenames, and with a bit of hacking and tweaking, you can fairly easily create a utility to build a archive with repeated filenames like the one shown above.

Oh. Guess what?

Android’s cryptographic verifier validates the first version of any repeated file in an APK archive, but the installer extracts and deploys the last version.

In other words, the APK passes its cryptographic tests at install time, even though what gets installed is bogus:

Real versus hacked

Installing the unmodified test package places a new icon on the Android launcher screen like this:

In the hacked app, however, I had modified several files, as shown in the listing above.

I scrawled the word PWN3ED over the launcher icon files, and I edited the name of the app in the resources file from Activity under demo to Duck Changed This!!:

As you saw above, I was able to install the hacked APK without triggering a digital signature failure, allowing the modified app to adopt the cryptographic identity of the original:

It runs without error messages or complaints from Android, too:

How bad is this?

Bluebox disclosed this flaw responsibly to Google, and the Mountain View coders have already patched the hole.

The fix checks for duplicate filenames in APK files, to ensure that there is only ever one version of any filename listed in the manifest, thus preventing a mismatch between the file that gets verified and the file that gets installed:

What to do in the meantime?

Of course, even though a fix has been coded, you’ll still have to wait until the vendor of your handset publishes an upgrade for your firmware.

That might take some time.

So, until you receive a firmware fix from your provider, you can mitigate the risk if you:

  • Stick to the Google Play Store, where it is reasonable to assume that Google, now forewarned, will be aggressively monitoring officially-sanctioned APKs for duplicate filename trickery.
  • Use an Android anti-virus (yes, Sophos just happens to have a good one, and it’s free) that can scan newly-installed packages automatically before you run them.

Neither the Play Store nor your favourite anti-virus can guarantee to keep all unwanted apps off your device, but together they will come close.

And if you’re a programmer, remember that when it comes to testing, you should expect the worst, and prepare for it.

Ask unusual and unlikely questions, like the one that Bluebox came up with when they asked themselves, “What would happen if there were two different files in the APK archive with the same name?”