Security researchers have identified a critical vulnerability in all versions of Android devices, from 2.1 to 4.4, that deals with how apps are signed. Bluebox Security dubbed the flaw Fake ID; in the same way an underage person might use a fake ID to gain access to a bar, the vulnerability could allow a malicious app to trick the Android security model into believing it is a trusted application and then grant it access to special privileges.
Although Google made changes to how app permissions are displayed, those permissions are still visible if users take the time to check. But most people don’t dig around into the digital certificate that signed the app; it happens without any user notification. Yet this trusted digital signature says who built the app and that it's legit. It is what determines who can update the app, what apps can share data, and any special privileges granting the app access to functionality.
Apps are trusted by their digital certificate of authenticity chain and Fake ID exploits that Android security model. Bluebox Security chief technology officer Jeff Forristal explained, “The Android package installer makes no attempt to verify the authenticity of a certificate chain; in other words, an identity can claim to be issued by another identity, and the Android cryptographic code will not verify the claim (normally done by verifying the issuer signature of the child certificate against the public certificate of the issuer).”
For example, an attacker can create a new digital identity certificate, forge a claim that the identity certificate was issued by Adobe Systems, and sign an application with a certificate chain that contains a malicious identity certificate and the Adobe Systems certificate. Upon installation, the Android package installer will not verify the claim of the malicious identity certificate, and create a package signature that contains both the certificates. This, in turn, tricks the certificate-checking code in the webview plugin manager (who explicitly checks the chain for the Adobe certificate) and allows the application to be granted the special webview plugin privilege given to Adobe Systems – leading to a sandbox escape and insertion of malicious code, in the form of a webview plugin, into other applications.
Besides inserting a Trojan into an app to impersonate Adobe, an attacker could exploit Fake ID in order to impersonate Google Wallet and gain access to NFC financial and payment data. By impersonating 3LM, an attacker could take “full management control of the entire device.”
“The problem is further compounded by the fact that multiple signers can sign an Android application (as long as each signer signs all the same application pieces).” According to Bluebox, “This allows a hacker to create a single malicious application that carries multiple fake identities at once, taking advantage of multiple signature verification privilege opportunities to escape the sandbox, access NFC hardware used in secure payments, and take device administrative control without any prompt or notification provide to the user of the device.”
“You could use any app distribution mechanism, whether it’s a link in SMS or a legitimate app store. Look at other Android malware. You do it whatever it takes for the user to say, Yeah I want that app,” Forristal said. “It’s certainly severe. It’s completely stealth and transparent to the user and it’s absolutely the stuff that malware is made of. It operates extremely consistently, so in that regard it’s going to be extremely attractive to malware.”
Of about 6,300 Android device models, Bluebox researchers have tested about 40. Forristal said the vulnerability dates back "to the January 2010 release of Android 2.1" and affects "all devices that are not patched for Google bug 13678484." Google made changes in Android 4.4, or KitKat, which closed the hole in the case of Adobe, but KitKat devices are still vulnerable to Fake ID.
Although Google cooked up a generic code fix in April and provided the patch to the Android phone manufacturers, those manufacturers need to include that fix into a firmware update and give it to wireless carriers. Then the carrier must push the firmware update that includes a fix for the Fake ID vulnerability out to Androids. In other words, Google may have fixed the flaw but that doesn’t mean your Android is patched and safe.
As far as Bluebox knows, only one vendor has patched the Fake ID hole. Now that the details about the security flaw are in the wild, it is only a matter of time before some cyber-thug decides to actively exploit it.
So when you drill down to the nitty gritty, what you really want to know is if your phone is vulnerable. If you install the Bluebox Security Scanner app and it shows that your Android is vulnerable to Bug 13678484 (Fake ID), then it suggests to “ask your phone carrier and/or device vendor for update.”
Beneath that advice, there is a link for “Can Bluebox provide me vendor contact info?” Don’t hold your breath because the answer you will see is captured in the screenshot on the right:
Google indicates there are 6,300 known Android devices (as of July 2014). Each one of those has a separate fix. As you can imagine, it is not practical for Bluebox to try to track update information for that many devices. You know who you got your phone from, and you know who your carrier is – so use whatever customer support means they offer to inquire about an update.
Forristal will present more technical details and demonstrate the exploit against a live device at Black Hat when Bluebox presents "Android FakeID Vulnerability Walkthrough."