欢迎来到 嗅灵易学

零基础也能上手的脚本技术课,一对一答疑带你入门

[原创]Bluebox Security提报Android 绕过应用签名认证漏洞原理

[原创]Bluebox Security提报Android 绕过应用签名认证漏洞原理

本文章由Jack_Jia编写,转载请注明出处。  
文章http://blog.csdn.net/jiazhijun/article/details/9280995

一、漏洞描述
      安全公司 Bluebox Security 日前声称,他们在 Android 系统中发现了可能会对 99% 设备造成影响的漏洞。按照其说法,这个漏洞自 Android 1.6(Donut)以来就一直存在,恶意软件制作者可以在不破解加密签名的前提下利用它来修改合规 APK 的代码,可以绕过android应用的签名验证安全机制。
二、影响设备
      
      理论上会影响android1.6至漏洞提报google时间点2013-02之间的所有设备。
三、漏洞原理
      1、恶意APK如何在不修改应用签名情况下绕过android签名验证机制。

          漏洞修复前后比对:(luni/src/main/java/java/util/zip/ZipFile.java)
                  
        在漏洞修复前Android未考虑到APK压缩文件中的重复entryName问题,这样恶意软件制作者就可以制作特定的APK包绕过Android APK包证书认证。
        恶意APK软件包包含两个entryName="classes.dex"的文件,对应的数据分别为malicious.data和org.data,且malicious.data在压缩包字典中位于org.data之前。
       由于APK解析中,当entryName相同时,后者会覆盖前者信息,这样就能顺利通过APK证书签名验证过程。
       2、插入malicious.data绕过Android APK包证书验证后,如何工作呢?
            android apk包经过验证合格后,就需要通过请求installed进程完成代码的优化。进过优化后的代码才是APP程序运行时加载的代码。
            dex优化在dalvik2\dexopt\OptMain.cpp完成。
            OptMain.cpp对apk压缩文件的处理是通过dalvik2\libdex\ZipArchiver.cpp来完成的。
            通过分析ZipArchiver.cpp代码,底层对APK包解析可以存在相同entryName的文件而不会覆盖,且当根据文件名classes.dex提取压缩内容时,总是返回第一个名字匹配的数据,这样我们的插入的malicious.data就成了真正优化的代码。         
     经过以上两步,整个漏洞利用也就完成了。(以上逻辑暂未本人实际验证)
四、POC代码
   开源POC:https://gist.github.com/poliva/36b0795ab79ad6f14fd8
五、相关链接
    http://review.cyanogenmod.org/#/c/45251/
    http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/
    http://cn.engadget.com/2013/07/04/bluebox-reveals-android-security-vulnerability/

注意:上传附件及图片大小不得大于30M。

⚠️ 版权声明:
本博客所有内容(含教程、源码、工具)仅供个人技术学习与研究交流使用,严禁商用、倒卖、二次分发及非法用途。
未经作者书面授权,任何组织或个人不得转载、复制或用于其他平台,违者将追究相关责任。

0 0 0 举报
复制成功