? ? ? ? Android证书签名漏洞,是指攻击者可以在不改变原APK的签名情况下修改APK的代码,从而绕过Android的签名认证安全机制。通过植入恶意代码的到仿冒的App中,就可替代原有的App做下载、更新。
? ? ? ? 正常情况下,开发者发布了一个应用,该应用一定需要开发者使用他的私钥对其进行签名。恶意攻击者如果尝试修改了这个应用中的任何一个文件(包括代码和资源等),那么他就必须对APK进行重新签名,否则修改过的应用是无法安装到任何Android设备上的。
? ? ? ? 这个漏洞是由国外的一家安全公司Bluebox Security在2013年7月初揭露的,这个漏洞自Android1.6版本就一直存在,漏洞的覆盖范围达到99%。
? ? ? ?理论上会影响2013年5月以前的android系统,大概是4.3之前的android,大概可以控制95%以上的Android手机。
2.2. 原理
该漏洞位于luni/src/main/java/java/util/zip/ZipFile.java目录下,具体的漏洞点如下:
for (int i = 0 ; i < numEntries; ++i)
{
? ? ? ? ZipEntry newEntry = new ZipEntry (hdrBrf , bin) ;
? ? ? ? m.entries.put (newEntry.getname() , newEntry )
}
? ? ? ? 同一个文件夹内是不允许存在两个同名文件的,然而在APK这样一个ZIP格式的文件中却没有这样的限制,同时Android并未对APK中的重名文件进行检测,即一个APK压缩文件中可能存在两个相同的classes.dex文件。
? ? ? ? 此时可以假设一种情况,一个APK压缩包中存在两个classes.dex文件,第一个是恶意的执行文件,第二个是原来的执行文件,Android系统实际上验证的是第二个执行文件,因此可以顺利绕过APK的签名验证。Java层对APK验证完后,会请求installed进程完成代码的优化,而提取的classes.dex文件却是第一个执行文件。
其他变种可参考:学习Android三个签名漏洞_安卓 签名漏洞-CSDN博客
漏洞是如何工作的?
? ? ? ?要安裝 APK时,Android会检查其凭证。主要的 function 是 ZipFile 的 mEntries struct。而当读取解析APK(实际是ZIP文件)时, 系统会寻找 Zip Central Directory Entry,以Name(APK中的文件名)当成map的key, 依序放置LinkedHashMap中。当Name(文件名)发生碰撞时,LinkedHashMap会回传旧的值,并以新的值取代。因此检测凭证时,解析到两个dex文件,第二个dex文件会覆盖第一个dex文件,进行证书校验时校验的还是第二个dex文件,也就是原始的classes.dex,通过此方式绕过签名验证。但Apk执行的却是第一个classes.dex。
? ? ? ? Google在2017年12月份披露了一个名为“Janus”的安全漏洞(漏洞编号:CVE-2017-13156),该漏洞可以让攻击者绕过安卓的签名校验机制(signature scheme V1签名机制),进而可以对应用进行篡改(apk代码篡改)。安卓的部分安全机制是建立在签名和校验的基础上的,故这个漏洞会给搭载安卓系统的设备造成很大的危害,这个漏洞可以在篡改apk内容的情况下,保持apk的签名不发生变化,那么这就会使得用户在下载到安装这个过程中,设备中的安全软件发现不了它是一个被篡改的恶意盗版应用。
如果恶意攻击者利用Janus漏洞,那么恶意攻击者就可以任意地修改一个APK中的代码(包括系统的内置应用),同时却不需要对APK进行重新签名。换句话说,用这种方式修改过的APK,Android系统会认为它的签名和官方的签名是一致的,但在这个APK运行时,执行的却是恶意攻击者的代码。恶意攻击者利用这个修改过的APK,就可以用来覆盖安装原官方应用(包括系统的内置应用)。由此可见,该漏洞危害极大,而且影响的不仅是手机,而是所有使用Android操作系统的设备。
3.2. 影响范围
安卓5.0到8.0系统以及基于V1签名机制的app均Janus漏洞影响;基于V2签名的App则不受影响。从安卓7.0开始系统就已经支持了V2签名,那么7.0的安卓系统安装了含有V2签名的app不会受到此漏洞的影响。
安卓应用程序代码逻辑主要是以DEX文件格式存放。此DEX格式文件以文件名classes.dex,classes2.dex等与其他应用程序所需文件一起压缩存放于APK格式的文件里。
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代码。
解决方法:
添加了对ZIP格式文件,也就是APK格式文件的头部校验,保证头部的4字节确定是LocalFileHeader的Signature,此Signature就是以‘P’和‘K’开头,这时候dex2oat就只会把给它的文件当作APK格式文件了。
为了提升安卓系统的安全性,Google发布了新的签名认证体系,从v1到v2、v3、v4,但是大量的已经存在的App APK无法使用高版本的证书校验机制,所以为了保证向前兼容性,V1的校验方式的还被保留。
1.?v1方案:基于 JAR 签名。
2. v2方案:Android 7.0 引入,改动大。
3. v3方案:Android 9.0 引入,基于 v2 的升级。
4. v4方案:Android 11.0 引入,用来支持 ADB 增量 APK 安装。
参考链接:学习Android三个签名漏洞_安卓 签名漏洞-CSDN博客