Bluebox Security提报Android 绕过应用签名认证漏洞原理

标题: 【原创】Bluebox Security提报Android 绕过应用签名认证漏洞原理

作者: jiazhijun

时间: 2013-07-09,15:30:06

链接: http://bbs.pediy.com/showthread.php?t=175129

本文章由Jack_Jia编写，转载请注明出处。

文章链接：http://blog.csdn.net/jiazhijun/article/details/9280995

作者：Jack_Jia

邮箱：309zhijun@163.com

一、漏洞描述

安全公司 Bluebox Security 日前声称，他们在 Android 系统中发现了可能会对 99% 设备造成影响的漏洞。按照其说法，这个漏洞自 Android 1.6（Donut）以来就一直存在，恶意软件制作者可以在不破解加密签名的前提下利用它来修改合规 APK 的代码，可以绕过android应用的签名验证安全机制。

二、影响设备

理论上会影响android1.6至漏洞提报google时间点2013-02之间的所有设备。

三、漏洞原理

1、恶意APK如何在不修改应用签名情况下绕过android签名验证机制。

漏洞修复前后比对：（luni/src/main/java/java/util/zip/ZipFile.java）

在漏洞修复前Android未考虑到APK压缩文件中的重复entryName问题，这样恶意软件制作者就可以制作特定的APK包绕过Android APK包证书认证。

恶意APK软件包包含两个entryName="classes.dex"的文件,对应的数据分别为malicious.data和org.data，且malicious.data在压缩包字典中位于org.data之前。

由于APK解析中，当entryName相同时，后者会覆盖前者信息，这样就能顺利通过APK证书签名验证过程。

2、插入malicious.data绕过Android APK包证书验证后，如何工作呢？

android apk包经过验证合格后，就需要通过请求installed进程完成代码的优化。进过优化后的代码才是APP程序运行时加载的代码。

dex优化在dalvik2\dexopt\OptMain.cpp完成。

OptMain.cpp对apk压缩文件的处理是通过dalvik2\libdex\ZipArchiver.cpp来完成的。

通过分析ZipArchiver.cpp代码，底层对APK包解析可以存在相同entryName的文件而不会覆盖，且当根据文件名classes.dex提取压缩内容时，总是返回第一个名字匹配的数据，这样我们的插入的malicious.data就成了真正优化的代码。

经过以上两步，整个漏洞利用也就完成了。(以上逻辑暂未本人实际验证)

四、POC代码

开源POC:https://gist.github.com/poliva/36b0795ab79ad6f14fd8

http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/

http://cn.engadget.com/2013/07/04/bluebox-reveals-android-security-vulnerability/

原理简述

由于ZIP格式允许存在两个或以上完全相同的路径，而安卓系统没有考虑这种场景。在该情况下，android包管理器校验签名取的是最后一个文件的hash，而运行APK加载的dex文件却是zip的第一个dex文件。

包管理器验证签名验的是最后一个（名字相同情况下）文件。

1. 解析zip的所有Entry，结果存到HashMap（key为路径，value为Entry）。

zip Entry HashMap

2. 由于HashMap.put在相同key的情况下，会把value更新，导致上述的HashMap在相同路径下，存储的一定是最后一个文件的Entry。

Entry

系统加载dex文件，加载的是第一个dex。

1. 查找dex的Entry用的是dexZipFindEntry。

dexZipFindEntry

2. dexZipFindEntry的实现是只要match就返回，所以返回的都是第一个文件。

dexZipFindEntry

CyanogenMod的修复原理

原代码：

for (int i = 0; i < numEntries; ++i) {
    ZipEntry newEntry = new ZipEntry(hdrBuf, bin);
    mEntries.put(newEntry.getName(), newEntry);
}

修补后：

for (int i = 0; i < numEntries; ++i) {
    ZipEntry newEntry = new ZipEntry(hdrBuf, bin);
    String entryName = newEntry.getName();
    if (mEntries.put(entryName, newEntry) != null) {
        throw new ZipException("Duplicate entry name: " + entryName);
    }
}

关键代码为if (mEntries.put(entryName, newEntry) != null) {

该put为HashMap的put，key不存在返回null，反之返回原值。也就是说APK的Entry链存在2个或以上相同的路径即抛出异常

CyanogenMod的修复代码

相关内容：

Android uncovers master-key 漏洞分析

Bluebox Security提报Android 绕过应用签名认证漏洞原理

相关讨论：

netsniffer 2013-07-10, 10:20:54

LZ的工具不错，简洁大方得体，使用ant 直接可以输出修改过的apk。

美化一下build.xml, 用法直接在build.xml同目录下执行ant

<?xml version="1.0" encoding="UTF-8"?>
<project name="MyProject" default="dist" basedir=".">
<target name="dist">
  <zip destfile="evil.apk" duplicate="add">
    <fileset dir="orgin_nodex\\"/>
    <fileset dir="dirty_dex\\"/>
    <fileset dir="orgin_dex\\"/>
  </zip>
</target>
</project>

netsniffer 2013-07-10, 11:02:04

有一点值得说明：

如果只修改classes.dex，不修改androidmanifest.xml，则重启后，新安装的apk(update-system apk)会因为同样的版本号而被删除，所以建议也整两份，dirty_dex里边放一份修改过重新打包生成的AndroidManifest.xml，把orgin_nodex里边原始的AndroidManifest.xml移到orgin_dex里边，这样打包生成的APK才经得起重启的考验。

最终的效果就是apk里的xml和dex都是两份。

jaskell 2013-07-10, 15:50:33

追本溯源，解释得很清楚。拜读。

香蕉是我 2013-07-11, 19:28:43

分析得很具体到位，学习。

netsniffer 2013-07-16, 17:30:58

感觉odex的ROM有问题

其apk中META-INFO中.MF文件中记录的是未优化前的classes.dex的SHA1摘要

如：

Name: classes.dex

SHA1-Digest: F9o6D322lANlgD/JIE2txB8p4kQ=

我们有什么办法能从.odex还原成原始未优化前的classes.dex，试了几次从odex中提取出dex，

但发现SHA1摘要不匹配，谁能解释下怎么还原原始的classes.dex，SHA1摘要值相同。

文章目录