Android Fake ID Vulnerability Lets Malware Impersonate Trusted Applications, Puts All Android Since January 2010 At Risk
Every Android application has its own unique identity, typically inherited from the corporate developer’s identity. The Bluebox Security research team, Bluebox Labs, recently discovered a new vulnerability in Android, which allows these identities to be copied and used for nefarious purposes.
Dubbed “Fake ID,” the vulnerability allows malicious applications to impersonate specially recognized trusted applications without any user notification. This can result in a wide spectrum of consequences. For example, the vulnerability 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 financial and payment data by impersonating Google Wallet; or take full management control of the entire device by impersonating 3LM.
Implications
This is a widespread vulnerability dating back to the January 2010 release of Android 2.1 and affecting all devices that are not patched for Google bug 13678484, disclosed to Google and released for patching in April 2014. All devices prior to Android 4.4 (“KitKat”) are vulnerable to the Adobe System webview plugin privilege escalation, which allows a malicious application to inject Trojan horse code (in the form of a webview plugin) into other apps, which leads to taking control of the entire app, all of the apps’s data, and being able to do anything the app is allowed to do. Android 4.4 is specifically immune due to a change in the webview component (the switch from webkit to Chromium moved away from the vulnerable Adobe-centric plugin code).
Users of devices from specific vendors that include device administration extensions are at risk for a partial or full device compromise by malware. The 3LM device extensions (temporarily owned by Motorola and Google) are present in various HTC, Pantech, Sharp, Sony Ericsson, and Motorola devices – and are susceptible to the vulnerability as well.
Other devices and applications that depend upon the presence of specific signatures to authenticate an application may also be vulnerable. Essentially anything that relies on verified signature chains of an Android application is undermined by this vulnerability.
How it works:
Android applications are typically cryptographically signed by a single identity, via the use of a PKI identity certificate. The use of identity certificates to sign and verify data is commonplace on the Internet, particularly for HTTPS/SSL use in web browsers. 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. Again, this is how HTTPS/SSL works – a specific web site SSL certificate may be issued by a certificate authority such as Symantec/Verisign. The web site SSL certificate will be “issued” by Verisign, and Verisign’s digital identity certificate will be included with the website certificate. Effectively, the web browser trusts any certificate issued by Verisign through cryptographic proof that a web site SSL certificate was issued by Verisign.
Android applications use the same certificate signature concepts as SSL, including full support for certificates that are issued by other issuing parties (commonly referred to as a “certificate chain”). 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 (such as those in PackageManager).
Application signatures play an important role in the Android security model. An application’s signature establishes who can update the application, what applications can share it’s data, etc. Certain permissions, used to gate access to functionality, are only usable by applications that have the same signature as the permission creator. More interestingly, very specific signatures are given special privileges in certain cases. For example, an application bearing the signature (i.e. the digital certificate identity) of Adobe Systems is allowed to act as a webview plugin of all other applications, presumably to support the Adobe Flash plugin. In another example, the application with the signature specified by the device’s nfc_access.xml file (usually the signature of the Google Wallet application) is allowed to access the NFC SE hardware. Both of these special signature privileges are hard coded into the Android base code (AOSP). On specific devices, applications with the signature of the device manufacture, or trusted third parties, are allowed to access the vendor-specific device administration (MDM) extensions that allow for silent management, configuration, and control of the device.
Overall, this is an appropriate use of digital signatures in a system that supports the notion of PKI digital certificate identities. However, Bluebox Labs discovered a vulnerability that has been relatively present in all Android versions since Android 2.1, which undermines the validity of the signature system and breaks the PKI fundamental operation. 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 the both 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.
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). 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.
For the PKI & code savvy, you can see for yourself in the createChain() and findCert() functions of the AOSP JarUtils class – there is a conspicuous absence of cryptographic verification of any issuer cert claims, instead defaulting to simple subjectDN to issuerDN string matching. An example of the Adobe Systems hardcoded certificate is in the AOSP webkit PluginManager class.
How to get more details:
Technical details of the issue, and related tools/material, will be released as part of my Black Hat USA 2014 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 and you can track this information via @BlueboxSec
