• 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中会怎么样?文章发布后,再试试~ ^-^)         
  • 相关阅读:
    【33】避免遮掩继承而来的名称
    调用异步方法
    Python 调用C++
    【37】绝不重新定义继承而来的缺省参数值
    【36】绝不重新定义继承而来的non-virtual方法
    【38】通过复合塑模出Has-A 或根据某物实现出
    【转】C++ function、bind以及lamda表达式
    mongodb
    mongodb
    mongodb
  • 原文地址:https://www.cnblogs.com/goodhacker/p/3177190.html
Copyright © 2020-2023  润新知