A new Android design error discovered by Bluebox Security allows malicious apps to grab extensive control over a user's device without asking for any special permissions at installation. The problem affects virtually all Android phones sold since 2010.
calls the flaw "Fake ID" because it allows malware apps to pass fake credentials to Android, which fails to properly verify the app's cryptographic signature. Instead, Android grants the rogue app all of the access permissions of whatever legitimate app the malware claims to be.
This is particularly serious because Google has granted a variety of trusted apps in Android broad permissions; by pretending to be one of these trusted apps, malware can can fool users into thinking that they are installing an app that doesn't need any special permissions, then trick the system into giving it essentially full control of the device, with access to the user's financial data, contacts and other private information, even data stored in the cloud.
Bluebox said it disclosed the flaw to Google three months ago. The company's chief technology officer Jeff Forristal will detail how it was found and how it works in a presentation at BlackHat USA 2014, a security conference being held next week in Las Vegas.
Fake ID can exploit Flash to infect other apps
Among the trusted apps that can be spoofed by Fake ID is Adobe Flash, which Google deeply integrated into Android's web browser in an attempt to prove that Steve Jobs was wrong about Flash not being a good idea on mobile devices.
While Google eventually gave up on Flash for Android, an Adobe Flash plugin privilege escalation flaw remained embedded in Android's webview--the browser component that gets embedded into third party apps that present web content--until the release of Android 4.4 KitKat last fall.
With Flash so deeply integrated into Android's webview component, any malware using Fake ID to pretend to be Flash can subsequently escape Android's app sandbox and take control of other apps, including Salesforce and Microsoft OneDrive, grab data from those apps, sniff out all those apps' network traffic and gain any additional privileges held by those apps. Android Open Source Project forks including Amazon's Fire OS and various packages used in China are also susceptible to Fake ID
Google removed the Android webview Flash flaw from 4.4 KitKat last fall, but as of July 7, the company reports that less than 18 percent of its users have installed the new version.
The remaining 82 percent often can't update because of well known issues with mobile carriers and manufacturers delaying or opting not to deliver an update.
Google itself decided it wasn't worth it to offer a KitKat update to buyers of its Galaxy Nexus, despite the phone being less than two years old. Outside of Google Play, Android Open Source Project forks including Amazon's Fire OS and various packages used in China are also susceptible to Fake ID.
Flash not required: Fake ID can spoof NFC, too
In addition to the broad Flash permissions that Google hardwired into Android, the company has also built into Android support for its own Google Wallet, tied to NFC payment data.
Using Fake ID, a malware app that asks the user for no special permissions at installation can subsequently pretend to be the Google Wallet app; Android will then provide the rogue app with all the permissions it gave its own NFC infrastructure, which includes users' financial data.
Another vector for exploit is 3LM, a MDM (mobile device management) package Google inherited when it acquired Motorola (and later abandoned). However, Bluebox noted that "various HTC, Pantech, Sharp, Sony Ericsson, and Motorola devices" incorporate Android 3LM code, enabling Fake ID to allow "partial or full device compromise by malware."
Fake ID lets any app pretend to be any app
Bluebox added, "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."
Because Wallet, 3LM and other apps do not depend on the Flash / Android webview flaw, these other vectors of attack weren't fixed in KitKat. That means Fake ID affects all versions of Android, including the latest Android 4.4.4 and the upcoming "Android L" (aka Android 5.0 beta).Fake ID affects all versions of Android, including the latest Android 4.4.4 and the upcoming "Android L"
Google is expected to develop a patch for Fake ID, and it can attempt to scan for malware in Google Play to protect users from malware attempting to exploit the majority of Android users who likely won't see timely updates from their carrier or hardware vendor.
However, that still leaves wide open the "side loading" method of installing apps from other app markets, such as Amazon and the variety of stores operating overseas, including China, where Google maintains little control over Android.
Like Apple's iOS app signatures, without the verification part
Android apps are signed using the digital certificates of their developer, just like Apple's iOS introduced in 2008.
Once cryptographically signed, an app can be verified as genuine by the system; any subsequent tampering (such as the addition of malicious viral code) will break the signature, allowing the system to refuse to run the app.
However, Bluebox discovered that "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). "the Android package installer makes no attempt to verify the authenticity of a certificate chain" - Bluebox
"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 company added, "you can see for yourself in the createChain() and findCert() functions of the AOSP [Android Open Source Project] 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."
There's also another complication. "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)," Bluebox noted.
"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."
Fake ID bears some similarity to the SSL flaw found to affect Apple's iOS and OS X in February; in both cases, the encryption chain could be bypassed to allow malicious access to data.
Exploiting Apple's SSL vulnerability required an attacker with shared network access and the ability to create forged certificates matching the type of encrypted traffic a user was actively transmitting. Apps using Fake ID can be mass produced and distributed to Android users as innocuous games or free security tools, making it much easier to find and exploit victims with little effort.
Android's looking a lot like Windows
Last summer, Forristal presented a similar security flaw in Android which Bluebox dubbed "Master Key," as it allowed an app's code to be modified without breaking its signature.
While the flaw was subsequently exploited by malware makers within a month, it was "hard for malware to use in a stealthy way," Forristal told AppleInsider in a briefing."The Android malware ecosystem is beginning to resemble to that which surrounds Windows" - F-Secure Labs
On the other hand, Fake ID requires no user involvement, and can be used by malware posing as an innocent app or game that requests no special permissions. Once installed, the app can take over without the user having any knowledge of being infected.
Malware began rapidly evolving for Android in 2012, but gained new sophistication and reach last year as "highly specialized suppliers" began to "provide commoditized malware services" specifically targeting weaknesses in the Android platform, as researchers at F-Secure Labs noted in early 2013.
"The Android malware ecosystem is beginning to resemble to that which surrounds Windows," the firm observed. By September, Duo Security stated that "more than half of Android devices are vulnerable to at least one of the known Android security flaws."
In April, Symantec reported that mobile malware authors had 'almost exclusively' focused on Android.
Earlier this year, inexpensive "Android RAT," or Remote Administration Tool packages began to appear for as little as $300.
The RAT is designed to tack malware payloads onto original or stolen Android apps, and then obscure the malicious code in order to evade detection by Google's Bouncer scanning process used to detect malware code in apps submitted to Google Play.
Differing approaches to security by iOS and Android
Apple and Google have expressed very different approaches to designing their mobile software. Earlier this year, Apple released a whitepaper on iOS security that noted, "when we set out to create the best possible mobile OS, we drew from decades of experience to build an entirely new architecture.
"We thought about the security hazards of the desktop environment, and established a new approach to security in the design of iOS. We developed and incorporated innovative features that tighten mobile security and protect the entire system by default. As a result, iOS is a major leap forward in OS security."
As a result, Apple has rapidly gained adoption among corporate and government users while Google hasn't.
Earlier this month, Apple and IBM announced a partnership to further promote Apple's products in the enterprise with new suites of business apps exclusive to iOS.