What does Android “master key” vulnerability and your morning coffee Drive Thru routine have in common?
Bluebox Labs last week announced a vulnerability in Android’s code for cryptographic signature verification and app installation. They are planning to publicly disclose the details in their upcoming BlackHat US talk. Google has patched this vulnerability and some of the vendors have already started picking it up.
Understanding the threat
Each app on Android is required to be cryptographically signed by the author. A very common threat vector on Android is trojanizing trusted applications, whereby a malicious party modifies the trusted app and adds malicious functionality to it. Consider for example, that a known trustworthy company GoodGuys publishes a game AwesomeGame and sells it a price.
A malicious group BadBoys can then take that app and add malicious functionality to it, such as stealing user data, calling / sending SMS to toll numbers etc, retain the original game functionality and publish it on third party app store enticing the users to download it as a free pirated copy of AwesomeGame.
To publish it on Google Play BadBoys would have to bypass Google play security checks and even then publish it under a similar sounding / looking name but something other than GoodGuys or would have to have obtained login credentials GoodGuys to log in to their Google play account. On top of it he would need access to GoodGuys private key to sign the trojanized app.
With the vulnerability that BlueBox Labs responsibly disclosed to Google BadGuys can release a trojanized version of AwesomeGame installation file which contains some code that is not signed by GoodGuys, but when Android attempts to install it, it is tricked into thinking that all parts of the app are signed by GoodGuys.
Do you need to worry?
Depending on where you take your apps from you may not have to worry too much, if you follow the best practises and you only install apps from Google play and you pay attention to the author details then you are very very unlikely to be affected by this, as the attacker would have to bypass several security measures to deliver an app from a trusted channel while pretending that it is coming from GoodGuys.
But as I mostly do, I would like to give an analogy to explain the vulnerability.
Recall your drive through experience during your morning commute. in many setups you may have to pass through two windows, the first one is where you pay and the second one is where you pick up your order. The attendant at the second window is pretty sure that you are the one who just paid at the previous window. Now imagine (although it is hard to happen in the decimal world with humans but quite easy in the binary world) if the car behind you were to hit and throw you out of the lane and present itself to the attendant at second window… this is essentially what this vulnerability is about.