The majority of Android devices currently in use contain a vulnerability that allows malware to completely hijack installed apps and their data or even the entire device.
The core problem is that Android fails to validate public key infrastructure certificate chains for app digital signatures, said Jeff Forristal, chief technology officer of Bluebox Security, a San Francisco company whose researchers discovered the issue.
According to Google’s documentation, Android applications must be signed in order to be installed on the OS, but the digital certificate used to sign them does not need to be issued by a digital certificate authority. “It is perfectly allowable, and typical, for Android applications to use self-signed certificates,” the documentation says.
However, Android contains hard-coded certificates from several developers so it can give apps created by those developers special access and privileges inside the OS, Forristal said.
One such certificate belongs to Adobe and gives apps signed by it, or by certificates issued by it, the power to inject code into other installed apps. Forristal believes this behavior exists to allow other apps to use Adobe’s Flash Player plug-in.
A typical certificate chain validation process would use cryptography to check the signature relationships between all certificates in the chain. A certificate chain can contain intermediary certificates, so the system would start by validating if the certificate used to sign the app was indeed signed by the next certificate in the chain. Then it would validate whether that certificate was signed by the next one, and so on, until reaching the trusted Adobe certificate.
According to Forristal, Android does not do that, so an attacker can sign a malicious app with a certificate that appears to be signed by the hard-coded Adobe certificate, but actually isn’t. As long as the Adobe certificate is present in the app’s certificate chain, the system will take code from the app and inject it into other installed apps, Forristal said.
The injected code essentially becomes part of the other apps, inheriting their permissions. It has access to all data stored by those apps, it can see their network traffic and can perform all actions that those apps are authorized to perform on the device, he said.
The attack can only be used to hijack apps that use the WebView component on Android versions older than 4.4, known as KitKat. WebView is a feature commonly used by apps to display Web content using the browser engine built into Android.
In Android KitKat, the WebView component is based on the Chromium open-source browser and no longer supports this plug-in code injection, Forristal said.
Even so, the attack affects a large number of users. According to Google’s statistics from the beginning of July, around 88 percent of devices that use Google Play run Android versions older than 4.4.
“It is very, very easy for malware to use this attack—it is silent, transparent, with no notifications to users,” Forristal said. The malicious app doesn’t need any special permissions. It just needs to contain WebView code inside of it, which it can actually download after installation, he said.
Abusing the Adobe certificate is also not the only possible attack vector, as Android has at least two other hard-coded certificates that grant applications special access.
One is a certificate for mobile device management technology developed by a company called 3LM that was acquired in early 2011 by Motorola Mobility, before Google acquired Motorola Mobility.
The 3LM device management extensions are not part of the Android Open Source Project (AOSP), but are included in various devices that were produced and shipped by Sony, HTC, Motorola, Samsung, LG and a couple of other smaller manufacturers, Forristal said.
Any application with the 3LM certificate in its certificate chain can use the device management extensions to silently install new apps, change system settings and take control of the device, he said.
Finally, a third hard-coded certificate is used by Google Wallet and provides access to the hardware-based NFC (near-field communication) secure element that’s used to store sensitive information like credit card numbers during payment processing.
The Bluebox security researchers didn’t have time to analyze the impact of this attack vector in detail, but its mere existence likely violates the Android security model for the NFC secure element, Forristal said.
The certificate chain validation vulnerability, which Bluebox has dubbed Fake ID, was reported to Google in April and a patch was made available to device manufacturers, according to Forristal.
“After receiving word of this vulnerability, we quickly issued a patch that was distributed to Android partners, as well as to AOSP,” a Google representative said Tuesday via email. “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.”
Motorola has released updates with the patch for some devices and more vendors will probably do the same over the coming weeks, Forristal said.
However, due to the fragmentation of the Android ecosystem, update availability and delivery vary widely between different manufacturers and carriers. Some affected devices are most likely not even supported anymore and will never receive a patch for this issue.
Bluebox has released a free application that can check whether a device is vulnerable to the fake ID attacks.
Forristal plans to discuss the vulnerability in more detail during a presentation at the Black Hat security conference in Las Vegas next week.