Android FakeID(Google Bug 13678484) 漏洞详解

开始

继上一次Masterkey漏洞之后，Bluebox在2014年7月30日又公布了一个关于APK签名的漏洞——FakeID，并打算在今年的Blackhack上公布更详细的细节，不过作者Jeff Forristal在文中已经给出了不少提示，另外申迪的《FakeID签名漏洞分析及利用》也做了相关介绍。由于其中涉及的知识点较多，所以有部分朋友估计还没有看明白，所以我打算写一篇更详细漏洞分析解说，希望对大家有帮助。

基础概念

在分析之前，有几个基础概念需要普及一下的：

APK包中的MF、SF和RSA文件

完成签名后的APK包中，会多出一个叫META-INF的文件夹，一般情况下会包含MANIFEST.MF、CERT.SF和CERT.RSA三个文件（在多证书签名的情况下，就不止一个RSA文件）：

• MF文件中包含APK的包信息，如manifest文件的版本、签名版本、应用程序的相关属性以及包中所有源文件的SHA1值。
• SF文件则是在MF文件的基础上，采用SHA1withRSA签名算法进行签名的明文文件。
• RSA文件则是APK文件的签名证书，这个文件是一个PEM格式保存的PKCS7公钥证书，PKCS7证书一般会分开两个文件，一个是公钥证书，另一个则是私钥证书，有PEM和DER两种编码方式。PEM比较常见，是纯文件的形式，一般用于分发公钥证书。

其中RSA文件，则是FakeID漏洞利用的关键，下面会详细介绍。

证书链结构及认证原理

一般情况下，我们平时发布的Android应用都是采用自签名的方式，所谓自签名是指公钥证书中Issuer（发布者）和Subject（所有者）是相同的，比如Adobe Flash Player的签书信息如下所示：

所有者: CN=Adobe Systems Incorporated, OU=Information Systems, O=Adobe Systems Incorporated, L=San Jose, ST=California, C=US
发布者: CN=Adobe Systems Incorporated, OU=Information Systems, O=Adobe Systems Incorporated, L=San Jose, ST=California, C=US
序列号: d7cb412f75f4887e
有效期开始日期: Thu Oct 01 08:23:14 CST 2009, 截止日期: Mon Feb 16 08:23:14 CST 2037

除了通过自签名的方式，我们还可以采用由CA颁发私钥证书进行签发。采用这种方式，最终APK中的公钥证书中，就会包含证书链。这种方式跟签名名的主要区别是最终的公钥证书中，Issuer和Subject是不相同的，而且会存在多于一个证书，证书与证书之间是通过Issuer与Subject进行关联的，Issuer负责对Subject进行认证，下面是证书的验证示意图：

判断一个证书链是否有效，是一个递归的过程，下面是一个三级证书的验证示意图：

Android对APK的合法性验证

前面说到，当APK是非自签名时，APK中存在证书链。当安装APK时，