Mobile & Wireless

Android “Fake ID” Vulnerability Lets Malicious Apps Impersonate Trusted Apps

A serious vulnerability exists in the Android operating system, which could allow malicious apps to impersonate well-known trusted apps such as Google Wallet, researchers said.

<p><span><span><strong>A serious vulnerability exists in the Android operating system, which could allow malicious apps to impersonate well-known trusted apps such as Google Wallet, researchers said. </strong></span></span></p>

A serious vulnerability exists in the Android operating system, which could allow malicious apps to impersonate well-known trusted apps such as Google Wallet, researchers said.

Every Android app has a unique identity, and a flaw in the operating system dating back to 2010 lets malicious apps copy and adopt these identities without the user knowing anything about it, Jeff Forristal, CTO of Bluebox Security, told SecurityWeek. Forristal, along with Bluebox Labs, the company’s research team, will be presenting details of the “Fake ID” bug at next week’s Black Hat security conference in Las Vegas.

The Fake ID vulnerability dates back to Android 2.1 released January 2010 and is present in every version of Android since then, Forristal said. Even though Android is currently at version 4.4 (KitKat), the fragmented state of the Android ecosystems means a significant number of Android devices are running older versions of the operating system, and thus are vulnerable, he warned.

“Essentially anything that relies on verified signature chains of an Android application is undermined by this vulnerability,” Forristal said.

How Fake ID Can be Abused

Malicious apps can insert a Trojan into a legitimate app using the webview plugin by using the Adobe identity, Forristal said. Once inserted, an attacker could have control of the compromised app, access to all of its data, and be able to do anything the app can do. All devices prior to KitKat are vulnerable to the Adobe System webview plugin privilege escalation, according to Bluebox Labs. KitKat is immune because of the way the webview component was implemented.

Attackers can also gain access to near-frequency communications (NFC) chip and financial and payment data associated with the chip by impersonating Google Wallet, Forristal said.

Even scarier, the malicious app can take full management control of the entire Android device by impersonating 3LM. The 3LM identity is associated with device administration extensions supported by various handset manufacturers, including HTC, Pantech, Sharp, Samsung, Sony Ericsson, and Motorola.

Advertisement. Scroll to continue reading.

Undermining Certificates

Android apps tend to use PKI identity certificates to sign and verify data to confirm its legitimacy. App signatures establishe who can update the apps and what other apps can access the app’s data. The Android identity follows a similar model to HTTPS/SSL, with a certificate issued by a certificate authority for a specific app. Specific identies are given higher, specialized privileges, such as Google Wallet’s access to NFC hardware. Vendor-specific mobile device administration capabilities also have special identities, as well. The privileges are hard coded into the base code, according to Bluebox Labs.

On an Android system, the digital certificate used to sign an Android application become the application’s package signature and is accessible to other applications via an API, Bluebox Labs said. The package installer doesn’t verify the authenticity of the certificate chain, which means an app can claim an identity issued by a different issuer and the installer won’t cryptographically verify the signature to determine its legitimacy, Forristal said.

Fake ID is even more serious when considered that an app can use multiple identities. There’s no reason to think that attackers will just pick an identity for attack, when they can create a single malicious app with multiple identities and try out all the attacks to see which one succeeds, Forristal said.

According to a compnay spokesperson, Bluebox informed the Android security team of the problem with all of the technical details and confirmation of its research by March 31. “The Android security team verified the problem, and developed a fix in early April and provided the fix to OHA partners in early April, under an informal 90-day coordination release plan,” the spokesperson said.

In July 2013, Bluebox Researchers uncovered a serious vulnerability in Android which allowed attackers to modify apps without affecting the cryptographic signature and easily turn legitimate apps into Trojans. Dubbed the  Android “Master Key” vulnerability, the flaw lets a malicious author trick Android into believing an app is unchanged even if it has been.

Related Reading: Android Flaw Lets Attackers Convert Legitimate Apps into Trojans

Related Reading: TowelRoot Vulnerability Could Lead to Attacks on Android Devices

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version