首页
论坛
课程
招聘
[原创]Bluebox Security提报Android 绕过应用签名认证漏洞原理
2013-7-9 15:30 24280

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

2013-7-9 15:30
24280
本文章由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://review.cyanogenmod.org/#/c/45251/
    http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/
    http://cn.engadget.com/2013/07/04/bluebox-reveals-android-security-vulnerability/

[培训] 优秀毕业生寄语:恭喜id咸鱼炒白菜拿到远超3W月薪的offer,《安卓高级研修班》火热招生!!!

收藏
点赞0
打赏
分享
最新回复 (15)
雪    币: 5059
活跃值: 活跃值 (28)
能力值: (RANK:170 )
在线值:
发帖
回帖
粉丝
zmworm 活跃值 4 2013-7-9 16:31
2
0
原理简述

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

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

1. 解析zip的所有Entry,结果存到HashMap(key为路径,value为Entry)。



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



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

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



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


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个或以上相同的路径即抛出异常
上传的附件:
雪    币: 298
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
tedrick 活跃值 2013-7-9 21:40
3
0
前排~~~拜读
雪    币: 417
活跃值: 活跃值 (6484)
能力值: (RANK:350 )
在线值:
发帖
回帖
粉丝
kanxue 活跃值 8 2013-7-9 21:43
4
0
期待~
雪    币: 231
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
阿于 活跃值 2013-7-9 22:42
5
0
前排支持!!!!
雪    币: 386
活跃值: 活跃值 (17)
能力值: ( LV13,RANK:280 )
在线值:
发帖
回帖
粉丝
火翼[CCG] 活跃值 6 2013-7-10 09:44
6
0
支持
雪    币: 1292
活跃值: 活跃值 (1248)
能力值: ( LV12,RANK:490 )
在线值:
发帖
回帖
粉丝
熊猫正正 活跃值 9 2013-7-10 10:04
7
0
学习,老赵也来凑热闹了,哈哈~~
雪    币: 111
活跃值: 活跃值 (78)
能力值: ( LV3,RANK:20 )
在线值:
发帖
回帖
粉丝
netsniffer 活跃值 2013-7-10 10:20
8
0
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>
雪    币: 119
活跃值: 活跃值 (43)
能力值: ( LV4,RANK:50 )
在线值:
发帖
回帖
粉丝
zhangtaopy 活跃值 1 2013-7-10 10:57
9
0
前排广告位招租
雪    币: 111
活跃值: 活跃值 (78)
能力值: ( LV3,RANK:20 )
在线值:
发帖
回帖
粉丝
netsniffer 活跃值 2013-7-10 11:02
10
0
有一点值得说明:
如果只修改classes.dex,不修改androidmanifest.xml,则重启后,新安装的apk(update-system apk)会因为同样的版本号而被删除,所以建议也整两份,dirty_dex里边放一份修改过重新打包生成的AndroidManifest.xml,把orgin_nodex里边原始的AndroidManifest.xml移到orgin_dex里边,这样打包生成的APK才经得起重启的考验。

最终的效果就是apk里的xml和dex都是两份。
雪    币: 264
活跃值: 活跃值 (10)
能力值: ( LV4,RANK:50 )
在线值:
发帖
回帖
粉丝
jaskell 活跃值 1 2013-7-10 15:50
11
0
追本溯源,解释得很清楚。拜读。
雪    币: 40
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
香蕉是我 活跃值 2013-7-11 19:28
12
0
分析得很具体到位,学习。
雪    币: 111
活跃值: 活跃值 (78)
能力值: ( LV3,RANK:20 )
在线值:
发帖
回帖
粉丝
netsniffer 活跃值 2013-7-16 17:30
13
0
感觉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摘要值相同。
雪    币: 2
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
唯心独爱 活跃值 2013-7-26 10:41
14
0
高手!!!!前排支持!!!!!!!!!!
雪    币: 16
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
brucezl 活跃值 2014-1-4 12:38
15
0
这个必须要学习
雪    币: 5
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
牛宝宝 活跃值 2014-2-19 17:04
16
0
学习学习
游客
登录 | 注册 方可回帖
返回