[There is an Update to this article: See the end of the post below]

Something that could affect 900 million people in a bad way is more than enough incentive for me to stop the presses on a nearly-completed article, and begin a new one two days before deadline.

What caused my radical turnabout? The Android vulnerability that tech-news outlets are all fired up about, even though it’s something only super-crypto geeks truly comprehend. Terms like Master Key, APK, and cryptographic signature are scattered throughout the technical reports I “attempted” to understand; but the only thing I got for my effort was a headache.

Then I found the source of my consternation, a blog post by Jeff Forristal, CTO of Bluebox Security, titled “Uncovering Android Master Key that Makes 99% of Devices Vulnerable.” It starts out:

The Bluebox Security research team — Bluebox Labs — recently discovered a vulnerability in Android’s security model that allows a hacker to modify APK code without breaking an application’s cryptographic signature, to turn any legitimate application into a malicious Trojan, completely unnoticed by the app store, the phone, or the end user.

Got all that? Well, I didn’t. So, I asked the folks at Bluebox Security what the heck was going on — is my Android phone safe or not?

Expecting answers late Friday afternoon was awfully bold on my part, but Katherine Nellum of Lewis PR adroitly arranged for me to talk to Adam Ely, cofounder and COO of Bluebox. Don’t let the C-level title fool you, Adam is a seasoned IT-security expert recognized as one of the top 25 security influencers of  2012.

Cryptographic signature

My first request of Adam was to explain what a cryptographic (digital) signature was, and what role it played. I wondered out loud if it was similar to a cryptographic hash. Many of us use hashes as a way to ensure software we download has not been altered. Adam told me that a signature was similar, but offered more security options. As you can see in the slide below (courtesy of StackExchange.com). 

The StackExchange.com website offered the following definitions:

  • Integrity: Can the recipient be confident that the message has not been modified?

  • Authentication: Can the recipient be confident that the message originates from the sender?

  • Non-repudiation: If the recipient passes the message and the proof to a third party, can the third party be confident that the message originated from the sender?

So, an application’s cryptographic signature ensures that the application has not been altered, that it came from the responsible developer, and nothing happened to the application while it resided in the app store. Yet, Bluebox found a way to alter an application’s code without raising any alarms. Jeff’s post explains: “The vulnerability involves discrepancies in how Android applications are cryptographically verified and installed, allowing for APK code modification without breaking the cryptographic signature.”

There’s that term APK again. It stands for Application PacKage file, a file format similar to Window’s MSI — simply put, the application installation package. Jeff continues:

“All Android applications contain cryptographic signatures, which Android uses to determine if the app is legitimate, and to verify that the app hasn’t been tampered with or modified. This vulnerability makes it possible to change an application’s code without affecting the cryptographic signature of the application — essentially allowing a malicious author to trick Android into believing the app is unchanged even if it has been.”

So the app’s code can be internally altered, and we are none the wiser.

Bad guy options

It seems that malicious coders have two methods to get malicious working apps loaded on to Android phones. They can create a replacement app that is coded to do their bidding, making it look like an update for an already-installed application:

“The vulnerability found by Bluebox bypasses those security constraints (cryptographic signature), allowing a malicious application to update existing applications, access existing application data, and in certain circumstances (in the case when the app is platform-signed) allow the application to be granted immediate system UID access.”

The second method has the bad guys building a malicious version using an application already in the app store, changing only what is required to get past the app store entrance requirements; maybe replacing an uppercase O with a 0 in the app’s name. What the bad guys are hoping for is that someone will mistakenly download their application instead of the official one. And because of the vulnerability, Android will still load the application on the victim’s smartphone.

If my explanations seem “tongue in cheek” vague, well, they are. Adam and Bluebox Security have been working hard preparing for Black Hat 2013 where Jeff will be giving a talk (Android: One Root to Own Them All) about this very subject:

“Technical details of the issue, and related tools/material, will be released as part of my talk. During the talk, I will review the bug, including how it was found, and how it works. After the talk, we will post a follow-up post to our blog with a link to materials from the talk.”

Adam was kind enough to give us an advance peek at what Jeff is going to present.

Google has released a fix

I have written (too many times now) about Android’s number one issue: the completely inadequate update system currently employed. Android is up to version 4.2 (released November 2012); it wasn’t all that long ago that AT&T rolled out version 4.1 to my phone. I don’t know if the problem is with device manufacturers or mobile-telco providers; I just wish the delivery process would get fixed.

Case in point: According to Adam, Google has been exemplary in their handling of this issue. Bluebox Security approached Google in February of this year; and within a week, Google sent a representative to Bluebox Security to discuss the problem and thereafter had a solution within a month. It is now July, and a very real vulnerability is “alive and well in the digital wild” and it shouldn’t be a concern.

What are our options?

There is some good news; Google is now checking applications being uploaded to Play for the Master Key vulnerability. But — and it’s a but that the bad guys are counting on — there are other ways to load applications. Adam explains:

“Google has claimed to taken steps to ‘inoculate’ Google Play for this problem due to Bluebox’s disclosure of the problem. However, the practical reality is the Google Play is not the only app store used by the Android ecosystem. Markets such as Amazon, GetJar, SlideME, etc. also service large amounts of the Android population.”

Please do not forget about sideloading; it will, I suspect, become the primary focus for bad guys, simply because it avoids any vetting by app stores. So, what happens if I absolutely need to load an application from an app store other than Play?

There’s an app for that

Because the team at Bluebox Security is fully aware of the update issue, they created Bluebox Master Key Security Scanner. Jeff provides the details:

“The Bluebox Security Scanner app produced by our research team allows you to directly check if your Android device has been patched for this vulnerability without the hassle of having to contact the device manufacturer or mobile carrier.  It will also scan devices to see if there are any malicious apps installed that take advantage of this vulnerability.”

The app is available for free at Google Play, Amazon AppStore for Android, and GetJar.

The first slide shows a mobile device that is unaffected by the vulnerability:

The next slide shows one that has issues:

Businesses and BYOD

I’m not sure to what extent this will affect BYOD, but those in charge of mobile devices and network security need to be aware of the problem. Adam offered a few suggestions:

  • Push out an email to your Android user community with this link and have them immediately download and run the scanner. Make sure they provide the results back to you. If an update has not been made for specific devices, then give consideration to suspending them from your BYOD program.

  • Make an amendment to your BYOD policy that restricts your users from using any app stores outside of Google Play and your own internal enterprise app store. You can add in other app stores into your policy once they have expressly confirmed how they have addressed identifying the “master key” vulnerability.

Final thoughts

The “Master Key” vulnerability needs to be eliminated, and fast. People have enough going on, without worrying about the validity of their Android applications. It may seem like overkill, but I’m going to run the Bluebox scanner frequently just for peace of mind.

I’d like to thank Jeff and Adam of BlueBox Security for their help. I will update this post if Jeff’s Black Hat talk sheds any new light.

 Update (16 Jul 2013):

Jon Oberheide of DuoSecurity sent an email today, informing me they had developed a fix:

ReKey is the result of an ongoing research collaboration between Northeastern University’s SecLab research group and Duo Security. It is a mobile app for the Android platform that, in essence, takes the upstream patch from Google and deploys it in a safe and non-destructive manner on your device. The end result is that Android users are able to immediately protect their Android phone from the ‘Master Key’ vulnerabilities, without having to wait on security updates from their mobile carrier.

There is a small catch, right now the mobile device has to be rooted (unlocked for ReKey to work. You can get ReKey at Google Play.