针对Android移动应用的恶意加密流量标注方法研究

何高峰,司勇瑞,徐丙凤

(1.南京邮电大学 物联网学院,南京 210003; 2.东南大学 计算机网络和信息集成教育部重点实验室,南京 211189;3.南京林业大学 信息科学技术学院,南京 210037)

0 概述

随着移动互联网的迅速发展,Android智能终端已经成为日常社会活动的重要辅助工具,与此同时,Android智能终端的广泛使用也吸引了众多攻击者的目光,造成各类恶意移动应用攻击事件层出不穷。如2019年趋势科技安全团队在Google Play中检测出恶意应用Flappy Birr Dog,其会窃取用户的短信、联系人信息以及截屏、录音等敏感性文件,对全球196个国家都造成了严重的影响[1]。恶意移动应用现已普遍采用HTTPS等加密流量进行网络数据传输从而躲避检测[2],这给移动网络和移动用户的安全防护带来了巨大的挑战。

为了从加密网络流量中识别出恶意移动应用,研究人员提出多种基于机器学习的检测方法,如文献[3-5]等。此类检测方法的共同流程是同时运行恶意移动应用和正常移动应用,采集其产生的网络流量作为数据样本,从收集的网络流量样本中提取检测特征,利用支持向量机等机器学习方法对检测特征进行训练,从而得出检测模型。再利用检测模型对未知流量进行分类检测,判定未知流量是否由恶意移动应用产生。在上述流程中,准确的网络流量采集是检测方法的基础,这是因为机器学习分类方法的有效性依赖于数据标注的正确性[6]。

然而,现有工作对恶意移动应用的流量标注研究较少。实际上,已有相关研究均将恶意移动应用产生的所有网络流量直接标注为恶意流量,并对其进行特征提取和建模分类,但该方法会产生较多的错误标注,如对公开的恶意移动应用网络流量数据集CICAAGM[7]进行分析时,150个恶意移动应用总共产生477条TLS(Transport Layer Security)流量,但其中多数TLS流量都具有Google的合法证书。进一步利用TLS证书的别名选项排除Google和Facebook中的正常流量,剩余的恶意流量数目仅有196条。在此案例中,若将所有加密TLS流量均标注为恶意流量,则会产生大量的错误样本标注数据,从而影响最终检测结果。究其原因,多数Android恶意移动应用通过重打包方式形成[8],黑客攻击者通常选取对热门移动应用进行反编译并加入恶意代码,再对修改后的代码和资源文件进行重新打包发布,诱骗用户下载运行。因此,移动用户在运行该恶意移动应用时,原有代码也将被执行以完成主体功能,从而产生正常交互网络流量。这类流量与恶意代码无关,应当标注为正常流量,进而使得恶意流量样本数据集更加精确。

为区分恶意移动应用产生的加密网络流量为恶意流量还是正常流量,本文提出一种针对Android移动应用的恶意加密流量标注方法。通过TLS握手协议等特征筛选出可疑加密流量,再对恶意移动应用进行反编译,利用代码分析对可疑加密流量进行确认,从而标注出恶意加密流量,以减少错误标注。

1 相关工作

现有研究工作提出多种恶意移动应用检测方法,如文献[9]提出一种三步骤检测方法。首先,识别HTTP POST/GET请求报文;然后,在识别出的报文中查找用户身份敏感内容,如国际移动用户识别码IMSI和移动设备国际识别码IMEI等;最后,若检测出敏感内容,使用WHOIS工具查询远端服务器的注册信息,并判断远端服务器是否为攻击者服务器。若远端服务器为攻击者服务器,则判定当前流量为恶意移动应用产生的恶意流量,反之则为恶意移动应用产生的正常流量,该方法需要检测报文内容,因而只适用于明文流量,无法应用于加密流量的检测判断。

针对加密网络流量的检测判断,文献[10]以平均报文长度、流平均长度、报文时间间隔等网络流量统计值为检测特征,利用机器学习分类方法对Android恶意移动应用进行检测。在测试的48个移动应用样本中(包括正常移动应用和恶意移动应用),总共成功检测出45个样本,准确率为93.75%。文献[11]以发送和接收的报数字节数、网络状态(WiFi、蜂窝等)、应用状态(前台、后台等)为移动应用的行为特征,利用机器学习方法建立恶意移动应用检测模型,实验结果表明检测率超过80%,误报率小于10%。

文献[12]提出一种基于网络行为对比的重打包应用检测方法。通过选择类似应用将待检测应用的网络行为与类似应用的网络行为进行比对,若行为差别超过一定阈值,则判断为重打包应用。该检测方法以网络行为作为考虑对象,不涉及流量内容,因而适用于加密流量的检测,但如何选择合适的类似应用是一项挑战。为此,文献[13]提出一种基于移动边缘计算的恶意重打包应用检测方法,在移动边缘计算节点处对不同移动设备产生的同一应用流量进行聚类分析,从而能够准确发现重打包应用。文献[14]提出基于攻击图的移动应用进行安全评估。文献[15]构建了移动应用安全防护生态链。文献[16]使用域名对恶意移动应用进行检测。但上述研究工作均未涉及恶意加密流量的标注问题。

传统的网络安全研究中已注意到恶意网络流量的标注问题。文献[17]提出一种利用网络攻防比赛来标注网络攻击数据集的思路,并说明了相关系统的组成部分和功能。文献[18]针对恶意DNS查询流量,提出一种半人工方式的标注方法。文献[19]利用黑名单、安全报告和沙盒分析对恶意网络流量进行标注,进而提高机器学习分类方法的检测效果。现有工作主要解决传统网络攻击流量的标注问题,对本文研究具有重要的启发和借鉴意义。

2 Android移动应用恶意加密流量标注

2.1 方法概述

本文提出Android移动应用恶意加密流量标注方法的整体思路,具体如图1所示。首先,根据端口号和报文熵值判断流量是否为加密流量,若为加密流量,则依据TLS握手协议解析Client Hello报文和服务器端返回的证书等内容,若解析失败或握手协议内容异常,则标记该加密流量为异常流量。然后,对移动应用APK文件进行反编译,在代码中检索对应域名或IP地址。最后,以对应域名或IP地址所在函数为中间节点,构建程序控制流程图,并在图中寻找是否含有敏感函数调用,若含有敏感函数调用则标注该流量为恶意加密流量。

图1 本文标注方法的整体思路

在上述基本思路中,有2点需要加以解释。一是网络流量与移动应用的对应关系,在采集移动应用网络流量数据时会单独运行某移动应用程序,并利用VPN程序排除其他干扰流量[13],因而可以明确网络流量所对应的移动应用。二是恶意移动应用多数调用Android系统函数来完成攻击目的[20],如调用读取短信、日历或联系人的系统函数来窃取用户数据,或调用发送短信、拨打电话相关系统函数进行恶意扣费等,因此本文利用是否含有敏感函数调用来判断是否存在恶意行为。

2.2 异常加密流量的检测

从图1可以看出,标注加密网络流量时需判断该流量是否为加密流量,以及是否为异常流量。Android移动应用多数利用HTTPS协议进行数据的加密传输[21],判断服务器端口是否为443,若是,则判定该流量为加密流量。值得注意的是,若443端口流量不属于加密流量,后续的代码分析将会对其进行排除。若远程端口不为443,则计算报文内容载荷的熵值[22-23],具体过程如下:

针对网络流f,合并所有报文内容(不考虑报文头部信息),形成长度为N的字节串,即网络流f内容大小为N字节。计算每一字节对应的数值(0～255),并计算数值ni出现的频率。如第一个字节对应的数值为3,且在N个字节中,数值3一共出现10次,则数值3的频率计算为10/N,记频率pi为ni/N,则网络流f的内容载荷熵值H(f)的计算方法如式(1)所示:

(1)

其中,m为不同数值的个数。

理想情形下的所有数值都均匀分布,此时熵值最大为8。计算H(f)与8的差值d,若d小于设定的阈值τ,则判定该流量为加密流量,d的计算方法如式(2)所示:

d=8-H(f)

(2)

根据文献[23]可知,当N≥1 024时,加密的网络流f的内容大小大于1 KB时,H(f)值无限趋近于8,在实际中易于满足该条件。因而本文方法对τ值的设定没有严格要求,实验中τ值设定为0.8。

识别出加密流量后,统一执行TLS协议解析,解析Client Hello报文和服务器端返回的证书内容。若Client Hello、证书内容或服务器自身异常,则判定该加密流量为异常流量。具体的加密流量异常判断条件如下:

1)TLS协议解析失败。

2)或者Client Hello报文中的密码套件支持3DES、RC4等不安全加密算法。

3)或者解析服务器的证书内容失败。

4)或者服务器证书为自签名。

5)或者服务器位于云平台中,如Google App Engine、百度云盘等。

6)或者服务器不在Alexa top 200中。

上述6个判断条件为“或者”关系,只需满足其一,则可判定为异常加密流量。异常加密流量判定的背后逻辑是:正常Android移动应用多数基于HTTPS(HTTP+TLS)协议进行数据的加密传输,且客户端优先选择椭圆曲线加密算法等高安全算法,以保证通信内容的安全。而恶意移动应用利用加密流量仅仅是为了躲避检测,且多数自签名其证书以降低攻击成本和隐藏自身信息(购买和维护X.509证书需要一定费用,且泄露攻击者自身信息)[24-25]。由于黑客趋向于借助公共云平台隐藏身份[26],且黑客自身部署的服务器排名较低,因而上述6个条件能够有效检测出异常加密流量。

2.3 恶意加密流量的确认

检测出异常加密流量后,执行代码分析确认该流量是否为恶意流量,具体步骤如下:

输入流量域名或IP地址A以及对应的移动应用APK文件F

输出流量标注

//初始化

步骤1判定APK文件F是否存在全局程序控制流程图G,若不存在,则反编译APK文件F,构建全局程序控制流程图G并保存。

步骤2在反编译后的源代码中寻找IP地址A,确定IP地址A所在的函数Fun(A)以及产生该流量的参数变量Par1,Par2,…,Parp。

步骤3通过函数调用判断与IP地址A的网络连接是否为加密连接,若不为加密连接,则返回。

//前向搜索(确定参数是否敏感)

步骤4在函数Fun(A)中检查参数Par1,Par2,…,Parp的赋值情形,若在赋值过程中调用了敏感函数,返回“恶意”标注。

步骤5在全局程序控制流程图G中,以函数Fun(A)为起点,深度优先向前遍历所有父节点。

步骤6在父节点中,检查对参数Par1,Par2,…,Parp的隐形赋值情况,若在赋值过程中调用了敏感函数,返回“恶意”标注。

步骤7若遍历结束,返回“正常”标注。

//后向搜索(判定后续是否有敏感函数调用)

步骤8在全局程序控制流程图G中,以函数Fun(A)为起点,向后遍历所有子节点。

步骤9若子节点中存在敏感函数调用,返回“恶意”标注。

步骤10若遍历结束,返回“正常”标注。

在上述步骤中,初始化阶段的核心功能是反编译APK文件F,然后针对得到的源代码,构建全局程序控制流程图G。APK文件名称、反编译后的文件与全局程序控制流程图将一一对应保存,便于后续分析使用。程序控制流程图反映程序调用关系,示例如图2所示。Android应用的程序控制流程图可由Soot框架自动生成,本文不再进行赘述。

图2 程序调用关系示例

在初始化阶段的步骤2中,利用域名或IP地址A定位至特定函数。但在实际中,域名可以动态生成(通过参数赋值或多个参数串联而成,如new URL(str)),无法直接进行匹配查询。因此,在生成全局程序控制流程图时,对于网络访问类函数,需要对访问地址参数进行数据流分析,进而得到域名的完整表示,具体流程同前向搜索类似。

执行完初始化后,进行前向搜索,确定函数参数是否含有敏感数据。参数变量Par1,Par2,…,Parp表示Android系统提供的网络相关函数,如setURI函数的参数。在当前节点所在的函数Fun(A)中寻找对Par1,Par2,…,Parp的赋值语句,若在赋值语句的右边存在变量Var,则继续向上遍历其父节点,寻找对变量Var的赋值语句(即对参数Par1,Par2,…,Parp的隐形赋值)。以此类推,形成递归分析,从而最终确定参数Par1,Par2,…,Parp的具体值,如图3所示。若在赋值路径中存在敏感函数调用,则返回“恶意”标注。

图3 参数值回溯流程

在后向搜索中,无需考虑参数问题,只需判断子节点是否为敏感函数。即在网络通信结束后,根据通信内容,恶意移动应用会执行相关攻击代码。此行为在远程控制、广告展示类恶意应用中较为常见。恶意流量的确认算法中的敏感函数具体有startService()、loadClass()、sendTextMessage()、getContentResolver()、query()、mkdir()、delete()、ListFiles()等。完整的函数列表及其在恶意应用的常见应用解释见文献[27]的第4节内容,但不包括其中的HttpURLConnection 和Sockets等网络相关函数。

3 实验结果与分析

为了测试本文方法的准确性,实验重点对重打包类型恶意应用进行分析。这是由于可以通过比对原始应用和重打包应用的代码,确定恶意代码位置,从而明确网络流量的真实类别。即由原始代码产生的网络流量为正常流量,而由额外添加的代码所产生的网络流量为恶意流量,进而为本文方法的测试提供基准值。

从公开数据集AndroZoo[28]中下载了300个合法移动应用和300个对应的重打包移动应用。针对下载的600个移动应用,首先反编译其代码,经文件比对定位出恶意代码位置。代码反编译由Jadx工具完成,代码文件的比较通过WinMerge来实现。然后,将重打包应用运行于真实的智能手机中,捕获其产生的网络流量。若运行出错(如移动应用版本较早,无法运行于最新手机),则根据移动应用的API版本,配置对应虚拟机进行安装运行。移动应用的安装运行均自动化进行,且安装过程使用adb install命令实现。安装完成后,使用开源的DroidBot自动点击产生点击事件,运行移动应用不同组件。

如图4所示,移动应用流量的采集由网关完成。网关运行Ubuntu 16.04操作系统,并配置WiFi热点功能,智能手机及虚拟机均通过无线网络连接至该网关。在网关中,部署tshark软件进行网络流量报文的抓取。流量域名的提取同样由tshark完成,具体命令为tshark-e dns.qry.name。本文重点解决加密流量的标注问题,在流量采集中仅保存加密流量。首先判断服务器端口是否为443,若不为443,则计算流载荷的字节熵值。若熵值大于7.2,即式(2)中的τ值为0.8,则标记为加密流量。对于采集的加密流量统一按照TLS协议进行解析,若解析成功,则标记为TLS流量,否则标记为其他类型的加密流量。结果发现,实验中采集的TLS流量数量为1 523条,其他类型的加密流量数量为116条。

图4 采集网络流量环境设置

针对采集到的其他类型的加密流量,进一步分析其对应的移动应用源代码,确定其是否为真正加密类型的网络流量。在116条其他类型的加密流量中,总共有79条流量为加密流量,其产生的方式为使用AES或自定义的加密算法对数据内容进行加密,通过Java Socket编程将数据发送至远程服务器。而剩余的37条网络流量为压缩流量,数据内容经gzip等压缩后发送至服务器。后续的分析仅针对1 602(1 523+79)条加密网络流量进行。

针对筛选后的加密网络流量,利用2.2节中的异常判断条件按照先后顺序匹配检测,若满足其中一项,则判断异常并停止后续匹配,检测结果如表1所示。

表1 异常检测结果

对表1中的422(79+15+217+111)条异常加密流量执行恶意流量确认算法步骤进行确认。使用Soot生成全局程序控制流程图,然后对图执行前向搜索和后向搜索。全局程序控制流程图规模庞大,难以直接展示,因而将数据保存为XML格式。利用Java解析XML文件进行节点的遍历操作,在前向遍历时,需要结合源代码确定变量赋值语句,此部分由人工方式完成。

代码分析结果表明,总共有341条加密流量为恶意流量,剩余的81条加密流量为正常流量。进一步同基准值进行对比,结果如表2所示。

表2 基准值比对结果

从表2可知,在异常检测阶段检测出的正常流量均为正常加密流量,从而减少了恶意流量确认部分的分析负载。在恶意流量确认阶段,针对422条异常加密流量,共产生了28条误报流量,误报率为6.6%。与未采用本文方法标注的1 602条恶意加密流量相比,采用本文方法标注的恶意加密流量仅有341条,总共减少了1 261条错误标注,占总数量的78.7%。由此可知,本文方法能有效减少错误标注,从而构建出更加精确的恶意移动应用网络流量数据集。

4 结束语

本文提出一种针对Android移动应用的恶意加密流量标注方法,判断网络流量是否为加密流量,对于非加密流量,使用传统的DPI技术对其标注,而对于加密类型的流量,依据TLS协议对其解析并利用TLS握手消息等内容判断该流量是否异常。若该流量异常,则对相应的恶意Android移动应用进行反编译,构建程序控制流程图,并分析该加密流量是否涉及敏感操作。若该加密流量的参数为敏感数据或执行完网络通信后调用执行敏感函数,则标注该加密流量为恶意加密流量。针对300个重打包类型恶意应用进行测试,分析结果表明,未采用本文方法总共采集1 602条加密流量,采用本文方法只有341条流量被标注为恶意加密流量,且仅有28条为误报流量。因此本文方法可准确地标注恶意Android移动应用网络流量。

本文仅针对重打包类型恶意Android应用进行分析,后续工作将对更多类型的恶意移动应用进行测试,并研究更加合适的异常加密流量判断标准,从而减少异常加密流量的数量,提升代码分析性能,同时识别出APT攻击类型加密网络流量。基于形成的准确数据集,将开展针对单条恶意加密流量的在线检测研究,以更好地保护移动应用和移动网络安全。