Android签名漏洞-编程知识

1. 什么是签名漏洞

Android证书签名漏洞，是指攻击者可以在不改变原APK的签名情况下修改APK的代码，从而绕过Android的签名认证安全机制。通过植入恶意代码的到仿冒的App中，就可替代原有的App做下载、更新。

正常情况下，开发者发布了一个应用，该应用一定需要开发者使用他的私钥对其进行签名。恶意攻击者如果尝试修改了这个应用中的任何一个文件（包括代码和资源等），那么他就必须对APK进行重新签名，否则修改过的应用是无法安装到任何Android设备上的。

2. MasterKey漏洞

2.1. 背景

这个漏洞是由国外的一家安全公司Bluebox Security在2013年7月初揭露的，这个漏洞自Android1.6版本就一直存在，漏洞的覆盖范围达到99%。

2.2. 影响范围

理论上会影响2013年5月以前的android系统，大概是4.3之前的android，大概可以控制95%以上的Android手机。

2.2. 原理

该漏洞位于luni/src/main/java/java/util/zip/ZipFile.java目录下，具体的漏洞点如下：

for (int i = 0 ; i < numEntries; ++i)

{

ZipEntry newEntry = new ZipEntry (hdrBrf , bin) ;

m.entries.put (newEntry.getname() , newEntry )

}

同一个文件夹内是不允许存在两个同名文件的，然而在APK这样一个ZIP格式的文件中却没有这样的限制，同时Android并未对APK中的重名文件进行检测，即一个APK压缩文件中可能存在两个相同的classes.dex文件。

此时可以假设一种情况，一个APK压缩包中存在两个classes.dex文件，第一个是恶意的执行文件，第二个是原来的执行文件，Android系统实际上验证的是第二个执行文件，因此可以顺利绕过APK的签名验证。Java层对APK验证完后，会请求installed进程完成代码的优化，而提取的classes.dex文件却是第一个执行文件。
其他变种可参考：学习Android三个签名漏洞_安卓签名漏洞-CSDN博客

漏洞是如何工作的？

要安裝 APK时，Android会检查其凭证。主要的 function 是 ZipFile 的 mEntries struct。而当读取解析APK(实际是ZIP文件)时, 系统会寻找 Zip Central Directory Entry，以Name(APK中的文件名)当成map的key, 依序放置LinkedHashMap中。当Name(文件名)发生碰撞时，LinkedHashMap会回传旧的值，并以新的值取代。因此检测凭证时，解析到两个dex文件，第二个dex文件会覆盖第一个dex文件，进行证书校验时校验的还是第二个dex文件，也就是原始的classes.dex，通过此方式绕过签名验证。但Apk执行的却是第一个classes.dex。

3. Janus签名与校验漏洞

3.1. 背景

Google在2017年12月份披露了一个名为“Janus”的安全漏洞（漏洞编号：CVE-2017-13156），该漏洞可以让攻击者绕过安卓的签名校验机制（signature scheme V1签名机制），进而可以对应用进行篡改（apk代码篡改）。安卓的部分安全机制是建立在签名和校验的基础上的，故这个漏洞会给搭载安卓系统的设备造成很大的危害，这个漏洞可以在篡改apk内容的情况下，保持apk的签名不发生变化，那么这就会使得用户在下载到安装这个过程中，设备中的安全软件发现不了它是一个被篡改的恶意盗版应用。

如果恶意攻击者利用Janus漏洞，那么恶意攻击者就可以任意地修改一个APK中的代码（包括系统的内置应用），同时却不需要对APK进行重新签名。换句话说，用这种方式修改过的APK，Android系统会认为它的签名和官方的签名是一致的，但在这个APK运行时，执行的却是恶意攻击者的代码。恶意攻击者利用这个修改过的APK，就可以用来覆盖安装原官方应用（包括系统的内置应用）。由此可见，该漏洞危害极大，而且影响的不仅是手机，而是所有使用Android操作系统的设备。

3.2. 影响范围

安卓5.0到8.0系统以及基于V1签名机制的app均Janus漏洞影响；基于V2签名的App则不受影响。从安卓7.0开始系统就已经支持了V2签名，那么7.0的安卓系统安装了含有V2签名的app不会受到此漏洞的影响。

3.3. 原理

安卓应用程序代码逻辑主要是以DEX文件格式存放。此DEX格式文件以文件名classes.dex,classes2.dex等与其他应用程序所需文件一起压缩存放于APK格式的文件里。

Android操作系统在安装一个应用软件时，会将DEX文件转化成OAT文件，负责转化任务的程序叫dex2oat 。安卓操作系统会将APK文件直接给dex2oat程序。

而dex2oat有这样一套逻辑：如果给它的是APK文件，它会把classes.dex文件从APK文件里取出再转化成OAT文件。如果给它的是DEX文件，它直接把DEX文件转化成OAT文件。

如果一个既是APK格式文件又是DEX格式文件的文件，给dex2oat程序会怎样呢？以下是程序判断逻辑：

dex2oat通过IsZipMagic函数和IsDexMagic函数来决定这是什么格式的文件。

再来看看IsZipMagic函数和IsDexMagic函数的实现：

所以dex2oat程序是依据前文件的前4个字节决定这是什么格式文件。然而根据APK格式，前两个字节可以不是‘P’和‘K’，也就是说这里对APK格式的判断并不严谨。事实上一个既满足APK格式要求又满足DEX格式要求的文件是可以构造出来的。

漏洞个发现者发布的图片所示：

暂且把这个DEX格式文件与APK格式文件合体之后产生的文件叫做DEXAPK文件。

当DEXAPK文件在被安卓操作系统安装时，包管理器的代码会把它当作APK格式文件，而dex2oat会把它当作DEX格式文件。安卓应用程序的签名验证是包管理器做的，程序运行加载的OAT文件是由dex2oat根据输入的DEX格式文件生成的。

攻击者可以利用Janus漏洞，将一个恶意DEX与源APK进行拼接，构造一个DEXAPK文件，从而既可以通过安装程序时系统对APK文件的签名认证，又包含攻击者想要运行的程序逻辑。Android系统运行时会将当前的APK文件看作是之前应用的合法升级版并允许安装，最终通过
“升级”植入用户设备执行恶意DEX代码。

解决方法：

添加了对ZIP格式文件，也就是APK格式文件的头部校验，保证头部的4字节确定是LocalFileHeader的Signature，此Signature就是以‘P’和‘K’开头，这时候dex2oat就只会把给它的文件当作APK格式文件了。