Bluebox Security最新提报Android漏洞的初步探讨
16lz
2021-01-23
作 者:ZhWeir
时 间:2013-07-06,17:04:34
链 接:http://bbs.pediy.com/showthread.php?t=174928
转载请注明出处： http://www.blogjava.net/zh-weir/arch...06/401270.html
BlueboxSecurity最新提报Android漏洞的初步探讨
BlueboxSecurity在7月3号的时候，在官网上发布了一个据称99%Android机器都有的一个漏洞。国内最早在4号开始有媒体报道，并持续升温。该漏洞可使攻击者在不更改Android应用程序的开发者签名的情况下，对APK代码进行修改。并且，这个漏洞涉及到从1.6版本至今全部的Android版本，换句话说，这4年中生产的9亿设备，即当今市场上99%的Android产品都面临这一问题。
看到这样的报道，一开始我和我的小伙伴们都不敢相信。因为签名机制用了这么多年，多少大脑袋厚眼镜的天才们想要颠覆都没搞定，BlueboxSecurity怎么可能搞定的呢？不过，由于好奇心驱使，我开始查看BlueboxSecurity官方的说法： 《UNCOVERINGANDROIDMASTERKEYTHATMAKES99%OFDEVICESVULNERABLE》 ，我意识到，这个问题应该不是签名机制本身的问题，而是Android安装APK过程中的校验存在漏洞。
如果是APK安装校验签名的漏洞，而这个Bug又从1.6开始就有，那也太伤我自尊了。出于某种嗜好，俺怎么着也是从1.5起就对包管理充满了浓厚兴趣，2011年还写了一篇《AndroidAPK签名比对》的文章，里面对Android签名机制做了稍详细的解析。不过回过头来一想，GoogleAndroid负责包管理的工程师估计更伤自尊了，当然这是后话。
在将信将疑的感情中，迎来了一个休息两天的周末。于是我开始翻翻包管理的代码，跟着APK安装流程往下看。以前一直有个地方让我觉得google工程师真的这么重视效率吗？结果今天一看，发现好像存在问题。大家来评评：
安装应用的时候包管理检查签名不知检查了多少次，在这里针对系统应用却只检查manifest.xml一个文件的签名。GoogleAndroid工程师真的是为了效率么？不管怎样，他一定是深思熟虑之后的结果，因为这里有段注释：“Ifthispackagecomesfromthesystemimage,thenwecantrustit...we'lljustusetheAndroidManifest.xmltoretrieveitssignatures,notvalidatingallofthefiles.”（所以如果真是这段代码导致的漏洞，他真伤自尊了...）
事实上，大多数时候安装一个APK对于Android来说是一个复杂的过程，这个过程中Google为了安全做了很多冗余的事情。但是结合BlueboxSecurity的漏洞描述，我联想到一种情况。那就是开机过程中扫描安装/system/app中的应用时！基于这个想法，我自己鼓捣了一会儿，发现按这个逻辑往下还真能绕过签名认证！当然，还有一些令人扫兴的附加操作，例如需要root权限以对/system/app下的文件进行读写操作。
这里我贴一下我的操作步骤吧。
（ 先声明：我所描述的不一定是BlueboxSecurity最近宣称的漏洞，只是一种系统应用修改代码而绕过Android签名校验的方法。BlueboxSecurity所描述的漏洞据官网消息称，将由Bluebox的CTOJeffForristal，在本月27号到8月1号的拉斯维加斯美国黑帽安全大会上讲话时，公布具体的技术细节并放出相应的工具和资料 ）
1、好吧，我以MIUIROM中的系统应用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、adbpushAPK_DIST到/system/app/下，覆盖原来的APK_ORG。
到此为止，大功告成了！如果系统没有更新应用，可以重启一下手机。结果发现文件管理器安装成功，自己添加的Log正常打印，之前在APK_ORG时登录的网盘（快盘），数据都在且能正常使用。
总结：这段代码应该是从1.6之后就一直是这样，因此符合BlueboxSecurity所说的99%Android手机都存在此漏洞。但是我现在发现的漏洞需要手动root之后才能操作出来，且只针对systemapp，与BlueboxSecurity所描述的情况有所出入。也许是同一个漏洞，不同的操作方式，也许不是同一个漏洞，或者这个压根不算漏洞。希望这篇文章起到抛砖引玉的作用，呼吁国内Android安全人员和手机厂商一起加入探讨～（哦，对了，我直接把这个apk放到官方ROM中会怎么样？文章发布后，再试试～^-^）
时 间:2013-07-06,17:04:34
链 接:http://bbs.pediy.com/showthread.php?t=174928
转载请注明出处： http://www.blogjava.net/zh-weir/arch...06/401270.html
BlueboxSecurity最新提报Android漏洞的初步探讨
BlueboxSecurity在7月3号的时候，在官网上发布了一个据称99%Android机器都有的一个漏洞。国内最早在4号开始有媒体报道，并持续升温。该漏洞可使攻击者在不更改Android应用程序的开发者签名的情况下，对APK代码进行修改。并且，这个漏洞涉及到从1.6版本至今全部的Android版本，换句话说，这4年中生产的9亿设备，即当今市场上99%的Android产品都面临这一问题。
看到这样的报道，一开始我和我的小伙伴们都不敢相信。因为签名机制用了这么多年，多少大脑袋厚眼镜的天才们想要颠覆都没搞定，BlueboxSecurity怎么可能搞定的呢？不过，由于好奇心驱使，我开始查看BlueboxSecurity官方的说法： 《UNCOVERINGANDROIDMASTERKEYTHATMAKES99%OFDEVICESVULNERABLE》 ，我意识到，这个问题应该不是签名机制本身的问题，而是Android安装APK过程中的校验存在漏洞。
如果是APK安装校验签名的漏洞，而这个Bug又从1.6开始就有，那也太伤我自尊了。出于某种嗜好，俺怎么着也是从1.5起就对包管理充满了浓厚兴趣，2011年还写了一篇《AndroidAPK签名比对》的文章，里面对Android签名机制做了稍详细的解析。不过回过头来一想，GoogleAndroid负责包管理的工程师估计更伤自尊了，当然这是后话。
在将信将疑的感情中，迎来了一个休息两天的周末。于是我开始翻翻包管理的代码，跟着APK安装流程往下看。以前一直有个地方让我觉得google工程师真的这么重视效率吗？结果今天一看，发现好像存在问题。大家来评评：
安装应用的时候包管理检查签名不知检查了多少次，在这里针对系统应用却只检查manifest.xml一个文件的签名。GoogleAndroid工程师真的是为了效率么？不管怎样，他一定是深思熟虑之后的结果，因为这里有段注释：“Ifthispackagecomesfromthesystemimage,thenwecantrustit...we'lljustusetheAndroidManifest.xmltoretrieveitssignatures,notvalidatingallofthefiles.”（所以如果真是这段代码导致的漏洞，他真伤自尊了...）
事实上，大多数时候安装一个APK对于Android来说是一个复杂的过程，这个过程中Google为了安全做了很多冗余的事情。但是结合BlueboxSecurity的漏洞描述，我联想到一种情况。那就是开机过程中扫描安装/system/app中的应用时！基于这个想法，我自己鼓捣了一会儿，发现按这个逻辑往下还真能绕过签名认证！当然，还有一些令人扫兴的附加操作，例如需要root权限以对/system/app下的文件进行读写操作。
这里我贴一下我的操作步骤吧。
（ 先声明：我所描述的不一定是BlueboxSecurity最近宣称的漏洞，只是一种系统应用修改代码而绕过Android签名校验的方法。BlueboxSecurity所描述的漏洞据官网消息称，将由Bluebox的CTOJeffForristal，在本月27号到8月1号的拉斯维加斯美国黑帽安全大会上讲话时，公布具体的技术细节并放出相应的工具和资料 ）
1、好吧，我以MIUIROM中的系统应用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、adbpushAPK_DIST到/system/app/下，覆盖原来的APK_ORG。
到此为止，大功告成了！如果系统没有更新应用，可以重启一下手机。结果发现文件管理器安装成功，自己添加的Log正常打印，之前在APK_ORG时登录的网盘（快盘），数据都在且能正常使用。
总结：这段代码应该是从1.6之后就一直是这样，因此符合BlueboxSecurity所说的99%Android手机都存在此漏洞。但是我现在发现的漏洞需要手动root之后才能操作出来，且只针对systemapp，与BlueboxSecurity所描述的情况有所出入。也许是同一个漏洞，不同的操作方式，也许不是同一个漏洞，或者这个压根不算漏洞。希望这篇文章起到抛砖引玉的作用，呼吁国内Android安全人员和手机厂商一起加入探讨～（哦，对了，我直接把这个apk放到官方ROM中会怎么样？文章发布后，再试试～^-^）
更多相关文章
- Android_判断文件是否存在并创建代码
- Android / iOS 静态代码扫描工具调研
- Android 项目打包成apk文件
- Android 内部API （android.internal）和隐藏代码(@hide)概述
- Android从远程服务器下载文件到本地sd卡中
- Android控制手电筒代码，简单易用，不需要任何权限
- Android文件访问权限问题