转载请注明出处：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本身的问题，上传应用商店后下载即可直接安装。我没研究过这部分代码，因为以为它是不会出问题的。。。

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

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！