To build a better world !

Bluebox Security最新提报Android漏洞的初步探讨(及后续跟踪分析)

转载请注明出处: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中会怎么样?文章发布后,再试试~ ^-^)

   
关于ANDROID-8219321漏洞的后续补充说明。没有后续补充说明,这篇文章是不完美的。因为实际漏洞并不是上文分析的这个。
具体后续跟踪,之前只在看雪论坛上发布,没有更新过来。为了本文的完整性。先将看雪上我发的后续跟踪分析的帖子一起贴在这里。



★ 2013.07.08 (http://bbs.pediy.com/showthread.php?t=174928

更新补充说明:

目前已确认本文所述问题与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本身的问题,上传应用商店后下载即可直接安装。我没研究过这部分代码,因为以为它是不会出问题的。。。

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



★ 2013.07.10 (http://bbs.pediy.com/showthread.php?t=175175

这两天这个问题基本已经公之于众了。所以不用再保密了。相关信息及自己研究的一些结果放上来,汇总一下。

首先是3月和5月google官方发出的补丁说明:

3月:

Improper installation of unsigned code
ID: ANDROID-8219321
Severity: High
Affected versions: Android 2.0 and greater

An inconsistency in the handling of zip files during application installation may lead to the installation and execution of unsigned code in a privileged context.

This issue will be publicly disclosed in 90 days. A CTS test will be included in the next CTS release.


5月:

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

Arbitrary code can be inserted into an APK and pass signature verification due to incorrect parsing of APKs. A maliciously crafted classes.dex can be inserted before a legitimately signed classes.dex in an APK. Signature verification will be performed on the second, legitimate classes.dex, but the first, malicious classes.dex is installed for application use. 

Update: This issue will be publicly presented at Blackhat 2013. Please see http://www.blackhat.com/us-13/briefings.html#Forristal for more details. At that time, we expect active public exploitation of this issue outside of Google Play.


官方补丁:patch.rar.



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


当然大家关注这个问题是在7月3号bluebox在官网发文以后。
发文地址:http://bluebox.com/corporate-blog/bl...id-master-key/


由于问题的严重性,一时间大家开始研究起来。漏洞基本公之于众是在7号cyanogenmod打上补丁之后。
详见:http://review.cyanogenmod.org/#/c/45251/


根据打补丁的代码,大家推测到是apk中存在两个相同的classes.dex文件。于是大家又开始研究POC的问题。我也自己做了尝试,由于打包顺序问题没弄出来(失之毫厘,谬以千里啊~)。今天上班没法弄,之后大家关注到了这个网址:
https://gist.github.com/poliva/36b0795ab79ad6f14fd8


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


到这本来应该已经完了。结果下午我网上下载了一个网易新闻Android客户端按照上面网址的操作方法,却怎么也安装不上。我曾怀疑是我方法的问题,后来写了一个简单的demo,发现通过这个方法又能成功安装。


这个方法是将原始apk数据全部压缩进修改后的未签名的apk中,体积直接增大了一倍!网站上自己对这个方法的描述也是“Quick & dirty PoC for Android bug 8219321 discovered by BlueboxSec”。所以确实存在问题。


经过上述方法的启发,我明白之前的方法问题出在压缩顺序上。应该是先压缩修改后的dex文件,再压缩原本的dex。


于是,比较完善的方法是:


1、将原本的apk中的文件解压出来。分成两个文件夹,orgin_dex和orgin_nodex。其中orgin_dex仅放解压出来的classes.dex文件,orgin_nodex放剩余的所有文件。
2、创建第三个文件夹dirty_dex,放修改之后编译出的classes.dex文件。
3、利用ant打包。build.xml如下:
代码:
<?xml version="1.0" encoding="UTF-8"?> <project name="MyProject" default="dist" basedir="."> <zip destfile="evil.apk" duplicate="add">   <fileset dir="D:\\ant\\orgin_nodex\\"/>   <fileset dir="D:\\ant\\dirty_dex\\"/>   <fileset dir="D:\\ant\\orgin_dex\\"/> </zip> </project> 

Linux下可使用这个shell脚本:weir.rar.


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

最后上传两个按此方法制作的apk包。一个是网易新闻,一个是微信。在启动的时候弹出自定义的Toast信息。可以直接覆盖官方应用安装。(用之前那个POC的方法我试了不能成功安装)


网易新闻下载    微信下载 



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


posted on 2013-07-06 16:58 zh.weir 阅读(5556) 评论(6)  编辑  收藏 所属分类: Android框架研究Android软件安全

评论

# re: Bluebox Security最新提报Android漏洞的初步探讨 2013-08-15 19:24 lgwinner

您好,很佩服您的破解思路,我也做了些破解实验
详细信息已经发到了您的gmail邮箱。
希望可以进行有深度交流!  回复  更多评论   

# re: Bluebox Security最新提报Android漏洞的初步探讨[未登录] 2013-08-17 12:41 jack

博主可以写的再详细点吗?
首先从system/app下导出一个APK文件,经过apktool反编译后是没有smali文件的。在网上查了下,需要将apk对应的odex反编译,生成smali。
修改生成过的smali后再编译生成classes.dex,如果此时直接将classes.dex放入导出的APK包中,再放到system/app下,重启机器后,就无此应用了,请博主详细说下从odex-->smali-->classes.dex之后,再如何打包成APK。对这一步还不是特别清楚  回复  更多评论   

# re: Bluebox Security最新提报Android漏洞的初步探讨[未登录] 2013-08-18 22:53 jack

还发现一个问题 讲system/app/Calendar.apk扣出来后按照楼主的说法,修改完之后重新覆盖原来的apk,手机重启后,系统中这个应用就没了!不知道什么原因,楼主可以给点建议吗  回复  更多评论   

# re: Bluebox Security最新提报Android漏洞的初步探讨 2013-08-19 19:23 an0nym0us

扯淡,这也叫漏洞?
Google注释里的代码已经写得很清楚了,“If this package comes from the system image, then we can trust it”,在Android的安全体系中,system image本来就是受信任的。你用ROOT读写system image后,已经直接破坏了Android的安全体系,这时再说能绕过人家的签名验证,你确定这能叫做漏洞?
好比在windows里面,你在administrator权限,关掉安全软件,用一个驱动干掉了安全软件的签名检查,你认为这叫做漏洞?
ROOT读写system image有1000种方法绕过Android的签名验证。  回复  更多评论   

# re: Bluebox Security最新提报Android漏洞的初步探讨 2013-08-29 14:24 sincere

@lgwinner
你们怎么做的破解啊!求解  回复  更多评论   

# re: Bluebox Security最新提报Android漏洞的初步探讨(及后续跟踪分析) 2014-10-23 11:09 764511389@qq.com

我觉着吧,这不算漏洞
既然你都root了,你破门而入,进到房子里面了,人家只是没锁抽屉,被你拿戒指了。那也没什么说的了。
你无论怎么签,只要替换原文件就好了(当然直接adb install 是不行的)  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

公告

大家好!欢迎光临我的 Android 技术博客!



本博客旨在交流与 Android 操作系统相关的各种技术及信息。

博客内的文章会尽量以开源的形式提供给大家,希望我们能相互交流,共同提高!

有不足之处,请不吝赐教!

我的邮箱:zh.weir@gmail.com
我的新浪微博:@囧虎张建伟

 

导航

<2013年7月>
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

统计

留言簿(18)

随笔分类(24)

随笔档案(18)

文章档案(1)

搜索

最新评论

阅读排行榜

评论排行榜