New Android 'Fake ID' flaw empowers stealthy new class of super-malware

Posted:
in iPhone edited August 2014
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.

Android Fake ID


Bluebox 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.

Steve Jobs iPhone


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.
«13456

Comments

  • Reply 1 of 103
    22july201322july2013 Posts: 3,705member
    DED never fails to amaze.
  • Reply 2 of 103
    andysolandysol Posts: 2,506member
    Lol

    Sorry, I should have more to contribute. Here it goes.... Hahahaha
  • Reply 3 of 103
    wisdomseedwisdomseed Posts: 141member
    While it sounds menacing, has the exploit actually been found in the wild? I'm never sure where the terror starts, there is a vast difference between 'can/might' and 'did'.
  • Reply 4 of 103
    formosaformosa Posts: 261member
    Quote:
    Originally Posted by AppleInsider View Post



    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.

     

    There's some incredible synergistic irony going on here... Flash + Android (vs. SJ)

  • Reply 5 of 103
    rabbit_coachrabbit_coach Posts: 1,114member

    Ouch!

     

    That must hurt a little.

  • Reply 6 of 103
    addicted44addicted44 Posts: 830member
    22july2013 wrote: »
    DED never fails to amaze.
    true. Android's pathetic security is clearly DED's fault.
  • Reply 7 of 103
    mstonemstone Posts: 11,510member
    Quote:
    Originally Posted by AppleInsider View Post



    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...

     

    I seriously doubt proving SJ wrong was the motivation for embedding Flash. Perhaps an attempt at differentiating Android from iOS. Only fandroids are intent on proving SJ wrong. Google has nothing to gain from trying to embarrass Apple or Steve Jobs. Google actually wants to be on good terms with Apple. They need Apple and iOS.

  • Reply 8 of 103
    MacProMacPro Posts: 19,822member
    22july2013 wrote: »
    DED never fails to amaze.

    Hopefully PED picks this one up for Fortune like he did with the one about the lousy Gartner reports about the sales data for Macs.
  • Reply 9 of 103
    MacProMacPro Posts: 19,822member
    formosa wrote: »
    There's some incredible synergistic irony going on here... Flash + Android (vs. SJ)

    It seems somehow very appropriate that Flash is involved, such Karma!
  • Reply 10 of 103
    MacProMacPro Posts: 19,822member
    mstone wrote: »
    I seriously doubt proving SJ wrong was the motivation for embedding Flash. Perhaps an attempt at differentiating Android from iOS. Only fandroids are intent on proving SJ wrong. Google has nothing to gain from trying to embarrass Apple or Steve Jobs. Google actually wants to be on good terms with Apple. They need Apple and iOS.

    I see what you are trying to say there ... but surely not ripping of iOS in the first place would have been a better way to achieve 'good terms' with Apple?
  • Reply 11 of 103
    acatomicacatomic Posts: 60member
    I need a little bit of help from you guys, there's one thing I don't understand and I'm hoping you can explain it to me. In January I downloaded a free app from the app store which had free movies and cartoons but was later taken down by Apple. Later I got notified by the app that there was an update available but it can only be downloaded from their webpage, so I did and it worked.

    So my question is how is this possible? I thought it was only possible to download apps from the app store store and nowhere else.
  • Reply 12 of 103
    marskmarsk Posts: 30member

    Nice! <img class=" src="http://forums-files.appleinsider.com/images/smilies//lol.gif" />

  • Reply 13 of 103
    chipsychipsy Posts: 287member
    One thing must be cleared up here. Just like Apple's SSL verification issue there is no knowledge of this vulnerability ever actually being used for malicious intend. It's a theoretical danger that is again predominantly a possible issue for sideloaders.
    It of course needs to get fixed.The Play Store's Dynamic Security Provider might be the solution for older devices here.
  • Reply 14 of 103
    MacProMacPro Posts: 19,822member
    acatomic wrote: »
    I need a little bit of help from you guys, there's one thing I don't understand and I'm hoping you can explain it to me. In January I downloaded a free app from the app store which had free movies and cartoons but was later taken down by Apple. Later I got notified by the app that there was an update available but it can only be downloaded from their webpage, so I did and it worked.

    So my question is how is this possible? I thought it was only possible to download apps from the app store store and nowhere else.

    It is up to the software company how they wish to distribute. However in your security settings you do have to option to set the Mac to only download from the App Store or from that and approved web sites. Lastly you can override and download from anywhere, not a good idea. See lower part of the dialog box below. The company must have decided to opt out of Apple's Store for some reason.

    1000
  • Reply 15 of 103
    Quote:

    Originally Posted by WisdomSeed View Post



    While it sounds menacing, has the exploit actually been found in the wild? I'm never sure where the terror starts, there is a vast difference between 'can/might' and 'did'.

    I quite agree with you.  And I might go a step further, because it seems that 9 times out of 10, these theoretical vulnerabilities are found in an Apple platform and the tech press creates a bunch of sound and fury signifying nothing.  I'd be pleased to see Apple Insider document this phenomenon of theoretical threat versus in-the-wild reality.  Today's DED story is like the exception that proves the rule, because in general this phenomenon is used to create anti-Apple FUD.

  • Reply 16 of 103
    cnocbuicnocbui Posts: 3,613member

    So can anyone actually name an instance of this 'super-malware' or is the title perhaps ever so slightly misleading?

  • Reply 17 of 103
    dasanman69dasanman69 Posts: 13,002member
    cnocbui wrote: »
    So can anyone actually name an instance of this 'super-malware' or is the title perhaps ever so slightly misleading?

    I guess you didn't see the word 'potentially' in super duper miniscule fine print.
  • Reply 18 of 103
    acatomicacatomic Posts: 60member
    It is up to the software company how they wish to distribute. However in your security settings you do have to option to set the Mac to only download from the App Store or from that and approved web sites. Lastly you can override and download from anywhere, not a good idea. See lower part of the dialog box below. The company must have decided to opt out of Apple's Store for some reason.

    1000

    I forgot to say that it's not a Mac, it's an iPad and it's not jailbroken.
  • Reply 19 of 103
    chipsychipsy Posts: 287member
    cnocbui wrote: »
    So can anyone actually name an instance of this 'super-malware' or is the title perhaps ever so slightly misleading?
    The title is indeed somewhat misleading as there are no real world examples of this vulnerability being used by malware.
  • Reply 20 of 103
    MacProMacPro Posts: 19,822member
    cnocbui wrote: »
    So can anyone actually name an instance of this 'super-malware' or is the title perhaps ever so slightly misleading?

    To quote the first paragraph...

    "The problem affects virtually all Android phones sold since 2010. Bluebox 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."

    So, I guess the specific names will be up to the creators.
Sign In or Register to comment.