Sophos Cloud Optix
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?”
This puts a clear and realistic understanding to what is clearly important but other *may* be creating self-motivated hype around. Great article, Duck!
Thanks.
The company that issued the "bluebox-uncovers-android-master-key" press release was trying to promote its forthcoming talk at BlackHat without giving so much away that no-one would bother to attend the session – so I get the reason for the headline, and it's not an outrageous metaphor by any means…but I still got a bit confused by the words they chose to use 🙂
Having said that, it is a poor show from Google. Can't be denied. I suspect that one or more coders in Mountain View are standing in a nervous queue outside the headmaster's office waiting to Be Talked To!
I think you understate the seriousness and vendor culpability here; a broken algorithm is as bad as a stolen key, as it bait and switches from what you expect, and what you get.
This is the same sanctimonious vendor who released exploit details before a competitor could fix an exploitable defect Google had found. What goes around…
I hear you!
I tried to avoid passing judgement in the article, as I think the flaw speaks loudly enough for itself, but as I replied above to @Tony, the bug is a poor show from Google.
I did find myself wondering how Google's new disclosure guidelines will affect the company's response. It announced a few weeks back that "we believe that more urgent action – within 7 days – is appropriate for critical vulnerabilities under active exploitation." 60 days' of grace, it seems, is too long these days.
(Google doesn't say what "urgent action" means, and to be fair, it has taken *some* action in this case, since the code to fix the flaw is published. Also, there are mitigations, as mentioned in the article.)
Nevertheless, I wonder how tough Google is going to get with its handset vendors to push out updates? If Google thinks that seven days to fix critical vulns is an acceptable timescale for the world at large (and it's certainly a fantastic goal to aim for), I wonder how long those of us with Android phones or tablets will end up waiting for firmware fixes?
Nothing on the Google Online Security Blog yet…watch that space.
I don't think the seriousness of this bug was ever as dramatic as Bluebox suggested. While the exploit works (or worked) in a way that makes their initially vague description accurate it lacked an attack vector.
For a malicious party to take advantage of this in a meaningful way they'd essentially have had to compromise the Play Store credentials of an established developer and replace the app with a trojaned clone.
And the risk to system software as described by Bluebox seems very implausible as it would require actually compromising a device manufacturer to get the trojan into the distribution chain. If someone could get to that point then presumably they may be able to compromise signing keys or worse anyway?
The practical exploitability of this bug seems very limited. Even more so now that the Play Store specifically scans packages for this.
Does this pertain to the older versions of Android or is it applicable to any version?
That's what happens when you rely too much on widely known shared libraries. This is a naughty trap though. What happens is that both versions of the file are extracted and the last replaces the first…
Such archives should be deemed damaged and raise an error upon extraction as it makes no sense to have duplicated filenames in an archive anyway.
Google may be at fault for not being paranoid enough but the bug really comes from the people who coded the shared zip extraction library!
Android malware is a serious issue that needs to be addressed, there is several public forums openly selling android malware very cheap. With features like camera spying, real-time call recording, tracing GPS location, exporting photos/messages e.t.c
The big feature alot of the underground blak hats are using is the ability to silently sens premium sms messages, i advise all people to have av on there phones and yes sophos is great.
The Google play store is plagued with genuine apps binded with the rogue apk's, several of the sellers also add the option for them to personally upload to Google play-store for an additional fee of $5.
I will happily helpyou out with an article Paul showing how the rogue apk's work and the features they use.
lewis
Really good post! Can you tell me the method to add multiple files with same name in a zip archive? Thanks in advance! 🙂
Good post!!! Was explained in a good way. Does this applies to all versions of android??
Shouldn't there also be a manifest signature for the zip archive listing?