开始
继上一次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时,