Jar Bug 13678484 / Android FakeID

转载 2015年11月20日 15:26:26

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.


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 vulnerable to Fake ID, but not specifically to the Adobe System webview plugin 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.

Status of Vulnerability Fix:

Effectively addressing a vulnerability requires a three step process:
1)  Google produces a generic code fix, which it provides to the Android phone manufacturers
2)  Then phone manufacturers must then incorporate that fix into a firmware update suitable to specific phones, which they provide to carriers
3)  The carrier then distributes the final update, which ensures your phone is safe from the vulnerability
As regards Fake ID, Google has provided the generic code fix to the phone manufacturers.  Currently the manufacturers and carriers are working to get that fix out to you.  The Bluebox Security Scanner will help you track when that finally happens.  Alternatively, you can contact customer support for your phone manufacturer or carrier for the more current and up-to-date status for your specific Android phone.

Install the Bluebox Security Scanner to see if you’ve been exposed to this vulnerability.

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.

July 31 Updates to our original FakeID blog post
  • We have confirmed multiple vendors have already released, or are in the process of releasing, patches to the ecosystem.  This can take time, please be patient as updates get rolled out.  Not all devices by a vendor may be updated, and not all geographies may be updated at the same time.
  • Special note: there is no single, specific “fixed” version of Android.  In fact, multiple vendors are maintaining the same prior version number, and only patching the functionality.  We have confirmed “fixed” versions existing within the ranges of 4.1, 4.2, 4.3, and 4.4.  Do not expect your Android version number to necessarily change; instead, rely on the free Bluebox Security Scanner to inform you when the patch has arrived.
  • We have noticed some devices need manual involvement to check for system updates.  Go to Settings -> About -> System Updates and manually trigger an update check.  Some devices may include the system update check in a different location, you may need to search around for the functionality.
Correction:  Our prior statement about Android L-preview being vulnerable was incorrect.  We based our statement on the review of code in the l-preview branch of the AOSP code repository, and the presence of the vulnerable code in JarUtils.  Google Android Security Team members provided us insight that Android L fixes the vulnerability in a different way, i.e. in a different code location, so the presence of the prior-vulnerable code in JarUtils is a red herring.  We’ve updated the free Bluebox Security Scanner to correctly check the patch status of Android L devices using this different fix approach.  Thank you to Josh Armour of the Android Security Team for cooperatively helping us include correct scanning of Android L devices.

Android FakeID(Google Bug 13678484) 漏洞详解

继上一次Masterkey漏洞之后,Bluebox在2014年7月30日又公布了一个关于APK签名的漏洞——FakeID,并打算在今年的Blackhack上公布更详细的细节,不过作者Jeff Forr...
  • L173864930
  • L173864930
  • 2014年08月07日 12:45
  • 16360

FakeID签名漏洞分析及利用(Google Bug 13678484)

作者:申迪   转载请注明出处: http://blogs.360.cn/360mobile BlueBox于7月30日宣布安卓从2010年以来一直存在一个apk签名问题[1],并且会在今...
  • u011240877
  • u011240877
  • 2015年12月08日 11:01
  • 934

Android FakeID任意代码注入执行漏洞简析

博文作者:金刚项目团队发布日期:2014-09-01阅读次数:100博文内容:u  漏洞背景 国外安全机构BlueBox在2014年7月30日公布了一个关于APK签名的漏洞——FakeID,攻击者可利...
  • jiazhijun
  • jiazhijun
  • 2014年09月02日 19:25
  • 8615


转自CSDN《程序员杂志》         作者:火点,三金 7月30号,新闻又爆出Bluebox安全研究团队发布的安卓新的签名漏洞 “假 ID”,除了最新的4.4版本,几乎所有安卓设备都有此漏洞,本...
  • android_squad
  • android_squad
  • 2014年12月01日 21:48
  • 1856


大家好,我很少原创,只因太菜,最近在研究微信api,说到这先讲一个笑话: 话说西蜀刘备去世之后,托孤阿斗于诸葛孔明,孔明为报知遇之恩,兴师北伐中原。临行之前对阿斗说:“陛下聪慧机智,才艺超群,但...
  • ligboy
  • ligboy
  • 2013年04月30日 14:55
  • 2527


  • wengedexiaozao
  • wengedexiaozao
  • 2018年03月07日 16:09
  • 24

用Android studio 生成jar包--->亲测可用

1.新建library类型的module 2.将libs加入当前的项目依赖 3.生成classes.jar文件 在as Terminal输入命令 ./gradle...
  • tiankongcheng6
  • tiankongcheng6
  • 2017年12月06日 11:48
  • 182

Android 源码系列之<十七>自定义Gradle Plugin,优雅的解决第三方Jar包中的bug<上>

  • llew2011
  • llew2011
  • 2017年11月15日 15:00
  • 925


腾讯Bugly 官网传送门BugTags官网传送门网易云捕官网传送门
  • wtt945482445
  • wtt945482445
  • 2017年05月23日 21:19
  • 385


CPPAlien的专栏 . [原]从Installer直接打开应用程序会出现Android系统bug 问题现象: 用Android系统自带的Installer安装完应用后,会有以下两...
  • Ln_ZooFa
  • Ln_ZooFa
  • 2015年12月14日 15:08
  • 1390
您举报文章:Jar Bug 13678484 / Android FakeID