3

Bluebox have recently disclosed a vulnerability (Android security bug 8219321) in Android, that is getting a lot of coverage in the media.

The title of the post is "Uncovering Android Master Key" - I'm assuming this is just a media-friendly headline, and a master key doesn't come in to it.

From what they have disclosed so far, it allows for

APK code modification without breaking the cryptographic signature

Taking this at face value, if it is possible to take a signed Android application (APK) and modify it without invalidating the signature, what practical attacks are possible?

What is the risk to a typical Play-store-only user (probably only installing high ranking search results and featured apps in the Play store)?

Some more specific questions:

  • Given a validly signed (maliciously modified) APK, what are the barriers to getting the legitimate Play store version of the app updated with that file?

  • Would a man-in-the-middle attacker (e.g. malicious wifi hotspot) be able to exploit auto update in any way (this might be - are APKs delivered over HTTPS?)

  • They state that a signed app that appears to come from the device manufacturer allows full system access - are these permissions different to the normal Android permissions system? How does it work? Are system updates delivered as APKs and is there any risk here?

  • How much does this help phishing attacks? Presumably a user would still need to enable installation from "unknown sources"?

I appreciate that at this point the full details of the vulnerability are not publicly available*, so I'm looking for answers based on the above quote, and possibly extrapolating additional information from anything else Bluebox have said or from other reputable sources.

* presumably if this bug has been fixed in any publicly released updates, we will very quickly find out what it is from people analysing the deltas in the APK verification area.

Improve this question
2

2 Answers 2

Reset to default
1

The practical exploit is the ability to later substitute different code from that signed, either on an individual basis or wholesale.

The ability to substitute entirely different code, without changing the signature means that the application could undergo rigorous review, and be signed off as a harmless or beneficial application, but the installed version would run an entirely different set of code which had never been reviewed. Yet the signature would be the same, so as far as Android is concerned it is still a trusted application.

Worse, this could be implanted into the device by anyone with physical access without special knowledge. For example, if the APK was stored on an SD card, the SD card could be slipped out, altered, and replaced in minutes. But as far as android is concerned, the signature is the same so it must be the same app.

Improve this answer
1

I would like to add to Ben's comment that the possibility to implant hostile code into what is assumed to be a trusted application does not require physical access, a social engineering attack involving side loading an updated app (for example Maps) from a download is also possible.

Physical access to the device by the attacker is not required if the end user follows (hostile) instructions: they will receive no error message if the vulnerability is easily triggered.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .