Google在12月发布的安卓系统安全公告中披露了一个名为“Janus”安卓漏洞（漏洞编号：CVE-2017-13156）。该漏洞可以让攻击者绕过安卓系统的signature scheme V1签名机制，进而直接对App进行篡改。而且由于安卓系统的其他安全机制也是建立在签名和校验基础之上，该漏洞相当于绕过了安卓系统的整个安全机制。
一旦攻击者将植入恶意代码的仿冒的App投放到安卓商店等第三方应用市场，就可替代原有的App做下载、更新。网友安装这些仿冒App后，不仅会泄露个人账号、密码、照片、文件等隐私信息，手机更可能被植入木马病毒，进而或导致手机被ROOT，甚至被远程操控。
分析显示，安卓5.0到8.0系统以及基于signature scheme V1签名机制的App均受“Janus”漏洞影响；基于signature scheme V2签名的App则不受影响。
1、尽快将App APK(安装包）升级到最新的Signature scheme V2签名机制；
2、及时校验App APK文件的开始字节，以确保App是未被篡改；
“Janus”漏洞爆发原因是什么？
为了提升安卓系统的安全性，Google发布了新的签名认证体系signature scheme V2。由于，signature scheme V2需要对App进行重新发布，而大量的已经存在的App APK无法使用V2校验机制，所以为了保证向前兼容性，V1的校验方式的还被保留，这就导致了“Janus”漏洞的出现。
Google为什么发布signaturescheme V2呢？那就盘点一下，近年来安卓系统曾爆出的一系列安全问题吧。
这些年，安卓系统爆出的签名漏洞
“Janus”是一个签名与校验漏洞，其实，这不是安卓第一次爆出此类漏洞。在2013年 Black Hat上，Bluebox的安全团队公布了一个“MasterKey”漏洞。该漏洞影响包括当时最新的安卓6.0系统及以下所有系统。那么，这些漏洞是怎么形成的呢？
“MasterKey”漏洞原理是基于APK（ZIP文件格式）里面的多个ZipEntry实现的，具体如下：
1. 向原始的App APK的前部添加一个攻击的classes.dex文件（A)；
2. 安卓系统在校验时计算了A文件的hash值，并以”classes.dex”字符串做为key保存；
3. 然后安卓计算原始的classes.dex文件（B），并再次以”classes.dex”字符串做为key保存，这次保存会覆盖掉A文件的hash值，导致Android系统认为APK没有被修改，完成安装；
4. APK程序运行时，系统优先以先找到的A文件执行，忽略了B，导致漏洞的产生。
MasterKey漏洞爆出后没多久，国内的“安卓安全小分队”再爆出一个类似的漏洞。这个漏洞非常精巧：利用了Zip local file header在计算时候的一个整形溢出漏洞。
1. 向原有的APK中的classes.dex文件B替换为攻击文件A，并添加一个大小为0xFFFD的extrafield；
2. 将原始dex文件B去除头3个字节写入extrafield；
3. Android系统在校验签名时使用的是Java代码的short，将0xFFFD以16位带符号整形的方式解析得到-3, 并解析出原始的文件B，Android认为程序APK无修改，正常安装；
4. 系统在执行时使用C代码的uint16，将0xFFFD以16位无符号整形方式，得到攻击文件B。
这个漏洞的精巧之处在于，DEX文件以‘dex’字符串开头，而classes.dex以这个字符串结尾，通过-3的值将这两个内容在文件中重叠起来，因此这也限制了“9695860”漏洞只能对classes.dex进行攻击。
在“9695860”漏洞爆出不久后，APK文件中被发现存在类似的整形溢出漏洞，这个比“9695860”漏洞更容易利用且可以攻击APK中的任意文件。
原因是安卓默认认为Zip中localfile header和central directory entry中的文件名长度和和extra的长度是一致的。安装过程中java代码在处理时出现溢出，读取到了正常的文件B，通过校验，APK正常安装。运行过程中，C代码处理时没有溢出，读取到了攻击的文件A。
Google发布了signature scheme V2签名机制
以上的一系列漏洞全部出在基于jarsigner机制建立起来的签名和校验机制signature scheme V1出现。Google也意识到了这套机制的缺陷，所以，发布了重新设计的Siginature scheme V2签名机制。
Siginature scheme V2 APK文件整个内容进行签名，目标是任何对APK的修改都会导致检验的失败。
目前signature scheme V2已经在安卓7.0系统及以上的版本中支持。
“Janus”漏洞的攻击原理、利用过程
1、安卓在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’.
2、ZIP文件的读取方式是通过在文件末尾定位central directory, 然后通过里面的索引定位到各个zip entry，每个entry解压之后都对应一个文件。
2. 使用安卓Signaturescheme V1签名的App APK文件。
1、攻击者可以向APK文件的开始位置放置一个攻击的DEX文件A；
2. 安卓系统在安装时用ZIP的读取机制从末尾开始进行文件的读取，读取到了原始的APK内容，并且以V1的方式进行校验，认为这个文件是正常的，没有篡改，APK安装成功；
3. 在运行时，Android的ART虚拟机从文件头开始读取，发现是一个DEX文件，直接执行，攻击文件A被最终执行。
可以在没有apk所有者的证书的情况下对apk进行修改，并且绕过校验机制安装在用户的手机上，造成的可能后果如下：
1. 对存储在原手机上的数据进行读取，例如金融类APP的银行密码、支付密码、token; 通信类APP的聊天记录、图片、通信录
2. 对用户的输入做各种监听、拦截、欺诈，引导用户输入密码，转账。
3. 利用这个漏洞可以更新Android的系统APP，从获得更高的系统权限，甚至root/越狱，为其他攻击做准备
综上，
安卓系统“Janus”安全漏洞（CVE-2017-13156），所有运行于安卓5.0以上系统，仅采用安卓APK V1签名机制的APP受到影响。该漏洞可让攻击者在不改变APP开发者签名的情况下篡改APP程序、植入恶意代码，造成APP敏感数据泄露、手机远程控制等危害。核心就一点：不能只使用安卓APK V1签名机制打包签名apk。这边文章主要记录一下我在项目中处理这个问题的时候遇到的一些问题和解决方法。
一、处理过程
-
检验apk的签名机制：使用漏洞核查工具GetApkInfo.jar（网上可下载）
< 1>使用命令java -jar GetApkInfo.jar *.apk查看APK信息及签名版本；
< 2>结果说明：
①若“V1签名验证通过”为true，则该APK使用V1签名，反之没有；
②若“V2签名验证通过”为true，则该APK使用V2签名，反之没有；
③若“V1签名验证通过”和“V2签名验证通过”均显示为true，则该应用同时使用V1+V2签名。
-
若上述结果显示V2签名验证通过，则说明你的app是安全的；反之，重新打包签名，必须含有V2签名机制。
二、处理过程中遇到的问题
由于我们的项目要求防反编译，因而采用了360加固助手对项目进行加固并且加固时采用的自动签名的方式。因而造成无论打包时采用的时何种签名机制， V2签名验证均不通过。对比加固前后的两种情况，加固前V2签名验证通过，加固后则验证不通过。
猜测原因：加固助手在加固并自动签名过程中破坏了原有的签名
处理方式：取消360加固助手的自动签名，在应用加固后手动采用360的签名方式签名，签名采用V2签名机制签名。
验证：V1、V2验证通过。（打包时采用的时V1+V2的签名机制）
三、注意事项
(1)GetApkInfo.jar和apk放在同级目录下
(2)不能放在有中文的目录下(桌面也不行)
(3)使用命令前应先进入jar和apk的当前目录
(4)“漏洞核查工具与方法”这个工具，本机要安装jdk 8以上才能使用
(5)兼容性问题：v2签名是5.0以上才支持<待验证>
(6)打包时采用v1+v2签名模式，使用360加固助手加固时，不能使用自动签名，先加固再手动签名，签名时采用v2签名。
(7)加固签名后的app需要使用漏洞核查工具GetApkInfo.jar检测两种签名是否都通过了，确保安全性与准确性。
最后附上360加固助手对于这次安全漏洞的解决方法：360加固保紧急上线针对“Janus”安卓漏洞的解决方案
