对抗分析技术对安卓生态系统安全性影响研究
2019-08-13张桢宇朱东来杨哲慜
张桢宇,朱东来,杨哲慜,杨 珉
(复旦大学软件学院,上海201203)
E-mail:yangzhemin@fudan.edu.cn
1 引言
近年来,智能移动设备得到了飞速的推广普及.随着日新月异的移动应用的出现,智能移动设备在生活的方方面面中正在起到越来越重要的作用.据IDC(International Data Corporation)报道[1],2017年全球智能移动设备出货量为14.6亿部,而安卓设备自2014年起常年占据全球智能移动设备年出货量的80%左右.安卓设备正是目前全球范围内使用最为广泛的智能移动设备.在此环境下,安卓设备的安全性显得尤为重要.
安卓系统的巨大市场吸引了大量的恶意攻击者,据McAfee报道[2],2017年新增移动恶意样本逾700万例,全球移动设备平均恶意软件感染率逾10%.与此同时,众多研究工作[6-8,11]提出各种利用自动化程序分析的方式进行恶意软件检测的方法.与之对应的,恶意软件作者开始采用对抗分析技术以应对上述分析检测工作.
对抗分析技术是指一系列不同种类的、能够干扰程序分析的技术手段.在安卓生态系统中存在大量公开免费的商业化加固服务.商业化加固服务为其用户提供一站式的加固服务,将一系列对抗分析技术自动化地附加到用户上传的样本之中.商业化加固服务的初衷是为了保护应用开发者的知识产权,防止应用遭到恶意的逆向修改及重打包.然而,商业化加固服务却遭到了恶意软件开发者的滥用.Duan等人[3]研究发现,在其获取的2010年至2015年的恶意样本中,13.89%的样本使用了对抗分析技术,其中约30%使用了商业化加固服务.由于安卓生态系统中商业化加固服务的存在,作为安卓生态系统中的下游环节的反病毒引擎正面临着与传统PC环境不同的挑战.与对抗分析技术对应,DexHunter[4],App-Spear[5]等研究提出了通用的自动化脱壳方案,旨在突破对抗分析技术的干扰,还原样本中隐藏的行为.
然而,目前学术界缺乏对现有安卓生态系统中薄弱环节的系统性研究,无法明确目前安卓生态系统安全性受到不同对抗分析技术影响的差别.因此导致反对抗分析技术的相关研究缺乏方向性,难以进行更为有效的反对抗分析研究.
为了实现此研究,本文设计并实现了自动化的加固工具AATPacker(Anti-Analysis Techniques Packer).AATPacker根据用户输入的参数选择不同的对抗分析技术,将不同的对抗分析技术代码自动化地插入用户指定的安卓应用程序之中.在有了AATPacker这一可指定选择附加不同对抗分析技术的自动化加固工具之后,方可对安卓生态系统的安全性受到不同种类的对抗分析技术的影响进行系统性的研究.
借助于AATPacker,本文对安卓生态系统安全性受到对抗分析技术的研究进行了深入的研究.目前,现有研究[3]仅对反病毒引擎受到商业化加固的影响进行了简要研究.而利用AATPacker,本文不仅能够对反病毒引擎受到各类对抗分析技术的影响进行更为深入全面的研究,而且首次将商业化加固服务纳入受对抗分析技术影响研究的范畴,对商业化加固服务本身受到不同种类的对抗分析技术的影响进行了系统化的实验研究.通过分析对比了不同种类的对抗分析技术对商业化加固服务以及反病毒引擎的安全性检测产生的影响,本文为将来的防御工作提供重点研究方向.
利用AATPacker,本文对来自F-droid1https://f-droid.org/的9个良性开源样本及来自GitHub公开仓库2https://github.com/ashishb/android-malware的22个已知恶意样本附加不同种类的对抗分析技术,共生成239个施加了不同种类组合的对抗分析技术的应用样本,对商业化加固服务及反病毒引擎进行实验,主要取得了如下发现:
1)商业化加固对上传样本进行了一定程度的安全性检测,但通过附加对抗分析技术将极大程度地降低其检测的有效性,恶意样本通过检测率由27.27%提升至81.82%
2)附加对抗分析技术能够显著降低恶意软件在反病毒引擎中的检出率,首次上传由AATPacker附加所有对抗分析技术的恶意样本,其平均检出率下降56.26%.而良性样本在使用对抗分析技术后被部分反病毒引擎的误报为PUP(Potentially unwanted program),部分样本甚至被误报为恶意软件.
3)使用商业化加固对反病毒引擎产生的干扰效果与使用AATPacker附加对抗分析技术相近.将AATPacker与商业化加固结合使用能进一步提升干扰效果,降低其检测有效性.
4)在不同种类的对抗分析技术中,动态代码加载技术能够对商业化加固与反病毒引擎中的安全检测环节均产生最为显著的对抗干扰效果.
综上所述,本文旨在对安卓生态系统的安全性受到对抗分析技术的影响进行研究,以找出目前安卓生态系统安全性的薄弱环节,为将来的研究提供方向性的指导.为实现此研究目的,本文设计实现了自动化加固工具AATpacker,以对实验样本可控地插入不同种类的对抗分析技术.基于上述发现,本文揭示了现有反对抗分析研究成果尚未在实际安卓生态系统中得到有效应用,对抗分析技术仍然能够对安卓生态系统中的安全性分析产生显著影响,不仅使恶意软件能够规避检测,还会使良性软件遭到误报.商业化加固服务作为对抗分析技术的供应者,其本身却缺少对对抗分析技术的反对抗能力,从而易使其提供的服务遭到恶意软件作者的滥用.上述安卓生态系统中的薄弱环节应作为将来反对抗分析技术研究工作的重点方向.
2 背景与相关工作
2.1 对抗分析技术
对抗分析技术是指一系列以干扰程序分析为目的的技术手段.程序分析可分为人工分析和自动化分析,自动化分析可主要分为静态程序分析和动态程序分析两类.在实际的应用中,可混合使用上述程序分析方法,相互结合形成如动静结合的程序分析等更加灵活复杂的程序分析方法.对抗分析技术针对程序分析过程中的某些弱点进行对抗,使程序分析无法继续进行或无法得到真实有效的分析结果.本文关注的对抗分析技术主要包含动态代码加载,反模拟器,反调试,完整性检查.动态代码加载主要针对静态程序分析,而后三者主要针对动态程序分析.
动态代码加载主要指安卓应用通过调用系统接口等方式,在运行过程中动态地加载Java层代码并执行的技术手段.被动态加载的代码通常以加密形式存放在安卓安装包(Android Package,在下文中简称为APK)文件中,在动态运行时进行解密并动态加载运行.被动态代码加载的代码在静态时无法被有效分析,进而能够规避静态的程序分析检测.在实际应用中,恶意开发者使用动态代码加载技术使其恶意行为免于被静态分析工具发现;而良性开发者使用动态代码加载技术旨在使其核心代码不直接暴露于攻击者眼下,增加攻击者对应用进行篡改的难度.
反模拟器是指通过检测运行环境是否处于安卓模拟器环境中,进而决定是否执行关键代码的技术手段.反模拟器技术通常通过检测系统调用返回值、检测模拟网络环境、检测底层模拟器、检测计算性能等方式进行[9].动态分析工具常部署在安卓模拟器环境中,以取得对设备更强的控制能力.恶意开发者正是利用这一特性,利用反模拟器技术使其恶意代码免于动态分析工具的检测;而良性开发者使用反模拟器技术以保护其真实用户群体免受恶意批量注册的虚假用户的损害.
反调试技术是指在运行过程中防止应用在处于被调试状态下运行关键代码的技术手段.反调试技术可通过检查进程调试状态和主动抢占调试等方式实现.当应用处于被调试状态时,调试者对应用有完全的掌控权,安全研究人员能够完全掌握应用所执行的所有代码,且能够绕过如反模拟器,完整性检查等其他针对动态分析的对抗分析技术;而恶意攻击者能够达到随意篡改和窃取应用数据的目的.
完整性检查是指在动态运行时,对应用是否被静态修改进行检查,进而决定是否执行关键代码.安卓应用需要经过对APK文件的签名后方可安装,此签名仅需使用自签名的证书即可.恶意攻击者可在反编译应用并篡改其内容后使用完全不同的自签名证书重新签名,被篡改的应用可以被正常的安装执行.此问题源于对安卓应用的签名只能保证在签名之后的APK并未被改动,而无法保证对应用进行签名者正是原应用开发者.完整性检查可通过在附加对抗分析技术时记录原DEX文件校验值或原签名证书信息,并在动态运行时进行相应的检查校验来判断应用是否在上次打包后被重新打包.恶意开发者使用完整性检查以规避基于静态插桩的动态程序分析;良性开发者使用完整性检查以避免应用被重打包.
综上所述,恶意开发者与良性开发者出于不同目的,均存在对对抗分析技术的需求.恶意开发者使用对抗分析技术对抗程序分析,延长其恶意软件的存活时间;良性开发者使用对抗分析技术保护其知识产权,使其应用不被破解盗版.在安卓生态系统中,存在大量的个人应用开发者.个人开发者并不都具有对对抗分析技术的了解,大量的商业化加固应运而生.商业化加固的本质是集合了一系列对抗分析技术,将其附加至应用开发者上传的应用中,使应用开发者在不需要关注相应技术细节的情况下,实现保护自身应用不被非法破解盗版的目标.商业化加固为了避免为恶意软件所用,通常都会进行对上传应用的安全性检测,拒绝为恶意软件提供相应的服务.
2.2 安卓生态系统
安卓生态系统是指由安卓应用从应用开发者到最终被用户使用的整个过程.安卓生态系统的一大特点是其中存在大量商业化加固服务,其直接为安卓应用开发者提供服务,位于安卓生态系统的上游.而反病毒引擎则位于安卓生态系统的下游环节,反病毒引擎以安全软件的形式存在于用户的终端设备中,作为保护用户不受恶意软件侵害的最后一道屏障.
安卓生态系统的安全性由商业化加固的安全性检查与反病毒引擎进行的安全性检测共同保障,任一环节如受到对抗分析技术的干扰,使恶意软件成功通过该环节的安全性检测,都将大大提升恶意软件最终损害用户的可能性.作为一个完整的生态系统,上下游环节中的安全性检测息息相关.商业化加固服务如为恶意软件所用,将极大地提升作为下游环节的反病毒引擎发现和识别恶意软件的难度.而如反病毒引擎为对抗分析技术所干扰,用户将直接暴露在恶意软件面前,极有可能受到恶意软件带来的损害.在研究对抗分析技术对安卓生态系统的安全性产生的影响时,应将安卓生态系统中的各个环节本身受到的影响及前后环节之间可能产生的影响都考虑在内.
2.3 相关工作
目前,已有多项研究提出面向安卓应用的通用自动化脱壳方案.DexHunter[4]认为安卓应用在进行动态代码加载时存在某些关键函数,为所有动态代码加载技术所必经,因此DexHunter在该函数中插入代码,在进行主动的类初始化调用之后,对动态加载的代码进行转储.
AppSpear[5]认为壳代码与原始应用代码的执行存在明显分界,壳代码将原始应用代码全部恢复后将执行流转交给原始应用代码.因此AppSpear选择应用的主活动(main activity)开始执行时作为收集原始代码的时间节点.AppSpear通过Dalvik虚拟机在内存中维护的关于应用代码的内存结构收集相应的数据结构信息,并重新由此重新构建DEX(Dalvik Executable)文件.
DexHunter和AppSpear都是通过修改安卓系统的方式进行相应的实现,可部署在真实的安卓设备中,从而避免受到反模拟器及反调试等对抗分析技术的影响.但随着商业化加固和其使用的对抗分析技术的发展,上述两篇工作的前提假设都已无法保证,已无法达成对现有商业化加固应用的有效脱壳.
DroidUnpack[3]基于全系统模拟,能够获取并重建操作系统级别和ART(Android Runtime)级别的语义信息,捕获实际执行的方法的代码.此外,基于捕获的操作系统级别的语义信息,通过对同一内存区域的写入和执行顺序的先后关系,判断是否存在脱壳,代码自修改,多层脱壳等技术.但由于DroidUnpack仅能覆盖实际执行的代码,存在代码覆盖率问题,且其基于模拟器的特性,会受到反模拟器技术的干扰,因此并不能在实际环境中用作解决商业化加固及对抗分析技术的终极方案.
此外,DroidUnpack中提到商业化加固会对反病毒引擎产生影响,降低反病毒引擎的有效性.但在DroidUnpack仅尝试对少量恶意软件进行商业化加固,并比较其加固前后的检出率.其仅考虑了反病毒引擎受到商业化加固的直接影响.与之相比,本文实现了自动化加固工具 AATPacker.借助于AATPacker,本文能够:
1)对商业化加固本身的安全性检测受到对抗分析技术的影响进行研究.
2)通过选择附加不同类型的对抗分析技术,比较不同类型的对抗分析技术之间产生影响的差异.
3)比较商业化加固及客制化加固(AATPacker)对反病毒引擎的影响差异.
4)对反病毒引擎进行了长时间的观察,探究对抗分析技术对反病毒引擎产生的影响随时间的变化.
3 AATPacker系统设计
本章将对AATPacker的系统设计进行阐述.AATPacker接受APK文件及用于指定不同对抗分析技术的程序参数作为输入,输出为自动化插入了根据参数选择的对抗分析技术的APK文件.与商业化加固一样,AATPacker的输出文件需要经过重新签名后方可安装至安卓设备中.AATPacker的系统结构如图1所示.
对于输入的APK文件,AATPacker首先使用Apktool3https://ibotpeaches.github.io/Apktool/对原应用进行反编译,得到表示应用程序代码的smali文件及包含应用基础信息的应用清单文件(AndroidManifest.xml).其次,AATPacker对应用清单文件进行解析,获取原应用的有关信息.
随后由控制模块对输入的参数进行解析,自对抗分析技术池中选取相应的技术,根据所选择的不同对抗分析技术,AATPacker将进行插入壳Application文件、插入对抗分析技术代码文件、加密由APK中单独抽取的原DEX文件、修改应用清单文件和写入AATPacker配置文件等操作,以将对抗分析技术附加至应用之中.对抗分析技术池包含多种类型的对抗分析技术,主要由对现有加固的样本的逆向分析及相关论文中提出的对抗分析技术综合提取生成.壳smali文件作为AATPacker在应用中所附加代码的起始点和控制中心,负责在应用动态运行时根据配置文件执行相应的对抗分析技术.
图1 AATPacker系统结构Fig.1 System architecture of AATPacker
最后,AATPacker再次使用Apktool将所有修改后的资源文件,会同所有未被修改的其他原有资源文件重新组装成APK文件.组装后的APK文件将失去原有的签名信息,需要经过重新签名后方可安装至安卓设备之中.
4 AATPacker实现
AATPacker主要由对抗分析技术控制模块和对抗分析技术池了两部分组成,本章将详细阐述其具体实现原理.
4.1 对抗分析技术控制模块
对抗分析技术控制模块主要负责AATPacker的整体执行控制,其主要负责对参数进行解析以选择对应的对抗分析技术、调用Apktool完成对APK文件的反编译及重新组合构建、对应用清单文件进行解析等操作.应用清单文件以xml格式存放,通过对其进行的解析,控制模块从中获取了应用的包名(package)以及原有的Application类名等信息.
Application类用于维护应用的全局属性,通常而言应用并不需要使用自定义的Application子类.部分应用可能为了维护某些特殊的全局变量因而需要使用自定义的Application类,在其提供了具体实现后,需要在应用文件清单中<application>标签下的“android:name”属性中提供其实现的Application子类名.
由于AATPacker需要插入壳Application类作为AATPacker在动态运行时的入口,为保证应用能够正常运行,控制模块需要保存原有的Application类信息,并在壳Application完成其任务后恢复原有Application类.为了达成此目的,控制模块记录了原有Application的类名.
4.2 对抗分析技术池
对抗分析技术技术池包含壳Application以及所有对抗分析技术的smali实现,以及附加相应代码需要进行的准备工作及收尾工作.以下将详细阐述壳Application及每项对抗分析技术的具体实现方式.
4.2.1 壳 Application
AATPaker插入的对抗分析技术以应用的Application类作为入口点.我们通过插入由我们实现的壳Application来控制对抗分析技术在应用运行时的执行.为了保证应用能够正常运行,我们需要在我们实现的壳Application完成相应工作后,恢复应用原有的Application类的运行.壳Application通过继承android.app.Application类的方式实现.对抗分析技术应在应用运行过程中尽可能早的时间段执行,以尽可能地产生有效的对抗分析效果,且保持原应用正常运行.出于此目的,AATPacker选择覆盖attachBaseContext方法,在其中插入执行对抗分析技术.attachBaseContext将在应用启动的较早阶段被执行,其执行时机早于Application类的onCreate方法及应用中其他组件的任意方法.
恢复执行原Application的算法将在壳Application中被覆盖的onCreate方法中被调用,其主要实现逻辑如下.
总体而言,我们需要将壳Application相对应的对象从应用的运行环境中移除,初始化生成原有Application对象(android.app.Application类),并将生成的原有 Application对象加入应用的运行环境.
我们通过反射的方式,由当前ActivityThread.mInitialApplication对象获取壳Application对象,将其从ActivityThread.mAllApplications列表中删除.通过LoadedApk.makeApplication方法完成原有Application对象的初始化,将mInitialApplication赋值为原Application对象并将其加入mAllApplications列表.此外,我们还需遍历ActivityThread.mProviderMap的值域,将完成了初始化的原Application对象赋值给ActivityThreadMYMProviderClientRecord.mLocalProvider.mContext变量,以将原Application对象作为应用的content provider的上下文使用.
4.2.2 动态代码加载
动态代码加载需要对原DEX文件进行加密存放,并在动态运行时将其解密存放于私有目录中,并通过替换Class-Loader的方式对原DEX进行加载.具体而言,需要初始化一个DexClassLoader对象,其dexPath参数为解密后的DEX文件路径,其parent ClassLoader参数为当前的ClassLoader.并将此新生成的DexClassLoader对象替换当前应用的默认ClassLoader.当前应用的ClassLoader信息存放于LoadedApk类中的mClassLoader对象中,而LoadedApk对象可以通过当前ActivityThread对象的mPackages对象利用当前应用的包名获得.
4.2.3 反模拟器
反模拟器技术可通过检测系统调用返回值、检测模拟网络环境、检测底层模拟器、检测计算性能、检测软硬件组件等方式检测运行环境是否处于安卓模拟器环境中,AATPacker式判断运行环境是否为模拟器.Morpheus[10]中提供了10个能够判断运行环境是否为虚拟机的特征文件.经过实验,AATPacker对其进行了改进,选择了1个来自Morpheus的和4个全新的特征文件作为判断运行环境是否为模拟器的标准.具体文件请见表1.
表1 特征文件列表Table 1 List of feature files
为了验证特征文件的有效性,本文构建了用于收集相关数据的安卓应用,对71款真机与7款模拟器进行了测试.其中真机测试利用腾讯云4http://wetest.qq.com/product/basic-compatibility-testing及阿里云5https://www.aliyun.com提供的兼容性测试服务完成,能够较好的覆盖目前较为主流的机型.在模拟器方面,本文选取了7款较为流行的安卓模拟器,详情见表2.
表2 模拟器列表Table 2 List of Android emulators
这些模拟器覆盖了arm架构和x86架构,及qemu和vbox底层模拟器.本文对上述共78款安卓设备进行特征文件总数量的统计.通过实验,本文发现所有真机至少存在其中3个特征文件,而所有模拟器至多仅存在其中1个特征文件.因此,这些特征文件能够有效检测运行环境是否为安卓模拟器.
4.2.4 反调试
AATPacker采用检测进程是否处于调试状态的方法以实现反调试对抗分析技术.由于安卓应用主要由Java代码构成,但同时可以通过JNI(Java Native Interface)的方式调用本地代码,因此需要同时检测是否存在Java调试器和本地调试器.对于Java调试器的检测,可以通过调用android.os.Debug类的isDebuggerConnected方法进行判断.对于本地调试器的检测,AATPacker采用了对于/proc/self/task目录下所有的pid,检查对应/proc/[pid]/status文件中 TracerPid属性是否为0的方式进行判断.
此外,调试工具可能并非在应用启动时已存在,对此选用基于特征文件的对底层模拟器及软件组件进行检测的方AATPacker创建了新的线程,定期执行调试状态检查.
4.2.5 完整性检查
AATPacker采用判断应用签名信息是否与加固时一致以判断应用完整性是否得以保障.AATPacker在加固时利用keytool工具提取原签名证书的公钥信息并加以保存;在动态运行时,通过调用PackageManager类的getPackageInfo方法获取当前应用的签名证书信息.将动态获取得到的当前应用签名证书信息与加固时保存的原签名证书信息进行对比,以判断应用完整性是否被破坏.
5 实验设计
为了回答对抗分析技术会对安卓生态系统的安全性检测产生如何的影响,以及不同类型的对抗分析技术的效果是否存在差异的问题,本文利用AATPacker,设计对安卓生态系统不同环节的安全性检测进行实验.
对抗分析技术对安卓生态系统的影响可能并不仅仅发生在恶意样本上,良性样本在使用对抗分析技术后可能同样会受到影响.为了有效分析对抗分析技术对安卓生态系统产生影响,本文将分别对良性样本和恶意样本利用AATPacker附加对抗分析技术,并分别对商业化加固和反病毒引擎进行实验.在本章的后续小节中,将对本文采用的实验原始样本集,面向商业化加固服务的实验及面向反病毒引擎的实验设计进行详细的阐述.
5.1 原始样本集
本文进行实验的原始样本集分为良性样本和恶意样本两部分,其中良性样本为随机选自F-Droid6https://f-droid.org/的9个开源样本,本文在获取其源码后编译生成相应的APK文件.恶意样本为来自GitHub公开仓库7https://github.com/ashishb/android-malware的22个恶意软件家族,对于每个恶意软件家族,本文从仓库中随机选取其中的一个APK样本作为其代表.此外,由于完整性检查技术要求应用加固前后使用相同的证书进行签名,本文对所有样本一一对应地随机生成了证书,并对其进行签名.在对恶意样本签名之前,需要移除其原有签名,并对其重签名.在之后的所有实验中,对抗分析技术的附加对象为经过签名的良性样本和重新签名的对抗分析技术.
5.2 商业化加固服务实验
商业化加固或出于企业责任,或出于维持自身于相关行业的声誉,或出于为用户提供对外包的第三方代码检测等目的,随着商业化加固的不断发展,主流商业化加固都会对用户上传的样本进行安全性分析,拒绝为恶意软件所用[3].
据Duan等人[3]研究发现,在其获取的2010年至2015年的恶意样本中,使用了对抗分析技术的样本中约30%的恶意软件使用了商业化加固服务.其中,超过50%的样本使用的是梆梆加固.因此,本文选取了使用率最高的梆梆加固作为商业化加固服务的代表,为本文实验的目标商业化加固服务.
商业化加固实验旨在探究作为对抗分析技术提供者的商业化加固,其本身的安全性检测本身是否会受到对抗分析技样本中任意一个通过商业化加固服务的安全性检查,则视为对于该样本,附加对抗分析技术能够通过商业化加固的安全性分析.通过数量及通过率见表3.术的影响,使恶意软件能够通过其检测,并得以进行商业化加固.如果存在影响,进一步探究不同种类的对抗分析技术的影响分别如何.得益于本文实现的自动化加固工具AATPacker,本文能够对样本在不受任何安全性检测制约的前提下,按照需求附加不同种类的对抗分析技术组合,这是文献[3]中无法做到的.
本文首先对恶意样本进行重新签名,对每一个经过重新签名的样本,对其在五种不同参数配置下生成带有对抗分析技术的样本.五种配置分别为:单独附加动态代码加载,单独附加反模拟器,单独附加反调试,单独附加完整性检查,同时附加上述四种对抗分析技术.因此,对每一份恶意样本,本文生成了原始恶意样本、重签名恶意样本及上述五种附带对抗分析技术的样本共7份样本.并将所有样本上传至梆梆加固,观察其是否被拒绝加固.
5.3 反病毒引擎实验
反病毒引擎作为保护用户的最后一道屏障,其对样本给出的断言将直接影响应用和用户,漏报将使用户受到恶意软件的损害,误报使良性应用被误杀,对应用开发者造成损失.
本文利用VirusTotal8https://www.virustotal.com/平台对样本进行持续的观察分析.VirusTotal平台提供60余种反病毒引擎对上传样本的检测结果,并保持反病毒引擎病毒库的持续更新.
在反病毒引擎实验中,本文选取良性样本及恶意样本共同作为原始样本集.对于良性样本,本文意图考察其经过商业化加固后是否会被反病毒引擎误报.对于恶意样本,本文意图考察其在附加对抗分析技术后是否会被反病毒引擎漏报.对于每个良性样本,本文选取其原始样本及经过梆梆加固的样本作为样本集.对于每个恶意样本,本文选取在商业化加固服务实验中所描述的7种样本组合,以及其所有通过商业化加固能够得到的样本.由于并非所有上传商业化加固服务的样本均通过了商业化加固的安全性检测,因此对于不同样本其通过商业化加固得到的样本数不等.
本文利用VirusTotal平台提供的接口,实现了Python脚本,每日对上述所有样本进行重新扫描,并获取其最新的检测报告.随后,将其每日的检测报告详情储存于MySQL数据库中.本文对其检测结果进行分析,以回答关于对抗分析技术对反病毒引擎影响情况的问题.
表3 商业化加固通过率Table 3 Success rate of commercial packing
可以看到,商业化加固具有一定的安全性检测,仅约27%的原始恶意样本和重签名样本能够通过其安全性检测.但在附加对抗分析技术后,通过商业化加固的安全性检测的比例大幅提升至约82%.对抗分析技术对商业化加固的安全性检测产生了极大的干扰,使恶意软件能够利用商业化加固,更有效地隐蔽自身的恶意代码.
其次,本文进一步对不同种类的对抗分析技术通过商业化加固的安全性检测的比例进行比较,不同种类的对抗分析技术组合,与原始样本及重签名样本的通过率如图2所示.
图2 不同种类对抗分析技术通过率对比Fig.2 Comparison between different techniques
6 实验结果
基于上一章所述的实验设计,本章将阐述取得的实验结果,并对其进行进一步分析,探讨安卓生态系统各环节中需要对对抗分析技术着重关注的重点.
6.1 商业化加固服务实验
对于商业化加固服务实验,本文上传了来自22个家族的,附加了不同对抗分析技术组合的共154个样本,其中有67个样本通过了商业化加固的安全性检测,总体通过率为45.3%.首先,本文进行原始样本、重签名样本及附加对抗分析技术后的样本通过商业化加固的数量及比例的对比.其中对于每个样本,若其五个按照不同配置附加对抗分析技术的
在原始样本通过率仅有27.27%的情况下,不同种类的对抗分析技术均能够显著提高样本通过商业化加固服务安全性检查的成功率.其中附加动态代码加载技术与附加所有对抗分析技术取得的效果相同,均能够将通过率提升至63.64%.其作为对商业化加固影响最大的对抗分析技术,应该进一步引起商业化加固服务的关注.
综上所述,对抗分析技术能够将已知恶意软件通过商业化加固的比例由27%提升至82%,其中对抗分析技术的提升效果最为显著.对抗分析技术能够严重干扰商业化加固的安全性检测,使其为恶意软件所用,进一步加大恶意软件对安卓生态系统的危害.商业化加固作为对抗分析技术的提供者,更应保护其本身的安全性检测免于对抗分析技术的干扰.
6.2 反病毒引擎实验
对于反病毒引擎实验,本文基于9个良性样本和22个恶意样本,生成了商业化加固后的良性样本及经过AATPacker或商业化加固的恶意样本总计239个.持续观察在首次上传后20天内的检测报告,结果如下.
6.2.1 良性样本实验
此部分实验包含对9个良性样本和与之对应的9个经过梆梆加固的样本的持续观察.检出结果如表4所示,其中若样本在观察周期内存在反病毒引擎对其给出阳性结果(检出恶意软件),则计入阳性样本数统计.同理,如其被检测为PUP或其他恶意软件,则计入相应统计.
9个原始良性样本在整个观察周期内均无任何检出,符合其做为良性样本的属性.但对于所有9个加固样本,某一反病毒引擎自首次上传起,始终将其标注为“PUP.HighConfidence”.对于其中一个加固样本(sha256:ff30aa48 a2d3491 a5a02 ecea4307693257 d514b8fb7 ecd9bb616279512 a5d922),在其原始样本无任何检出的情况下,自第12个观察日起出现反病毒引擎将其标注为恶意软件.在第20个观察日,共有13家反病毒引擎对其给出阳性结果,其中3家反病毒引擎将其识别为“SmsSpy”恶意软件.
表4 良性样本检出数Table 4 Detection of benign samples
存在反病毒引擎将进行商业化加固的样本标注为PUP,说明部分反病毒引擎已对商业化加固产生关注,但由于无法分析样本内容,仅能给出存在潜在威胁的结果.更有甚者,由于反病毒引擎无法有效分析经过商业化加固的样本,可能导致样本受到其他恶意样本的影响,被识别标注为与其本身毫无相关的恶意样本,遭到误报,严重影响良性应用的正常运行.
6.2.2 恶意样本实验
此部分实验包含对22个原始恶意样本,其重签名样本,经过AATPacker附加对抗分析技术的样本以及通过商业化加的样本共221个.本文将样本分文经过AATPacker加固的样本和经过商业化加固的样本两部分比较对抗分析技术对反病毒引擎的影响.首先对恶意样本本身,其重签名样本,5组AATPacker加固样本等共7组154个样本按照上述分组统计平均日检出率,结果如图3所示.
图3 AATPacker加固恶意样本检出率Fig.3 Detection rate of AATPacker packed malware
总体而言,附加所有对抗分析技术的样本和附加动态代码加载的样本检出率相近;附加反模拟器,完整性检查和反调试的样本检出率相近.在上传首日,附加对抗分析技术能够明显降低样本检出率,其中附加所有对抗分析技术和附加动态代码加载技术的样本,相对于重签名样本,检出率分别下降56.26%和55.15%,对反病毒引擎具有明显的对抗效果.随后,所有带有对抗分析技术的样本的检出率均不断提升.在首次上传后第10日起,各样本检出率趋于稳定,附加不同对抗分析技术相对于重签名样本检出率降低约6%和20%.
对于经过商业化加固的样本,由于并非所有样本都能够通过商业化加固的安全性检测,平均检出率受不同样本本身检出率影响,直接展现平均检出率并不能客观反映对抗分析技术产生的干扰.本文以不同对抗分析技术为组,统计同一组内每一样本相对于其重签名样本的检出率降低率,根据各组样本数不同对其计算平均降低率,以此体现不同对抗分析技术与商业化加固结合后产生的影响,降低率越大说明对反病毒引擎的影响越大,见图4.
图4 商业化加固恶意样本检出率的降低率Fig.4 Reduction rate of the detection rate of commercial packed malware
与使用AATPacker加固类似,使用商业化加固也存在对抗分析效果不断减弱的现象.最终单独使用商业化加固能够使恶意样本检出率降低约20%,其效果与AATPacker相似.在使用AATPacker进行加固后再次进行商业化加固能够进一步提高检出率的降低率.在附加商业化加固后,依然存在附加所有对抗分析技术的样本和附加动态代码加载的样本检出率相近;附加反模拟器,完整性检查和反调试的样本检出率相近的现象.与单独使用AATPacker类似,使用动态代码加载技术与商业化加固结合能够最大程度地降低检出率,最终检出率降低约30%.
7 总结
本文对安卓生态系统安全性受到对抗分析技术的影响进行了系统性的研究.为实现此研究,本文设计并实现了自动化加固工具AATPacker,能够对安卓应用有选择地附加不同种类对抗分析技术.基于AATPacker,本文揭示了现有研究工作尚未在实际安卓生态系统中得到足够应用,对抗分析技术仍能起到对抗分析效果.在各类对抗分析技术中,动态代码加载产生的影响最为显著.而作为对抗分析技术提供者的商业化加固服务,其本身缺乏对对抗分析技术的反对抗,使其服务易于被恶意软件作者滥用,进一步加大检测分析恶意软件的难度.上述安卓生态系统中的薄弱环节应作为将来反对抗分析技术研究工作的重点方向.