Bluebox Security, a mobile security company, has found a serious Android security hole that dates all the way back to Android 2.1. This hole, Fake ID, can be used by malware to impersonate trusted applications without any user notification.
Can you say bad news? I knew you could.
By enabling malware to act like already approved, high-level programs, Bluebox claims that Fake ID "can be used by malware to escape the normal application sandbox and take one or more malicious actions: insert a Trojan horse into an application by impersonating Adobe Systems; gain access to NFC [Neat Field Communication] financial and payment data by impersonating Google Wallet; or take full management control of the entire device by impersonating 3LM." Ironically, 3LM is part of an Android enterprise security system.
Bluebox is not exaggerating. This security hole has the potential to be a major problem. This hole exists in all versions of Android from 2.1, Eclair, to 4.3.1, Jelly Bean. It's not present in Android 4.4.x, KitKat.
Here's the good news: Google has patched the hole and it hasn't been exploited yet.
A Google spokesperson said, "We appreciate Bluebox responsibly reporting this vulnerability to us; third party research is one of the ways Android is made stronger for users. After receiving word of this vulnerability, we quickly issued a patch that was distributed to Android partners, as well as to AOSP [Android Open Source Project]. Google Play and Verify Apps have also been enhanced to protect users from this issue. At this time, we have scanned all applications submitted to Google Play as well as those Google has reviewed from outside of Google Play and we have seen no evidence of attempted exploitation of this vulnerability."
So how did this hole open? According to Bluebox, every Android application has its own unique cryptographic identity. This is in the form of a public key infrastructure (PKI) certificate, which incorporates its corporate developer’s identity.
So far so good. Bluebox explained, "As part of the PKI standard, an identity certificate can have a relationship with another identity certificate: a parent certificate ('issuer') can be used to verify the child certificate. On an Android system, the digital certificate(s) used to sign an Android application become the application’s literal package “signature”, which is accessible to other applications via normal application meta-data APIs [application programming interfaces]."
Here's where it gets tricky.
This application signature, according to Bluebox, "establishes who can update the application, what applications can share its data, etc." And, some "signatures are given special privileges in certain cases." For example, some signed applications can act as a webview plug-in, allow access to the NFC hardware, or even "allow for silent management, configuration, and control of the device."
That's still fine... so long as you can trust the signature system. It turned out, you couldn't. Bluebox found that the Android package installer makes no attempt to verify the authenticity of a certificate chain.
So, if a malware writer creates an app with a forged digital identity certificate, Android doesn't try to make sure it's really from the vendor it claims it is by checking the forged issuer signature against the real developer's public certificate.
So, with a forged digital identity certificate, an attacker's application can use the legal app's special privileges. Worse still, "multiple signers can sign an Android application (as long as each signer signs all the same application pieces). 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."
To avoid Fake ID attacks, follow the steps I outlined above. If you're stuck with a device with an older version of Android, bug your vendor to release a fix as soon as possible. While no one has used this security hole in the wild yet, it's only a matter of time until someone does.