安卓漏洞学习（九）：janus漏洞原理与利用

“Janus”安卓漏洞（漏洞编号：CVE-2017-13156）
该漏洞可以让攻击者绕过安卓系统的signature scheme V1签名机制，进而直接对App进行篡改。 众所周知，Android具有签名机制。正常情况下，开发者发布了一个应用，该应用一定需要开发者使用他的私钥对其进行签名。恶意攻击者如果尝试修改了这个应用中的任何一个文件（包括代码和资源等），那么他就必须对APK进行重新签名，否则修改过的应用是无法安装到任何Android设备上的。但如果恶意攻击者用另一把私钥对APK签了名，并将这个修改过的APK对用户手机里的已有应用升级时，就会出现签名不一致的情况。因此，在正常情况下，Android的签名机制起到了防篡改的作用。
如果恶意攻击者利用Janus漏洞，那么恶意攻击者就可以任意地修改一个APK中的代码（包括系统的内置应用），同时却不需要对APK进行重新签名。换句话说，用这种方式修改过的APK，Android系统会认为它的签名和官方的签名是一致的，但在这个APK运行时，执行的却是恶意攻击者的代码。恶意攻击者利用这个修改过的APK，就可以用来覆盖安装原官方应用（包括系统的内置应用）。由此可见，该漏洞危害极大，而且影响的不仅是手机，而是所有使用Android操作系统的设备。
为了提升安卓系统的安全性，Google发布了新的签名认证体系signature scheme V2。由于，signature scheme V2需要对App进行重新发布，而大量的已经存在的App APK无法使用V2校验机制，所以为了保证向前兼容性，V1的校验方式的还被保留，这就导致了“Janus”漏洞的出现。

攻击原理

安卓在4.4中引入了新的执行虚拟机ART，这个虚拟机经过重新的设计，实现了大量的优化，提高了应用的运行效率。与“Janus”有关的一个技术点是，ART允许运行一个raw dex，也就是一个纯粹的dex文件，不需要在外面包装一层zip。而ART的前任DALVIK虚拟机就要求dex必须包装在一个zip内部且名字是classes.dex才能运行。当然ART也支持运行包装在ZIP内部的dex文件，要区别文件是ZIP还是dex，就通过文件头的magic字段进行判断：ZIP文件的开头是‘PK’, 而dex文件的开头是’dex’。
Android在安装一个APK时会对APK进行签名验证，但却直接默认该APK就是一个ZIP文件（并不检查文件头部的魔术字），而ZIP格式的文件一般都是从尾部先读取，因此只要ZIP文件尾部的数据结构没有被破坏，并且在读取过程中只要没有碰到非正常的数据，那么整个读取就不会有任何问题。
总而言之，Android在加载执行代码时，只认文件头，而安装验证签名时只认文件尾。
因此只要构造一个APK，从其头部看是一个Dex文件，从其尾部看，是一个APK文件，就可以实施攻击。很容易想到，将原APK中的classes.dex抽取出来，改造或替换成攻击者想要执行的dex，并将这个dex和原APK文件拼起来，合成一个文件，就可以利用Janus漏洞。
当然仅仅简单地将恶意dex放在头部，原apk放在尾部合起来的文件还是不能直接用来攻击。需要稍作修正。对于头部dex，需要修改DexHeader中的file_size，将其调整为合并后文件的大小。另外需要修改尾部Zip,修正[end of central directory record]中[central directory]的偏移和[central directory]中各[local file header]的偏移。

DEX文件结构

Dex文件有很多部分组成，其中Dex Header最为重要，因为Dex的其他组成部分，都需要通过这个Dex Header中的索引才能找到。 Dex Header内部结构如下：<