0-abstract
恶意应用程序对Android平台的安全性构成了威胁。这些应用程序的数量和多样性不断增长,使得传统的防御措施在很大程度上无法发挥作用,因此,Android智能手机经常无法免受新型恶意软件的攻击。在本文中,我们提出了DREBIN,这是一种用于检测Android恶意软件的轻量级方法,可以直接在智能手机上识别恶意应用程序。由于有限的资源阻碍了在运行时监视应用程序,因此DREBIN进行了广泛的静态分析,收集了尽可能多的应用程序功能。这些功能嵌入在联合向量空间中,因此可以自动识别表示恶意软件的典型模式,并将其用于解释我们方法的决策。在对123,453个应用程序和5,560个恶意软件样本的评估中,DREBIN的性能优于几种相关方法,并在几乎没有误报的情况下检测到94%的恶意软件,其中为每次检测提供的解释均揭示了检测到的恶意软件的相关属性。在五种流行的智能手机上,该方法平均需要10秒钟进行分析,使其适合直接在设备上检查下载的应用程序。
1-introduction
Android是当今最流行的智能手机平台之一。在不同市场中有数十万个应用程序,它为用户提供了丰富的功能。不幸的是,运行Android的智能手机越来越受到攻击者的攻击,并感染了恶意软件。与其他平台相比,Android允许从未经验证的来源(例如第三方市场)安装应用程序,这使得攻击者更容易捆绑和分发带有恶意软件的应用程序。根据最近的一项研究,仅在2012年,就发现了超过55,000个恶意应用程序和119个新的恶意软件家族[18]。显然,有必要阻止Android市场和智能手机上恶意软件的传播
Android平台提供了多种可加强恶意软件安装的安全措施,其中最引人注目的是Android权限系统。为了在设备上执行某些任务(例如发送SMS消息),每个应用程序都必须在安装过程中明确要求用户许可。但是,许多用户倾向于盲目地将权限授予未知应用程序,从而破坏了权限系统的目的。因此,实际上,恶意应用程序几乎不受Android权限系统的限制。
因此,大量研究已经研究了在安装Android恶意软件之前用于分析和检测的方法。这些方法可以使用静态和动态分析粗略地分类为方法。例如,TaintDroid [11],DroidRanger [40]和DroidScope [37]是可以在运行时监视应用程序行为的方法。尽管运行时监视在识别恶意活动方面非常有效,但其开销却很大,无法直接应用于移动设备。相比之下,静态分析方法(例如Kirin [13],Stow-away [15]和RiskRanker [21])通常仅会产生很小的运行时开销。尽管这些方法高效且可扩展,但它们主要建立在通常无法用于新的恶意软件实例的手动检测模式上。而且,这些方法大多数都不提供其决定的解释,因此对于从业者是不透明的。
在本文中,我们介绍了DREBIN,这是一种用于检测Android恶意软件的轻量级方法,可自动推断检测模式并直接在智能手机上识别恶意软件。 DREBIN执行广泛的静态分析,从应用程序的代码和清单中收集尽可能多的功能。这些功能以字符串集(例如权限,API调用和网络地址)进行组织,并嵌入在联合向量空间中。例如,将发送高级SMS消息的应用程序强制转换为矢量空间中与相应权限,意图和API调用关联的特定区域。这种几何表示法使DREBIN能够使用机器学习技术自动识别表示恶意软件的特征组合和模式。对于每个检测到的应用程序,可以提取相应的模式,将其映射到有意义的描述中,然后提供给用户作为检测说明。除了检测之外,DREBIN还可以提供对已识别恶意软件样本的见解。
对来自不同市场的123,453个应用程序和5,560个最新的恶意软件样本进行的实验证明了我们方法的有效性:DREBIN优于相关方法[13、26、33]以及10种流行的防病毒扫描程序中的9种。该方法检测到94%的恶意软件样本,误报率为1%,对应于100个已安装应用程序中的一个错误警报。通常,在常规计算机上,对应用程序的分析时间不到一秒钟,而在流行的智能手机型号上,则需要10秒。据我们所知,D REBIN是第一种直接在智能手机设备上提供有效且可解释的Android恶意软件检测的方法。
总而言之,我们在本文中为检测Android恶意软件做出了以下贡献:
- 有效的检测。我们介绍了一种结合静态分析和机器学习的方法,该方法能够识别Android恶意软件的准确性高,错误警报少,独立于手工制作的检测模式
- 可解释的结果。所提出的方法提供了可解释的检测。可以从向量空间追溯指示检测到的恶意软件实例的特征模式,并提供对检测过程的深入了解。
- 轻量分析。为了提高效率,我们应用了线性时间分析和学习技术,这些技术可以检测智能手机上的恶意软件并在合理的时间内分析大量应用程序。
在这里我们需要注意,DREBIN建立在静态分析的概念之上,因此不能排除在移动设备上存在混淆或动态加载的恶意软件的可能性。正如我们的评估所示,我们将在第4节中专门讨论这种方法的局限性。由于对功能的广泛分析,我们的方法提高了攻击者感染带有恶意应用程序的智能手机的门槛,并增强了Android平台的安全性。
本文的其余部分安排如下:第2节介绍了DREBIN及其检测方法。第3节介绍了实验和与相关方法的比较。第4节和第5节分别讨论了局限性和相关工作。第六部分总结了论文。
2-Methodology
为了检测智能手机上的恶意软件,DREBIN需要全面而轻量级的应用程序表示形式,以便确定恶意活动的典型征兆。为此,我们的方法采用了广泛的静态分析方法,该方法可以从不同的来源中提取特征集,并在表达性向量空间中进行分析。此过程如图1所示,并概述如下:
- 广泛的静态分析。第一步,DREBIN静态检查给定的Android应用程序,并从该应用程序的清单和dex代码中提取不同的功能集(第2.1节)。
- 嵌入向量空间。然后将提取的特征集映射到联合向量空间,在此可以对几何特征的模式和组合进行几何分析(第2.2节)。
- 基于学习的检测。功能集的嵌入使我们能够使用高效的机器学习技术(例如线性支持向量机(第2.3节))来识别恶意软件。
- 说明。在最后一步中,识别出有助于检测恶意应用程序的功能,并将其呈现给用户以解释检测过程(第2.4节)。
在以下各节中,我们将更详细地讨论这四个步骤,并提供必要的分析技术背景
2.1 Static Analysis of Applications
第一步,DREBIN对给定的Android应用程序执行轻量级的静态分析。尽管表面上看似简单,但静态提取要素需要在受约束的环境中运行并及时完成。如果分析花费的时间太长,则用户可能会跳过正在进行的过程并拒绝整个方法。因此,选择可以有效提取的特征就变得至关重要。
因此,我们将重点放在应用程序的清单和反汇编的dex代码上,它们都可以通过线性扫描应用程序的内容来获得。为了进行通用和可扩展的分析,我们将所有提取的功能表示为字符串集,例如权限,意图和API调用。特别是,我们提取了以下8组字符串
2.1.1 Feature sets from the manifest
为Android开发的每个应用程序都必须包含一个名为AndroidManifest.xml的清单文件,该清单文件提供支持该应用程序安装和以后执行的数据。可以使用Android Asset Packaging Tool在设备上有效地检索此文件中存储的信息,该工具使我们能够提取以下集合:
S1硬件组件:此第一个功能集包含请求的硬件组件。如果应用程序请求访问相机,触摸屏或智能手机的GPS模块,则需要在清单文件中声明这些功能。请求访问特定硬件显然具有安全隐患,因为使用某些硬件组合通常会反映有害行为。例如,可以访问GPS和网络模块的应用程序可以收集位置数据,并将其通过网络发送给攻击者。
S2请求的权限:权限系统是Android中引入的最重要的安全机制之一。权限由用户在安装时主动授予,并允许应用程序访问与安全性相关的资源。如先前的工作[13,33]所示,恶意软件往往比无害的应用程序更频繁地请求某些权限。例如,当前恶意软件中有很大一部分会发送高级SMS消息,从而请求发送SMS许可。因此,我们收集功能集中清单中列出的所有权限。
S3 App组件:存在四种不同类型的应用程序中的组件,每个组件定义与系统的不同接口:活动,服务,内容提供者和广播接收者。每个应用程序都可以在清单中声明每种类型的多个组件。这些组件的名称也收集在功能集中,因为这些名称可能有助于识别恶意软件的知名组件。例如,所谓的DroidKungFu系列的几种变体共享特定服务的名称[请参见24]。
S4过滤的意图:Android上的进程间和进程内通信主要通过意图执行:作为异步消息交换的被动数据结构,并允许在不同组件和应用程序之间共享有关事件的信息。我们收集清单中列出的所有意图作为另一个功能集,因为恶意软件通常会侦听特定意图。恶意软件中涉及的意图消息的典型示例是BOOT COMPLETED,它用于在重启智能手机后立即触发恶意活动。
2.1.2 Feature sets from disassembled code
Android应用程序是用Java开发的,并被编译为Dalvik虚拟机的优化字节码。此字节码可以有效地反汇编,并为DREBIN提供有关API调用和应用程序中使用的数据的信息。为了实现低运行时间,我们基于Android平台的dex库实现了轻量级的反汇编程序,该库可以输出应用程序中包含的所有API调用和字符串。我们使用此信息来构造以下功能集。
S5 受限API调用:Android权限系统限制对一系列关键API调用的访问。我们的方法在反汇编的代码中搜索这些调用的发生,以便更深入地了解应用程序的功能。揭示恶意行为的一个特殊情况是使用了受限制的API调用,但尚未请求所需的权限。这可能表明恶意软件正在使用root漏洞,以超越Android平台施加的限制。
S6 已使用的权限:S 5中提取的完整呼叫集用作确定请求的和实际使用的权限子集的基础。为此,我们实现了Felt等人介绍的方法。 [15]匹配API调用和权限。与S 5相比,此功能集提供了有关应用程序行为的更一般视图,因为可以通过单个权限来保护多个API调用(例如,sendMultipartTextMessage()和sendTextMessage()都要求授予SEND SMS权限)到应用程序)。
S7 可疑API调用:某些API调用允许访问智能手机的敏感数据或资源,并且经常在恶意软件样本中找到。由于这些调用会特别导致恶意行为,因此将它们提取并收集到单独的功能集中。特别是,我们收集以下类型的API调用:
- API调用以访问敏感数据,例如getDeviceId()和getSubscriberId()
- API调用通过网络进行通信,例如setWifiEnabled()和execHttpRequest()
- API用于发送和接收SMS消息的API调用,例如sendTextMessage()
- API调用执行Runtime.exec()之类的外部命令
- 混淆常用的API调用,例如Cipher.getInstance()
S8 网络地址:恶意软件定期建立网络连接以检索命令或泄露从设备收集的数据。因此,在反汇编代码中找到的所有IP地址,主机名和URL都包含在最后一组功能中。其中一些地址可能与僵尸网络有关,因此存在于多个恶意软件样本中,这有助于改善对检测模式的学习。
2.2 Embedding in Vector Space
恶意活动通常反映在提取特征的特定模式和组合中。例如,发送高级SMS消息的恶意软件可能在S 2中包含许可SEND SMS,在S 1中包含硬件组件android.hardware.telephony。理想情况下,我们希望制定布尔表达式来捕获功能之间的这些依赖关系,并在检测到恶意软件时返回true。但是,从实际数据推断布尔表达式是一个难题,很难有效解决。
作为一种补救措施,我们旨在使用机器学习中的概念来捕获功能之间的依赖关系。由于大多数学习方法都对数值向量进行操作,因此我们首先需要将提取的特征集映射到向量空间。为此,我们定义了一个联合集S,该联合集S包含8个特征集中包含的所有可观察字符串:
通过向每个功能集中的所有字符串添加唯一的前缀,确保不同集合的元素不会发生冲突。在我们的评估中,集合S包含大约545,000个不同特征(请参见第3节)。
使用集合S,我们定义了一个| S |维向量空间,其中每个维为0或1。通过构造向量ϕ(x)将应用程序x映射到该空间,以便从中提取每个特征s。 x相应维设置为1,所有其他维设置为0。形式上,可以为一组应用X定义此映射as,如下所示
指标函数I(x,s)简单定义为
共享相似功能的应用程序在此表示中彼此靠近,而具有主要不同功能的应用程序相隔很远。此外,该空间中的方向可用于描述特征的组合,并最终使我们能够学习可解释的检测模型。
让我们以一个示例为例,考虑一个发送高级SMS消息并因此需要请求某些权限和硬件组件的恶意应用程序。此应用程序的对应向量ϕ(x)如下所示
乍一看,地图ϕ似乎不适合对应用程序进行轻量级分析,因为它将数据嵌入到高维向量空间中。幸运的是,从应用程序中提取的特征数量在大小上是线性的。即,包含m个字节的代码和数据的应用程序x最多包含m个特征字符串。结果,向量ϕ(x)中只有m个维度为非零,而与向量空间的维度无关。因此,例如,使用哈希表[6]或布隆过滤器[3],仅存储从应用程序提取的用于稀疏表示向量的特征就足够了。
2.3 Learning-based Detection
在第三步中,我们应用机器学习技术来自动学习恶意应用程序与良性应用程序之间的隔离。机器学习的应用使我们免于手动为提取的特征构建检测规则。
尽管可以采用几种学习方法来学习两类之间的分离,但是只有少数几种方法能够生成有效且可解释的检测模型。我们考虑将线性支持向量机(SVM)[8,14]用于此任务。给定两个类别的向量作为训练数据,线性SVM确定一个超平面,该超平面以最大余量将两个类别分隔开(见图2)。这些类中的一个与恶意软件相关联,而另一类与良性应用程序相对应。通过将未知应用程序映射到向量空间并确定它属于超平面的恶意(+)还是良性(-)来对未知应用程序进行分类。
形式上,线性SVM的检测模型仅对应于向量w∈R | S |。指定超平面的方向,其中相应的检测函数f由
并返回ϕ(x)相对于w的方向。也就是说,f(x)> t表示恶意活动,而f(x)≤t对应于给定阈值t的良性应用。
为了有效地计算函数f,我们再次利用映射ϕ的稀疏表示。给定一个应用x,我们知道只有从x提取的特征在ϕ(x)中具有非零条目。所有其他维均为零,对f(x)的计算没有贡献。因此,我们可以如下简化检测函数f
代替涉及的学习模型,我们最终得出一个简单的总和,只需将应用程序x中每个特征s的权重w s相加即可有效地计算出总和。这种表述使我们能够在智能手机上应用学习的检测模型,还使我们能够解释由支持向量机获得的结果。
Offline learning
在我们的实现中,我们不会在智能手机上学习检测模型。相反,我们在专用系统上离线训练支持向量机,并且仅将学习到的模型w传输到智能手机以检测恶意应用程序。
2.4 Explanation
在实践中,检测系统不仅必须指示恶意活动,还必须提供其检测结果的说明。基于学习的方法是黑盒方法[34],这是一个普遍的缺陷。在DREBIN的情况下,我们解决了这个问题并扩展了基于学习的检测,以便它可以识别有助于检测的应用程序功能。此外,可解释的检测还可以帮助研究人员检查恶意软件中的模式并更深入地了解其功能。
借助线性SVM的简单检测功能,我们能够确定每个单个特征s对函数f(x)的贡献。在计算f(x)时,我们只需要存储最大的权重w s,即可将应用程序转移到超平面的恶意端。由于每个权重w s都分配给某个特征s,因此可以解释为什么应用程序被分类为恶意。通过在函数f(x)[6]的计算过程中将k个最大权重w s保持在堆中,可以有效地实现此方法。
在按权重提取前k个特征后,DREBIN自动构建描述这些特征基础功能的句子。为了实现此目标,我们为每个功能集设计了可以使用相应功能完成的句子模板。表1列出了这些模板。对于恶意软件中经常观察到的功能,例如许可SEND SMS,我们提供了单独的描述。
对于大多数功能集,从表1中的模板构造句子很简单。例如,对于硬件功能,我们利用它们的命名方案来构造有意义的句子。例如,如果某个应用程序使用android.hardware.camera功能,则DREBIN向用户显示“应用程序使用硬件功能摄像头”这句话。
同样,我们提供请求和使用权限的说明。权限的说明可以从提供适当说明的Android文档(至少针对所有系统权限)中得出。我们会稍加修改这些描述,以便为用户提供有意义的解释。但是,由于应用程序开发人员可以定义自定义权限,因此,我们还提供了一个通用语句,如果不存在适当的描述,则会向用户显示该语句。对于基于使用某些权限的受限API调用,我们采用相同的方法。对于所有其他功能集,模板将直接使用功能名称或相应的占位符填充。
由DREBIN生成的解释的示例如图3所示。给出的示例属于GoldDream系列。 DREBIN正确识别恶意软件与外部服务器通信并发送SMS消息。在安装过程中,该应用程序请求16个权限。许多用户忽略了这么长的权限列表,因此成为了这种恶意软件的受害者。与传统的基于权限的方法相反,DREBIN将用户的注意力直接吸引到指示恶意活动的相关方面。此外,DREBIN向用户提供一个分数,告诉他该决定的信心。结果,用户能够决定所呈现的功能是否符合他的期望。
除了为用户带来好处外,生成的说明还可以帮助研究人员发现常见恶意软件家族中的相关模式。我们将在下一节中更详细地讨论这一方面
3 Evaluation
详细介绍了DREBIN之后,我们现在进行其功效的实证评估。特别是,我们进行了以下三个实验:
- 检测性能。首先,我们评估DREBIN在5,560个恶意软件样本和123,453个良性应用程序的数据集上的检测性能。我们将其性能与相关方法和防病毒扫描程序进行了比较(第3.2节)。
- 可解释性。在第二个实验中,我们详细分析了DREBIN提供的针对不同恶意软件家族的解释,并验证它们是否与恶意软件的实际特征相关(第3.3节)。
- 运行时性能。最后,我们评估DREBIN的运行时性能。在本实验中,我们使用五种常见的智能手机型号以及一台常规台式计算机进行不同的运行时测量(第3.4节)
3.1 Data sets
对于所有实验,我们考虑真实的Android应用程序和真实的恶意软件的数据集。特别是,我们已获得131,611个应用程序的初始数据集,其中包括良性和恶意软件。样本是在2010年8月至2012年10月期间收集的。详细而言,该数据集包含来自GooglePlay商店的96,150个应用程序,来自不同替代中国市场的19,545个应用程序,来自替代俄罗斯市场的2,810个应用程序以及来自其他来源(例如,作为Android网站,恶意软件论坛和安全博客。此外,数据集还包含来自Android Malware Genome Project [39]的所有样本。
为了确定恶意和良性应用程序,我们将每个样本发送到VirusTotal服务,并检查十个常见的反病毒扫描程序(AntiVir,AVG,Bit-Defender,ClamAV,ESET,F-Secure,Kaspersky,McAfee,Panda,Sophos)的输出。我们将至少两个扫描程序检测到的所有应用程序标记为恶意。此过程可确保(几乎)将我们的数据正确地分为良性和恶意样本,即使十个扫描程序之一将虚假的良性应用程序标记为恶意也是如此。
最后,我们从数据集中删除标记为广告软件的样本,因为这种类型的软件处于恶意软件和良性功能之间的暮色区域。最终数据集包含123,453个良性应用程序和5,560个恶意软件样本。据我们所知,这是用于评估Android上恶意软件检测方法的最大恶意软件数据集之一。
表4(c)提供了我们数据集中前20个恶意软件家族的概述,其中包括当前在应用程序市场中活跃分布的几个家族。请注意,仅显示了前20个系列,我们的数据集还包含1,048个其他恶意样本。
3.2 Detection Performance
在我们的第一个实验中,我们评估了DREBIN的检测性能以及相关的静态检测方法。对于此实验,我们将数据集随机分为一个已知分区(66%)和一个未知分区(33%)。 DREBIN的检测模型和各个参数在已知分区上确定,而未知分区仅用于测量最终检测性能。我们重复此过程10次,得到平均结果。分区可确保报告的结果仅引用在DREBIN学习阶段未知的恶意应用程序。对于相关方法,例如Kirin [13]和RCP [33],此实验过程略有不同,因为并非所有方法都需要单独的训练步骤。
3.2.1 Comparison with related approaches
我们首先将D REBIN的性能与检测Android恶意软件的相关静态方法进行比较。特别是,我们考虑了Kirin [13],RCP [33]和Peng等人的方法。 [26],我们使用SVM而非Naive Bayes分类器实现后者。实验结果以ROC曲线显示在图4(a)中,即针对不同检测方法阈值,检测率(真阳性率)相对于假阳性率作图
DREBIN的性能明显优于其他方法,并以1%的假阳性率检测到94%的恶意软件样本,对应于安装100个应用程序时的一次错误警报。其他方法以这种假阳性率提供10%–50%的检测率。由于Kirin和RCP都仅考虑请求的权限的一部分,因此它们在检测恶意应用程序方面有明显的局限性。甚至Peng等人的方法。认为所有权限均无法在此实验中足够准确地检测到恶意软件。 DREBIN的良好性能来自用于模拟恶意活动的不同功能集。这些集包括所请求的权限,还包含应用程序的其他相关特征,例如可疑API调用,已过滤的意图和网络地址。
3.2.2 Comparison with AV scanners
尽管与相关方法相比,DREBIN具有更好的性能,但最终它必须在实践中与常见的防病毒产品竞争。因此,我们还将其与数据集上选择的十个防病毒扫描程序进行了比较。再次从VirusTotal服务获取每个扫描仪的检测性能。我们进行了两个实验,首先考虑数据集的所有恶意软件样本,然后仅考虑Malgenome项目提供的样本[39]。我们为DREBIN选择了1%的假阳性率,我们认为这对于实际操作来说足够低
实验结果如表2所示。反病毒扫描程序的检测率差异很大。最好的扫描程序可以检测到90%以上的恶意软件,但某些扫描程序却发现不到10%的恶意样本,这可能是由于未专门检测Android恶意软件。在完整的数据集上,DREBIN的性能为次优,检测率为93.9%,性能优于10个扫描仪中的9个。由于我们的测试设置,此观察非常出色,因为至少有两个扫描仪应该能够检测到每个恶意软件样本。因此,必须在一定时间内知道每个样本,并且大多数防病毒扫描程序应配备相应的签名。但是,事实证明,自动生成的DREBIN检测模型比许多扫描仪的手工签名更有效。在Malgenome数据集上,反病毒扫描程序具有更高的检测率,因为这些样本已经公开了较长的时间。因此,几乎所有的防病毒扫描程序都为此数据集提供适当的签名。
在我们的良性应用程序数据集中,反病毒扫描程序的误报率在0%到0.3%之间,因此略低于D REBIN的性能。尽管有大量可用的Android应用程序,但普通用户仅在其设备上安装了数十个应用程序。例如,根据市场研究公司Nielsen 1的数据,美国每部智能手机的平均已安装应用程序数量在2011年为32,2012年为41。因此,我们认为1%的误报率仍可接受实践中的DREBIN
3.2.3 Detection of malware families
测试方法的检测性能时应考虑的另一个重要方面是数据集中恶意软件家族的平衡[32]。如果某些恶意软件家族的样本数量远大于其他家族,则检测结果主要取决于这些家族。为了解决这个问题,每个家庭可以使用相同数量的样本。但是,这导致与实际情况有很大不同的分布。相反,我们分别评估了20个最大的恶意软件家族的检测性能。表4(c)中列出了每个家族的名称和样本数,图4(b)中显示了每个家族的DREBIN检测性能。
DREBIN能够以1%的假阳性率以93%的平均准确度可靠地检测所有家族。特别是,所有家庭的检出率均超过90%,其中三个可以完全识别(H,O,P)。 DREBIN不能可靠地检测到只有一个恶意软件家族。这个家族是Gappusin(R),我们将在下一部分中研究其低性能。应该指出的是,只要样本数量足够高并允许SVM概括其功能,恶意软件家族的大小与其检测率之间似乎就没有依赖关系。
3.2.4 Detection of unknown malware families
DREBIN使用已知的恶意软件来学习其检测模型。因此,重要的是评估一个家族的多少样本才能可靠地检测出该家族。为了研究这个问题,我们进行了两个额外的实验,其中我们限制了训练集中特定家庭的样本数量。在第一个实验中,我们没有提供该家族的样本,这与完全未知的恶意软件株相对应。在第二个实验中,我们将10个随机选择的家庭样本放回到训练集中,从而模拟了一个新家庭的开始传播。
图5显示了两次实验的结果,其中显示了每个家庭训练集中0个和10个可用样本的检测率。如果没有样本可用于学习,则D REBIN很难检测到一个家族,因为SVM无法发现任何判别模式。但是,仅需很少的样本即可概括大多数恶意软件家族的行为。训练集中只有10个样本,平均检测性能提高了25%以上。在这种情况下,甚至可以完美地检测到三个家庭。这样做的原因是,某些家族的成员通常只是重新包装的应用程序,但要稍作修改。由于通过SVM进行的概括,因此即使只知道非常少的样本集,也可以检测到族的变异。
总而言之,DREBIN提供了对Android恶意软件的有效检测,其性能优于相关检测方法以及多种反病毒扫描程序。尽管DREBIN从一开始就无法发现未知恶意软件,但是每个家族仅需要几个样本就可以实现可靠的检测。
3.3 Explanations
除了其检测性能外,DREBIN的优势还在于其能够解释所获得结果的能力。这使我们可以检查有助于检测的提取特征是否适合常见的恶意软件特征。在本节中,我们首先研究四个流行的恶意软件家族,并分析具有高权重的功能如何得出有关其行为的结论。然后,我们详细检查DREBIN的误报和误报。
3.3.1 Explanation for malware families
为了研究D REBIN提供的解释,我们考虑了四个著名的恶意软件家族,即FakeInstaller,GoldDream [23],GingerMaster [22]和Droid-KungFu [24]。对于这些家族的每个样本,我们确定对分类决策贡献最大的特征,并将结果平均到家族的所有成员中。表3列出了每个恶意软件家族的前五项功能。为清楚起见,我们介绍了确切的功能,而不是第2.4节中介绍的解释性句子。
- FakeInstaller 是目前使用最广泛的恶意软件。该家族的成员将其恶意代码隐藏在流行应用程序的重新打包版本中。在安装过程中,恶意软件将昂贵的SMS消息发送给恶意软件作者拥有的高级服务。即使乍一看,其中三个提取的功能也表明该恶意软件使用了SMS功能,其中,一旦应用程序请求使用SMS功能的权限,就会将android.hardware.telephony隐式添加到清单文件中。
- DroidKungFu 尝试利用Android早期版本中的多个漏洞来获取root用户访问权限并从设备中窃取敏感数据。它获得root用户访问权限的意图由功能system / bin / su反映出来。调用getSubscriberId()表示恶意软件尝试访问敏感数据。电池更改动作和SIG STR这两个意图是由广播接收器组件过滤的,该组件是许多DroidKungFu样本的一部分。一旦某个事件(例如电池电量低)发生,这两个意图都可以用作触发以在后台启动恶意服务。
- GoldDream 是一种木马,可以监视受感染的设备,收集敏感数据并从收到的SMS消息中记录信息。 Telephony.SMS RECEIVED功能直接提示我们阅读SMS消息。恶意软件收集到足够的数据后,会将数据发送到外部服务器,其主机名在功能列表中排第二。此外,该恶意软件能够安装和删除软件包以及发送SMS消息,这也反映在所提取的功能中。
- GingerMaster还是特洛伊木马应用程序,通常与良性应用程序捆绑在一起,并尝试获得root访问权限,窃取敏感数据并将其发送到远程服务器。与DroidKungFu系列类似,该恶意软件在收到启动完成或用户当前意图后立即启动其恶意服务。同样,仅通过查看主要特征即可重构此行为的重要部分。
为了研究不同功能集对检测恶意软件的贡献,我们提取了数据集中所有恶意软件家族的前5个功能。结果显示在表4中。尽管所请求的权限出现在所有系列的主要功能中,但很明显,仅此功能集不足以确保可靠的检测。特别是,每个功能集在表中至少出现一次,这清楚地表明所有功能集对于检测Android恶意软件都是必需的。
3.3.2 False and missing detections
我们最终将检查被DREBIN错误分类为恶意软件的良性应用程序。与恶意应用程序相似,这些示例中的大多数都使用SMS功能并访问敏感数据,这反映在相应功能的权重较高中。此外,这些样本通常仅显示很少的良性行为,因此会触发错误警报。幸运的是,DREBIN输出可解释的结果的功能可以帮助用户确定可疑外观功能是否确实是恶意的,或者对于应用程序的预期目的而言是必需的
当D REBIN将Gappusin家族的样本分类为良性时,也会发生类似的情况[19]。尽管在许多情况下都可以提取与Gappusin家族描述相匹配的功能(其中包括外部服务器的主机名),但恶意功能很少,无法将样本识别为恶意软件。 Gappusin主要充当其他恶意应用程序的下载器,因此不表现出常见的恶意功能,例如盗窃敏感数据。
3.4 Run-time Performance
尽管移动设备的计算能力正在迅速提高,但与普通台式计算机相比仍然受到限制。因此,应该直接在这些设备上运行的检测方法必须非常有效地执行其任务。
为了分析D REBIN的运行时,我们实现了一个独立的Android应用程序,该应用程序接收学习的检测模型并能够直接在智能手机上执行检测过程。下载模型的大小仅为280 KB。使用此应用程序,我们使用来自Google Play商店的100个随机选择的流行应用程序来测量D REBIN在不同设备上的运行时间。在本实验中,我们选择的设备涵盖了各种广泛的硬件配置,包括四个智能手机(Nexus 4,Galaxy S3,Xperia Mini Pro和Nexus 3),平板电脑(Nexus 7)和普通台式计算机(PC)。
结果如图6所示。平均而言,DREBIN能够在10秒钟内在五部智能手机上分析给定的应用程序。即使在Xperia Mini Pro等较旧的机型上,该方法平均也可以在不到20秒的时间内分析应用程序。总体而言,所有设备的分析时间都不会超过1分钟。在台式计算机(具有4GB RAM的2.26 GHz Core 2 Duo)上,D REBIN可以实现每个应用程序750毫秒的出色分析性能,从而可以在一天之内扫描100,000个应用程序
图7显示了台式机和Galaxy S3智能手机的详细运行时分析,其中将每个应用程序的运行时与所分析代码的大小作图。出乎意料的是,在两个设备上,DREBIN都达到了亚线性运行时间,也就是说,其性能随着分析字节数m的O(√m)的增加而提高。显然,功能部件的数量不会随代码线性增加,因此较大的应用程序不一定包含更多要分析的功能部件。
通过此评估,我们得出结论,DREBIN不仅可以可靠地检测恶意应用程序,而且还能够在明显满足实际需求的时间内执行此任务。
4 Limitations
先前的评估证明了我们的方法在检测Android平台上最新恶意软件方面的功效。但是,DREBIN基于静态分析的概念并且缺乏动态检查,因此通常不能禁止恶意应用程序的感染。尤其是,静态分析无法检测到的转换攻击(例如基于反射和字节码加密[参见30])可能会阻碍精确检测。为了减轻动态分析的缺乏,DREBIN提取与代码的混淆和加载有关的API调用,例如DexClassLoader.loadClass()和Cipher.getInstance()。这些功能使我们至少能够发现隐藏代码的执行-即使我们无法进一步分析它。结合其他功能,尽管使用了一些混淆技术,DREBIN仍然能够识别恶意软件。
为了避免手动制作检测模式,我们利用机器学习来生成检测模型。虽然学习技术为自动推断模型提供了强大的工具,但它们需要训练的数据具有代表性。也就是说,DREBIN的检测模型的质量关键取决于代表性的恶意和良性应用程序的可用性。虽然收集良性应用程序很简单,但是收集最新的恶意软件样本需要一些技术上的努力。幸运的是,离线分析方法,例如DroidRanger [40],AppsPlayground [29]和RiskRanker [21],可能会在这里帮助自动获取恶意软件,并为随着时间的推移更新和维护DREBIN的代表性数据集提供基础。
使用机器学习带来的另一个限制是模仿和中毒攻击的可能性[例如25、27、35]。尽管混淆策略(例如重新打包,代码重新排序或垃圾代码插入)不会影响DREBIN,但是在学习和检测阶段之间重命名活动和组件可能会损害区分性[30,38]。同样,攻击者可能通过将良性特征或伪造的不变量结合到恶意应用程序中来成功降低DREBIN的检测分数[25,27]。尽管一般来说不能排除对学习技术的这种攻击,但是对学习数据进行彻底的清理[见7]以及对代表性数据集进行频繁的重新训练可以限制其影响。
5 Related Work
过去几年中,对Android恶意软件的分析和检测一直是研究的生动领域。已经提出了几种概念和技术来应对这种恶意软件的数量和复杂性。 Felt等人的研究提供了当前恶意软件现状的概述。 [16]和Zhou&Jiang [39]。
5.1 Detection using Static Analysis
检测Android恶意软件的第一种方法受到静态程序分析概念的启发。已经提出了几种方法来静态检查应用程序并反汇编它们的代码[例如,12、13、15、21]。例如,方法Kirin [13]检查应用程序的许可以获取恶意活动的迹象。同样,Stowaway [15]分析API调用以检测过度特权的应用程序,RiskRanker [21]静态地识别具有不同安全风险的应用程序。常用的静态分析开源工具是Smali [17]和Androguard [10],它们可以轻松分析应用程序的内容
我们的方法DREBIN与这些方法有关,并且采用类似的功能来识别恶意应用程序,例如权限,网络地址和API调用。但是,它与以前的工作在两个主要方面有所不同:首先,我们放弃了手动设计检测模式,而是将机器学习应用于分析从静态分析中提取的信息。其次,对DREBIN的分析进行了优化,以提高有效性和效率,这使我们能够直接在智能手机上检查应用程序。
5.2 Detection using Dynamic Analysis
研究的第二个分支研究了在运行时检测Android恶意软件。最值得注意的是,分析系统TaintDroid [11]和DroidScope [37]能够在受保护的环境中动态监视应用程序,其中前者专注于污点分析,而后者则可以在平台的不同层进行自省。虽然这两个系统都提供有关应用程序行为的详细信息,但从技术上讲,它们涉及面太广,无法部署在智能手机上并直接检测恶意软件。
因此,动态分析主要用于离线检测恶意软件,例如扫描和分析大量Android应用程序。例如,方法DroidRanger [40],AppsPlayground [29]和CopperDroid [31]已成功应用于研究不同Android市场中具有恶意行为的应用程序。 Google目前正在使用一种称为Bouncer的类似检测系统。这种动态分析系统适用于过滤来自Android市场的恶意应用程序。但是,由于Android平台的开放性,应用程序也可能从其他来源安装,例如网页和记忆棒,这要求在智能手机上运行检测机制。
ParanoidAndroid [28]是采用动态分析并可以在智能手机上发现恶意活动的少数检测系统之一。为此,智能手机的虚拟克隆在专用服务器上并行运行,并与设备的活动同步。此设置允许监视克隆上应用程序的行为,而不会破坏真实设备的功能。但是,涉及功能的重复,并且在实践中,数百万智能手机实际上大规模运行ParanoidAndroid在技术上是不可行的。
5.3 Detection using Machine Learning
手动设计和更新Android恶意软件的检测模式的困难激发了机器学习的应用。已经提出了几种使用学习方法自动分析应用程序的方法[例如2、26、33]。例如,Peng等人的方法。 [26]将概率学习方法应用于检测恶意软件的应用程序的权限。同样,方法Crowdroid [4],Droid-Mat [36],Adagio [20],MAST [5]和DroidAPIMiner [1]使用机器学习技术分析从Android应用程序静态提取的功能。与我们的工作最接近的是DroidAPIMiner [1],它对最近的恶意软件提供与D REBIN类似的检测性能。但是,DroidAPIMiner建立在k最近邻分类器上,这会导致大量的运行时开销并阻碍在智能手机上操作该方法。此外,DroidAPIMiner并非旨在为其检测提供解释,因此对从业人员不透明
总体而言,以前使用机器学习的工作主要集中在准确检测恶意软件上。没有考虑其他方面,例如检测的效率和可解释性。我们针对这些方面,提出了一种方法,该方法可提供对恶意应用程序的有效,高效和可解释的检测。
6 Conclusion
Android恶意软件是一种新的但增长迅速的威胁。诸如防病毒扫描程序之类的经典防御越来越无法应对应用程序市场中恶意软件的数量和多样性。尽管最近的方法(例如DroidRanger [40]和AppPlayground [29])支持从这些市场过滤掉这些应用程序,但它们会导致运行时开销,从而无法直接保护智能手机。作为补救措施,我们引入了DREBIN,这是一种用于检测Android恶意软件的轻量级方法。 DREBIN结合了静态分析和机器学习的概念,从而使其能够更好地与恶意软件开发保持同步。我们的评估证明了这种方法的潜力,其中DREBIN的性能优于相关方法,并且可以识别出几乎没有错误警报的恶意应用程序。
实际上,DREBIN为Android平台的安全性提供了两个优点:首先,它可以有效地扫描大量应用程序,例如来自第三方市场的应用程序。在普通计算机上,每个应用程序的平均运行时间为750毫秒,因此分析少于100,000个未知应用程序所需的时间少于一天。其次,DREBIN可以直接应用在智能手机上,当新的应用程序下载到设备上时,可以触发分析。因此,D REBIN可以保护从不可信来源(例如网站和第三方市场)安装应用程序的用户。
尽管D REBIN在我们的评估中可以有效识别恶意软件,但它表现出静态分析的固有局限性。尽管能够检测到混淆或动态执行的指示,但该方法无法访问检索到的代码。已经成功解决了一个类似的设置,用于JavaScript代码分析[请参见9],并且每当加载新代码时就动态触发DREBIN的静态分析似乎是未来工作的有希望的方向。