There is a critical vulnerability in millions of Android devices that allows a malicious app to impersonate a trusted application in a transparent way, enabling an attacker to take a number of actions, including inserting malicious code into a legitimate app or even take complete control of an affected device.
The vulnerability is a result of the way that Android handles certificate validation and it’s present in all versions of Android from 2.1 to 4.4, known as Kit Kat. Researchers at Bluebox Security, who identified the vulnerability, said that in some cases, attackers can exploit the vulnerability to gain full access to a target device. Specifically, devices that run the 3LM administration extension are at risk for a complete compromise. This includes devices from HTC, Pantech, Sharp, Sony Ericsson, and Motorola.
Android apps are signed using digital certificates that establish the identity of the developer and the vulnerability Bluebox discovered is that the Android app installer doesn’t try to authenticate the certificate chain of a given app. That means an attacker can create an app with a fake identity and impersonate an app with extensive privileges, such as an Adobe plug-in or Google Wallet. In the case of the Adobe impersonation, the malicious app would have the ability to escape the sandbox and run malicious code inside another app, the researchers said.
“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,” the Bluebox researchers said in a post explaining their discovery.
“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.”
In an interview, Jeff Forristal, CTO of Bluebox, said that there are a number of ways for an attacker to exploit this vulnerability, a bug that he called severe. Forristal will discuss the vulnerability in a presentation at Black Hat in Las Vegas next week.
“You could use any app distribution mechanism, whether it’s a link in SMS or a legitimate app store. Look at other Android malware. You do it whatever it takes for the user to say, Yeah I want that app,” he said. “It’s certainly severe. It’s completely stealth and transparent to the user and it’s absolutely the stuff that malware is made of. It operates extremely consistently, so in that regard it’s going to be extremely attractive to malware.”
Another target for an attacker exploiting the vulnerability could be Google Wallet. An attacker could create an app that has the signature of the device’s nfc_access.xml file, which is normally the signature of Google Wallet, and the app would then be allowed to access the NFC chip in the device. That portion of the hardware stores the payment information used in NFC payments via Google Wallet. NFC (near field communications) enables short-range wireless communication and is used in a number of electronic payment applications.
Forristal said Bluebox worked with Google to address this vulnerability and Google released a patch to its partners in April. However, it’s up to the carriers themselves to push the updates to users.
