Android "FakeID" security hole causes a pre-BlackHat stir

library
crime | hacking | security

Mobile control company Bluebox has created a bit of a pre-BlackHat stir about Android insecurity for the second year in a row.

Last year it was the cheekily-named “MasterKey” vulnerability; this year it’s FakeID.

Bluebox isn’t saying too much at this point, not least because it has a talk coming up next week at BlackHat 2014.

In today’s highly competitive, multi-stream commercial conference world, it’s perfectly understandable to keep the details under your hat so paying delegates get to see them first.

It also means there isn’t a proof-of-concept exploit floating around already, which is a relief.

Certificate chains

I hope I’m not oversimplifying here, but what Bluebox is calling “FakeID” happens because Android’s checking of what’s known as an app’s certificate chain is perfunctory.

Sufficiently perfunctory, in fact, that a rogue app can apparently get more privileges than it deserves simply by saying that someone trustworthy has vouched for it

We’ve explained the concept of a digital “chain of trust” before in the wake of various SSL certificate fiascos.

Very loosely speaking, I sign something for my users with a digital certificate, and you sign my signature (and someone else can sign yours, and so on) until the chain of signatures reaches a certificate belonging to someone my users already trust.

It’s vaguely like giving references when you apply for a job: if your interviewer trusts your referees, and your referees trust you, then your interviewer is inclined to trust you, too.

Different trust levels

As Bluebox points out, in Android, some digital certificates imbue more trust than others.

The company gives examples such as Adobe’s imprimatur being used to approve apps to act as plugins for other apps; and the blessing of the Google Wallet signature being used to authorise an app to access the NFC hardware.

→ NFC stands for Near Field Communication, a form of RFID commonly used for point-of-sale payments.

So far, so good, except Bluebox notes that the way Android actually verifies those certificates is not actually cryptographic; it’s just text matching, verifying that they certificates say they come from a particular issuer.

That’s a bit like verifying job applicants’ references simply by looking at the names they’ve written in their application, rather than by phoning up the referees and checking that the applicant is telling the truth.

In short, a rogue app could get more privileges than it deserves simply by saying it deserves them.

Google has a patch, but, as always, actually getting it onto Android devices in the real world is going to be a challenge.

Lots of users are still a long way behind, and many couldn’t update even if they wanted to, being reliant on their vendor or mobile provider to push out fixes.

What next?

As usual, a decent Android anti-virus and security product will help you weed out rogue developers and apps, regardless of how bold their claims of trustworthiness might be.

And sticking to the Google Play Store as far as you can will reduce the risk further.

We don’t for a moment buy Google’s braggadocio that the Play Store’s security validation is the “best review possible,” as security head honcho Adrian Ludwig has been publicly stating.

But Google’s claims aside, the Play Store does provide a decent level of security scrutiny, and has historically been much safer than many alternative markets out there.

As for the details of Bluebox’s analysis of this bug, watch this space.

Sophos’s Chester Wisniewski, of Chet Chat podcast fame, will be attending BlackHat 2014, and I’ll be interviewing him next week in a special edition of the Chet Chat, right from the conference.