Android安全检测 - Janus签名漏洞
前言
这一章来说说Janus签名漏洞
,网上关于这个漏洞的介绍很详细,其中的原理均为其它地方进行摘录,那么我主要做的就是POC测试
,在文章末尾也会给出相应的样本,当然样本就是自己做的
,用真实的上线项目
来做这个也不合适
,想找真实的项目来练练手的话推荐找2017年12月
之前的项目(学习可以,但不要在网上发布不当的东西
)
一、漏洞原理
基本概述
Google在2017年12月份披露了一个名为“Janus”的安全漏洞(漏洞编号:CVE-2017-13156
),该漏洞可以让攻击者绕过
安卓的签名校验机制(signature scheme V1签名机制
),进而可以对应用进行篡改(apk代码篡改
)。安卓的部分安全机制是建立在签名和校验的基础上的,故这个漏洞会给搭载安卓系统的设备造成很大的危害
这个漏洞可以在篡改apk内容的情况下,保持apk的签名不发生变化,那么这就会使得用户在下载到安装这个过程中,设备中的安全软件发现不了它是一个被篡改的恶意盗版应用。
影响范围
安卓5.0到8.0系统以及基于V1签名机制
的app均Janus漏洞影响
;基于V2签名
的App则不受影响
。从安卓7.0开始系统就已经支持了V2签名,那么7.0的安卓系统安装了含有V2签名的app不会受到此漏洞的影响
原理
文章来源:https://zhuanlan.zhihu.com/p/31972541
攻击原理解读:
安卓应用程序代码逻辑主要是以DEX文件格式存放。DEX格式标准文档链接:链接
此DEX格式文件以文件名classes.dex,classes2.dex等与其他应用程序所需文件一起压缩存放于APK格式的文件里。APK格式文档链接:链接
APK格式文件就是大众熟知的安卓应用程序安装包,有它就可以安装一款应用软件到手机。问题也就出在安卓操作系统安装应用程序的流程上。
蚂蚁金服安全部门的巴斯光年实验室成员吴潍浠(@wish_wu)表示,Android操作系统在安装一个应用软件时,会将DEX文件转化成OAT文件,负责转化任务的程序叫dex2oat 。安卓操作系统会将APK文件直接给dex2oat程序。
而dex2oat有这样一套逻辑:
如果给它的是APK文件,它会把classes.dex文件从APK文件里取出再转化成OAT文件。如果给它的是DEX文件,它直接把DEX文件转化成OAT文件。
如果一个既是APK格式文件又是DEX格式文件的文件,给dex2oat程序会怎样呢?
以下是程序判断逻辑:
dex2oat通过IsZipMagic函数和IsDexMagic函数来决定这是什么格式的文件。
再来看看IsZipMagic函数和IsDexMagic函数的实现:所以dex2oat程序是依据前文件的前4个字节决定这是什么格式文件。然而根据APK格式,前两个字节可以不是‘P’和‘K’,也就是说这里对APK格式的判断并不严谨。事实上一个既满足APK格式要求又满足DEX格式要求的文件是可以构造出来的。
借用漏洞个发现者发布的图片所示:这里我们暂且把这个DEX格式文件与APK格式文件合体之后产生的文件叫做DEXAPK文件。
当DEXAPK文件在被安卓操作系统安装时,包管理器的代码会把它当作APK格式文件,而dex2oat会把它当作DEX格式文件。安卓应用程序的签名验证是包管理器做的,程序运行加载的OAT文件是由dex2oat根据输入的DEX格式文件生成的。
攻击者可以利用Janus漏洞,将一个恶意DEX与源APK进行拼接,构造一个DEXAPK文件,从而既可以通过安装程序时系统对APK文件的签名认证,又包含攻击者想要运行的程序逻辑。Android系统运行时会将当前的APK文件看作是之前应用的合法升级版并允许安装,最终通过
“升级”植入用户设备执行恶意DEX代码。
二、POC
这里主要做"Janus"漏洞的POC测试,在实际的操作过程种遇到的一些问题
测试环境\工具
(1)AndroidStudio自带模拟器Android 6.0
(2)dex和apk合并工具
两种情况的不同处理
(1)在原dex的基础之上进行修改
(2)生成一个新dex替换原dex
具体测试
1. 在原dex的基础之上进行修改
1.1. 使用Android Studio生成含有单dex文件的apk
(只使用V1签名机制进行签名),并查看apk的签名信息
1.2. 模拟真实环境(不知道apk源码的情况下)
,使用AndroidKiller对apk文件代码(dex)进行修改,将文本修改成"盗版软件"
,并且进行重打包
1.3. 将重打包生成的apk文件提取出classes.dex文件
,将提取出的dex文件和原apk文件(样本)
进行合并
(使用工具进行合并)
1.4. 将合并完成的apk文件安装至模拟器,可以发现apk的内容已经修改,成功复现在原dex的基础之上进行修改
情况下的Janus漏洞
2、生成一个新dex替换原dex
2.1. 使用Android Studio生成一个含有Application、Activity、ContentProvider
的apk文件
2.2. 模拟真实环境(不知道apk源码的情况下)
,将apk进行反编译查看清单文件中的所有组件
2.3.创建一个新的Android项目,根据清单文件创建出所有已存在的组件(主Activity、ContentProvider),若是有Application也要进行创建
2.4. 把新Android项目生成的apk文件提取出classes.dex文件
,将提取出的dex文件和原apk文件(样本)
进行合并
(使用工具进行合并)
2.5.将合并完成的apk文件安装至模拟器,可以发现apk的内容已经修改,成功复现Janus漏洞
遇到的问题
1、在第二种情况(生成一个新dex替换原dex
)中,若未实现Application,则会发生崩溃情况
2、在第二种情况(生成一个新dex替换原dex
)中,若未实现ContentProvider,则会发生崩溃情况
3、合并apk之后无法进行安装的问题。出现这种问题可能是当前手机系统已经修复了此漏洞,换模拟器或者其它手机即可(系统版本在5.0-8.0)
4、单dex和多dex的情况不同,单dex的情况下可以在原apk的基础上直接进行修改,而不对功能的使用造成影响,而多dex的情况下处理比较麻烦,分dex表示dex的方法数超过了65535,若想保留原软件的功能,而使用一个dex来替换多dex文件,这是不太现实的,那么对于多dex并想保留原功能可以考虑使用动态加载和Classloader替换的方式来实现
三、修复建议
(1)建议开发者使用V2签名机制对应用进行签名
四、样本
asjhan for Android reverse