Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

7/29/2014
12:00 AM
Dark Reading
Dark Reading
Products and Releases
50%
50%

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

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Major Brazilian Bank Tests Homomorphic Encryption on Financial Data
Kelly Sheridan, Staff Editor, Dark Reading,  1/10/2020
New Attack Campaigns Suggest Emotet Threat Is Far From Over
Jai Vijayan, Contributing Writer,  1/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: It is too bad the ceiling is made of glass!
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-3686
PUBLISHED: 2020-01-17
openQA before commit c172e8883d8f32fced5e02f9b6faaacc913df27b was vulnerable to XSS in the distri and version parameter. This was reported through the bug bounty program of Offensive Security
CVE-2019-3683
PUBLISHED: 2020-01-17
The keystone-json-assignment package in SUSE Openstack Cloud 8 before commit d7888c75505465490250c00cc0ef4bb1af662f9f every user listed in the /etc/keystone/user-project-map.json was assigned full "member" role access to every project. This allowed these users to access, modify, create and...
CVE-2019-3682
PUBLISHED: 2020-01-17
The docker-kubic package in SUSE CaaS Platform 3.0 before 17.09.1_ce-7.6.1 provided access to an insecure API locally on the Kubernetes master node.
CVE-2019-17361
PUBLISHED: 2020-01-17
In SaltStack Salt through 2019.2.0, the salt-api NEST API with the ssh client enabled is vulnerable to command injection. This allows an unauthenticated attacker with network access to the API endpoint to execute arbitrary code on the salt-api host.
CVE-2019-19142
PUBLISHED: 2020-01-17
Intelbras WRN240 devices do not require authentication to replace the firmware via a POST request to the incoming/Firmware.cfg URI.