首页
论坛
课程
招聘
[原创]Bluebox Security最新提报Android漏洞的初步探讨(已确认不是同一个问题,详见正文后的补充说明)
2013-7-6 17:04 19805

[原创]Bluebox Security最新提报Android漏洞的初步探讨(已确认不是同一个问题,详见正文后的补充说明)

2013-7-6 17:04
19805
转载请注明出处:http://www.blogjava.net/zh-weir/archive/2013/07/06/401270.html

Bluebox Security最新提报Android漏洞的初步探讨

    Bluebox Security在7月3号的时候,在官网上发布了一个据称99% Android机器都有的一个漏洞。国内最早在4号开始有媒体报道,并持续升温。该漏洞可使攻击者在不更改Android应用程序的开发者签名的情况下,对APK代码进行修改。并且,这个漏洞涉及到从1.6版本至今全部的Android版本,换句话说,这4年中生产的9亿设备,即当今市场上99%的Android产品都面临这一问题。

    看到这样的报道,一开始我和我的小伙伴们都不敢相信。因为签名机制用了这么多年,多少大脑袋厚眼镜的天才们想要颠覆都没搞定,Bluebox Security怎么可能搞定的呢?不过,由于好奇心驱使,我开始查看Bluebox Security官方的说法:《UNCOVERING ANDROID MASTER KEY THAT MAKES 99% OF DEVICES VULNERABLE》,我意识到,这个问题应该不是签名机制本身的问题,而是Android安装APK过程中的校验存在漏洞。

    如果是APK安装校验签名的漏洞,而这个Bug又从1.6开始就有,那也太伤我自尊了。出于某种嗜好,俺怎么着也是从1.5起就对包管理充满了浓厚兴趣,2011年还写了一篇《Android APK 签名比对》的文章,里面对Android签名机制做了稍详细的解析。不过回过头来一想,Google Android负责包管理的工程师估计更伤自尊了,当然这是后话。

    在将信将疑的感情中,迎来了一个休息两天的周末。于是我开始翻翻包管理的代码,跟着APK安装流程往下看。以前一直有个地方让我觉得google工程师真的这么重视效率吗?结果今天一看,发现好像存在问题。大家来评评:



    安装应用的时候包管理检查签名不知检查了多少次,在这里针对系统应用却只检查manifest.xml一个文件的签名。Google Android工程师真的是为了效率么?不管怎样,他一定是深思熟虑之后的结果,因为这里有段注释:“If this package comes from the system image, then we can trust it... we'll just use the AndroidManifest.xml to retrieve its signatures, not validating all of the files.”(所以如果真是这段代码导致的漏洞,他真伤自尊了...)

    事实上,大多数时候安装一个APK对于Android来说是一个复杂的过程,这个过程中Google为了安全做了很多冗余的事情。但是结合Bluebox Security的漏洞描述,我联想到一种情况。那就是开机过程中扫描安装/system/app中的应用时!基于这个想法,我自己鼓捣了一会儿,发现按这个逻辑往下还真能绕过签名认证!当然,还有一些令人扫兴的附加操作,例如需要root权限以对/system/app下的文件进行读写操作。

    这里我贴一下我的操作步骤吧。
  
    (先声明:我所描述的不一定是Bluebox Security最近宣称的漏洞,只是一种系统应用修改代码而绕过Android签名校验的方法。Bluebox Security所描述的漏洞据官网消息称,将由Bluebox的CTO Jeff Forristal,在本月27号到8月1号的拉斯维加斯美国黑帽安全大会上讲话时,公布具体的技术细节并放出相应的工具和资料

1、好吧,我以MIUI ROM中的系统应用FileExplorer为例(切记这是99% Android手机都有的漏洞,MIUI是无辜的)。

2、找一台刷了MIUI的手机,先将它从/system/app抠出来。(这个apk我们暂且称作APK_ORG)

3、使用apktool工具(或者其他类似工具)将FileExplorer.apk反编译。apktool需要安装MIUI的Framework资源包,详查百度。

4、修改smali代码,想怎么改怎么改,这里我只是在onCreate的时候打印了一个Log。

5、将smali及其他文件再打包成apk文件。(这个apk我们成为APK_DIST)

(前面的步骤和一般破解的步骤都差不多, 后面就不一样了。)

6、将APK_ORG做zip包解压,取出其中META-INF文件夹和AndroidManifest.xml文件。

7、将尚未签名的APK_DIST用WinRAR打开,将APK_ORG中取出的META-INF文件夹和AndroidManifest.xml文件拖入APK_DIST中。

(OK,apk包做好了!)

8、将APK_DIST命名为FileExplorer.apk(与手机中文件管理器名字相同)。

9、adb push APK_DIST 到 /system/app/  下,覆盖原来的APK_ORG。

到此为止,大功告成了!如果系统没有更新应用,可以重启一下手机。结果发现文件管理器安装成功,自己添加的Log正常打印,之前在APK_ORG时登录的网盘(快盘),数据都在且能正常使用。

  
总结:这段代码应该是从1.6之后就一直是这样,因此符合Bluebox Security所说的99% Android手机都存在此漏洞。但是我现在发现的漏洞需要手动root之后才能操作出来,且只针对system app,与Bluebox Security所描述的情况有所出入。也许是同一个漏洞,不同的操作方式,也许不是同一个漏洞,或者这个压根不算漏洞。希望这篇文章起到抛砖引玉的作用,呼吁国内Android安全人员和手机厂商一起加入探讨~ (哦,对了,我直接把这个apk放到官方ROM中会怎么样?文章发布后,再试试~ ^-^)
   
   
转载请注明出处:http://www.blogjava.net/zh-weir/archive/2013/07/06/401270.html

-----------------------------------------------------------------------------------------------------

更新补充说明:

目前已确认本文所述问题与bluebox所说的漏洞不是同一个问题。大家可以继续研究,但是与bluebox所称的漏洞无关。

bluebox所述漏洞编号:ANDROID-8219321。

Insertion of arbitrary code without changing package signature due to incorrect parsing of APKs (update to previous bulletin)
First published: March 4th, 2013
Last Updated: May 31st, 2013
ID: ANDROID-8219321
Severity: High
Affected Android Versions: all

由于可能涉及保密问题,更多信息在我确认允许公布后才能公布。现在可以说的是,确实是对apk包进行处理,无需操作权限。可能不是Google本身的问题,上传应用商店后下载即可直接安装。我没研究过这部分代码,因为以为它是不会出问题的。。。

最后想说,出问题的代码就一句话。。。

第五届安全开发者峰会(SDC 2021)议题征集正式开启!

收藏
点赞0
打赏
分享
最新回复 (35)
雪    币: 944
活跃值: 活跃值 (5563)
能力值: (RANK:350 )
在线值:
发帖
回帖
粉丝
kanxue 活跃值 8 2013-7-6 17:15
2
0
感谢ZhWeir再次与大家分享心得 。
这个99%炒的是蛮热的,希望看到更多的分析和讨论。
雪    币: 442
活跃值: 活跃值 (23)
能力值: ( LV9,RANK:260 )
在线值:
发帖
回帖
粉丝
ZhWeir 活跃值 6 2013-7-6 17:44
3
0
呵呵,最近闲下来了,正好看到这个新闻,就研究了下。
雪    币: 34607
活跃值: 活跃值 (151689)
能力值: (RANK:10 )
在线值:
发帖
回帖
粉丝
linhanshi 活跃值 2013-7-6 17:51
4
0
雪    币: 350
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
大小人物 活跃值 2013-7-6 17:51
5
0
拜读了,帖子很容易让人理解。如果真是那段代码导致的 工程师真伤自尊了,哈哈
雪    币: 264
活跃值: 活跃值 (10)
能力值: ( LV4,RANK:50 )
在线值:
发帖
回帖
粉丝
jaskell 活跃值 1 2013-7-6 18:03
6
0
支持原创。非常有价值。
雪    币: 0
活跃值: 活跃值 (10)
能力值: ( LV7,RANK:100 )
在线值:
发帖
回帖
粉丝
wdynasty 活跃值 1 2013-7-6 18:15
7
0
支持楼主!建议继续深挖!比较system/app属于read-only,需要root!
android对高富帅的控制不严格 应该算是漏洞!另外如果是这样的漏洞,影响力肯定比blue吹的要小的多了。
听说S4已经用了新代码,建议dump比对!
雪    币: 0
活跃值: 活跃值 (10)
能力值: ( LV7,RANK:100 )
在线值:
发帖
回帖
粉丝
wdynasty 活跃值 1 2013-7-6 18:16
8
0
支持!!!!!!!!!!!!!!
雪    币: 201
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
fjhgx 活跃值 2013-7-6 18:44
9
0
雪    币: 0
活跃值: 活跃值 (10)
能力值: ( LV7,RANK:100 )
在线值:
发帖
回帖
粉丝
wdynasty 活跃值 1 2013-7-6 18:57
10
0
你看看能否push到data/app,如果安装成功,那就大功告成!
雪    币: 5059
活跃值: 活跃值 (28)
能力值: (RANK:170 )
在线值:
发帖
回帖
粉丝
zmworm 活跃值 4 2013-7-6 22:08
11
0
http://www.blackhat.com/us-13/briefings.html
blackhat上对这个漏洞的说明,标题是亮点:

ANDROID: ONE ROOT TO OWN THEM ALL
This presentation is a case study showcasing the technical details of Android security bug 8219321, disclosed to Google in February 2013. The vulnerability involves discrepancies in how Android applications are cryptographically verified & installed, allowing for APK code modification without breaking the cryptographic signature; that in turn is a simple step away from system access & control. The vulnerability affects a wide number of Android devices, across generations & architectures, with little to no modifications of the exploit. The presentation will review how the vulnerability was located, how an exploit was created, and why the exploit works, giving you insight into the vulnerability problem and the exploitation process. Working PoCs for major Android device vendors will be made available to coincide with the presentation.

PRESENTED BY

Jeff Forristal
雪    币: 386
活跃值: 活跃值 (17)
能力值: ( LV13,RANK:280 )
在线值:
发帖
回帖
粉丝
火翼[CCG] 活跃值 6 2013-7-6 23:08
12
0
这个必须要顶,加油看源码去了
雪    币: 114
活跃值: 活跃值 (16)
能力值: ( LV5,RANK:60 )
在线值:
发帖
回帖
粉丝
gamehacker 活跃值 1 2013-7-6 23:24
13
0
惊现CCG大神啊
雪    币: 322
活跃值: 活跃值 (113)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
高军 活跃值 2013-7-6 23:54
14
0
继续围观!!!
雪    币: 386
活跃值: 活跃值 (17)
能力值: ( LV13,RANK:280 )
在线值:
发帖
回帖
粉丝
火翼[CCG] 活跃值 6 2013-7-7 10:42
15
0
4.X源码截图

这么写应该是为了加快系统启动速度,root后的安全毕竟不是Google要优先考虑的事情
从这个角度考虑也能理解为什么google并不是很care这个问题
上传的附件:
雪    币: 40
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
香蕉是我 活跃值 2013-7-7 15:46
16
0
很有道理,和S4比对一下
雪    币: 11
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
virtualabc 活跃值 2013-7-8 10:34
17
0
雪    币: 1781
活跃值: 活跃值 (46)
能力值: ( LV9,RANK:370 )
在线值:
发帖
回帖
粉丝
fosom 活跃值 8 2013-7-8 10:44
18
0
顶一个,,,,,,,,,,。
雪    币: 46
活跃值: 活跃值 (12)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
司马相如 活跃值 2013-7-8 15:30
19
0
被看雪学院微信召唤过来的。虽然看的一头雾水,不过还是要来膜拜大神。
雪    币: 885
活跃值: 活跃值 (34)
能力值: ( LV12,RANK:310 )
在线值:
发帖
回帖
粉丝
yuansunxue 活跃值 6 2013-7-8 15:40
20
0
学习 学习
雪    币: 298
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
tedrick 活跃值 2013-7-8 17:14
21
0
竟然不是我一直认为的rooted不校验,难道是包dalvik溢出?还能实现伪装包签名覆盖啊?
mark下~等具体文档~~~好神奇
雪    币: 1407
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
liangdong 活跃值 2013-7-8 17:57
22
0
https://jira.cyanogenmod.org/browse/CYAN-1602
雪    币: 111
活跃值: 活跃值 (75)
能力值: ( LV3,RANK:20 )
在线值:
发帖
回帖
粉丝
netsniffer 活跃值 2013-7-8 21:05
23
0
很显然是为了提高启动速度,如果每一个zip entry都校验,开机就不是几十s到1分钟了,就是N分钟了
这个并不算漏洞,试问,如果没root,谁能往/system/app下push apk。
完全是那个机构的噱头,博取眼球的。
雪    币: 111
活跃值: 活跃值 (75)
能力值: ( LV3,RANK:20 )
在线值:
发帖
回帖
粉丝
netsniffer 活跃值 2013-7-8 21:14
24
0
这个原理不少做ROM的人都清楚,
他们为了不修改原生ROM签名,不破坏原ROM各apk之间的shareuserid关系,
就不动APK中的META-INFO/*.RSA|*.SF|*.MF,
转而改代码(classes.dex)、图片、资源等除了AndroidManifest.xml以外的资源。

但也有很多第三方ROM是全部重签名的,如MIUI等;甚至有一些ROM Maker很懒,
连自己的签名都懒得弄,直接用AOSP代码build中的自带的签名,这很危险,
因为谁都可以把自己的APK用AOSP原生签名签一下,再shareuserid到uid.system,
这样就可以申请platform签名保护的权限了,甚至可以把自己放到system_server里边去运行,
这些ROM的用户因此而悲催了。
雪    币: 22
活跃值: 活跃值 (21)
能力值: ( LV3,RANK:20 )
在线值:
发帖
回帖
粉丝
tewilove 活跃值 2013-7-8 22:12
25
0
以下是阅读源代码之后的猜想,没有证明。

1. libdex的zip实现
分配一个大数组,对entry求hash,冲突项顺次放到hash位置之后
2. framework的ZipFile实现
使用一个HashMap存放entry

绕过签名的方法:
例如常见的修改class.dex,制作一个含有两个同名的class.dex的zip文件(普通工具无法制作)。
按照entry的顺序,第一个是修改过的class.dex,第二个是原本的class.dex。

原理:
校验签名的时候是用的framework的ZipFile实现,由于HashMap后者覆盖前者,故校验的时候用的是正确的class.dex,通过。
而后dexopt的时候,直接寻找class.dex那个entry,故使用的是第一个,也就是修改过的class.dex。
这样就bypass了android的签名校验机制。
游客
登录 | 注册 方可回帖
返回