The flaw has been dubbed “Fake ID” and exists in all versions of Google’s Android since 2010 (4.4 is not susceptible). Fake ID is pretty much exactly what the name implies: a malicious individual can craft a false id for an application and push it through as if it were something else. Once the malware is on the system it has access to a large number of functions including NFC data, Google Wallet, Contacts and even simply taking over the phone.
According to the information released by Blue Box Security:
“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. “
So far not every manufacturer has pushed out the patch. According to the information we have only Motorola has pushed this patch out to carriers for OTA update. This leaves a lot of phones vulnerable to this bug. To compound the issue it seems that the ID (security certificates) are not being properly validated by the Android Package installer. This is the equivalent of a bouncer at a bar only asking if you have ID, but not actually checking to make sure it is real.
Because of this lack of verification any application can have a fake ID made for it that allows it to act like another app. This Fake ID can allow for some very deep access to system level functions. Blue Box uses the following as an example:
“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”
But wait there is more, an attacker can further exploit the system by allowing multiple signatures on a single application that contains multiple identities. Once the super-spy malware gets in and breaks out of the sandbox (because of this flaw) the game is over for the device. This flaw is present in the Android Base Code (AOSP) so it is a very fundamental flaw in the system. Perhaps Google needs to hire a new crew of bouncers, with the current set they have left the front door open to a lot of people.
As we mentioned earlier Google has pushed out a patch for this and it is in the hands of the manufacturers. The down side of this is that manufacturers can take a long time to verify that a patch will not break their shovelware, many will also hold onto patches until they have a few in hand to reduce releases. Once the manufacturers are done it goes to the carriers who run the whole process all over again before setting up and scheduling a release for OTA update…
For now we would recommend that you avoid installing apps until you know you are patched. Even those running Android 4.4 might want to take things slow until they see an update that covers this. Blue Box Security will be talking about this bug during Black Hat 2014 and we hope to bring you more information then.
Tell us what you think in our Forum
The full release can be found on the next page -
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
