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

转载请注明出处： h ttp://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。

InsertionofarbitrarycodewithoutchangingpackagesignatureduetoincorrectparsingofAPKs(updatetopreviousbulletin)
Firstpublished:March4th,2013
LastUpdated:May31st,2013
ID:ANDROID-8219321
Severity:High
AffectedAndroidVersions:all

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

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

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

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

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

3月：

Improperinstallationofunsignedcode
ID:ANDROID-8219321
Severity:High
Affectedversions:Android2.0andgreater

Aninconsistencyinthehandlingofzipfilesduringapplicationinstallationmayleadtotheinstallationandexecutionofunsignedcodeinaprivilegedcontext.

Thisissuewillbepubliclydisclosedin90days.ACTStestwillbeincludedinthenextCTSrelease.

5月：

InsertionofarbitrarycodewithoutchangingpackagesignatureduetoincorrectparsingofAPKs(updatetopreviousbulletin)
Firstpublished:March4th,2013
LastUpdated:May31st,2013
ID:ANDROID-8219321
Severity:High
AffectedAndroidVersions:all

ArbitrarycodecanbeinsertedintoanAPKandpasssignatureverificationduetoincorrectparsingofAPKs.Amaliciouslycraftedclasses.dexcanbeinsertedbeforealegitimatelysignedclasses.dexinanAPK.Signatureverificationwillbeperformedonthesecond,legitimateclasses.dex,butthefirst,maliciousclasses.dexisinstalledforapplicationuse.

Update:ThisissuewillbepubliclypresentedatBlackhat2013.Pleaseseehttp://www.blackhat.com/us-13/briefings.html#Forristalformoredetails.Atthattime,weexpectactivepublicexploitationofthisissueoutsideofGooglePlay.

官方补丁： 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&dirtyPoCforAndroidbug8219321discoveredbyBlueboxSec”。所以确实存在问题。

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

于是，比较完善的方法是：

1、将原本的apk中的文件解压出来。分成两个文件夹，orgin_dex和orgin_nodex。其中orgin_dex仅放解压出来的classes.dex文件，orgin_nodex放剩余的所有文件。
2、创建第三个文件夹dirty_dex，放修改之后编译出的classes.dex文件。
3、利用ant打包。build.xml如下：
代码:

<?xmlversion="1.0"encoding="UTF-8"?> <projectname="MyProject"default="dist"basedir="."> <zipdestfile="evil.apk"duplicate="add"> <filesetdir="D:\\ant\\orgin_nodex\\"/> <filesetdir="D:\\ant\\dirty_dex\\"/> <filesetdir="D:\\ant\\orgin_dex\\"/> </zip> </project>

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

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

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

网易新闻下载微信下载

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

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

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

更多相关文章

随机推荐