0 引言

移动平台上各式各样的应用程序呈指数式爆炸增长，其中，基于Android系统的应用程序更是占据了绝对优势。但是，由于Android应用开发门槛较低，开发者水平良莠不齐，一些应用往往会因为开发者的安全意识不强、逻辑不够严谨或者没有对应用进行异常处理而存在安全漏洞。因此，安卓应用很容易出现安全漏洞。

安卓应用是由功能丰富的组件构成的。这些组件可以实现用户交互界面、后台服务、广播通知等功能。同时，安卓系统提供了Intent机制来帮助这些组件实现应用间通信和应用内通信。借助Intent，开发者研发的任意应用可以和软件中的开放组件进行通信并传递任意类型的数据。但是如果应用在解析通过Intent获取的数据时没有进行异常捕获，畸形数据就可能使应用崩溃，导致应用的部分功能不可用，更甚者会导致整个应用瘫痪。利用这种漏洞，攻击者对应用发起拒绝服务攻击，不仅能够直接影响用户体验，而且还能导致安全防护应用的防护功能被绕过或失效，进而危害用户的隐私和财产安全。如何有效地实现对该类漏洞的挖掘，保障Android用户的权益是亟待解决的问题^[1]。

在漏洞挖掘方面，目前通用的方法是静态挖掘和动态挖掘。静态挖掘方法主要是使用了代码审计的思想，结合应用的函数调用图、控制流图以及敏感数据的传播路径对Android程序的源代码进行静态分析来进行漏洞挖掘，具有速度快，覆盖率全的优点，可用于组件劫持漏洞挖掘^[2]、隐私泄露漏洞挖掘^[3-5]、Intent注入漏洞挖掘^[6]等研究工作，但是误报率比较高。动态挖掘方法目前主要以fuzzing技术^[7]为主，广泛地应用于挖掘应用组件间通信机制和系统短信应用的漏洞，如Yang等^[8]使用模糊测试技术对应用的功能泄露漏洞进行挖掘，Mulliner等^[9]使用模糊测试技术对系统短信的漏洞进行挖掘。与静态挖掘方法相比，动态挖掘方法提高了准确率和自动化程度，但存在样本覆盖率低、效率不高的缺点。

本文在研究Intent机制的基础上提出了一种面向Android组件拒绝服务漏洞的自动化漏洞挖掘框架。该框架主要由动态分析模块和静态分析模块两部分组成。其中，静态分析使用了逆向分析技术和数据流跟踪技术，提取应用的组件相关信息(如公开组件信息、动态注册的广播等)，以及公开组件启动私有组件的路径信息来辅助模糊测试。而动态分析则基于静态分析获取的结果，使用模糊测试技术，对应用进行空Intent测试、类型错误Intent测试、畸变Intent测试和异常Intent测试，进一步挖掘拒绝服务漏洞。此外，本文在模糊测试过程中采用Accessibility技术将应用崩溃弹窗进行关闭，实现了完全自动化。

1 背景知识与相关工作 1.1 公开组件

Android应用程序通常由一个或多个基本组件共同完成其功能。而Android应用程序的组件主要有活动(Activity)、服务(Services)、广播(Broadcast Receiver)和内容提供者(Content Provider)。其中，前三者可以通过Intent对象启动。

本文将应用组件分为公开组件和私有组件两类：公开组件指应用对外暴露，能被其他应用通过Intent启动的组件；而只能被应用内部其他组件访问的组件称为私有组件^[1]。

应用程序组件在AndroidManifest.xml文件中被声明为公开组件有两种方式：第一种是显式声明，即直接将组件的Android:exported属性设为true^[1]；第二种是隐式声明，即为组件添加一个或者多个Intent-filter过滤器的方式^[1]。

1.2 启动私有组件

当私有组件被公开组件启动时，也存在发生崩溃的情况。如下所示，应用中存在一个私有组件PrivateActivity和一个公开组件MainActivity。MainActivity能够根据对外传入的Intent中的内容启动私有组件PrivateActivity，且启动私有组件的Intent的内容来自于启动公开组件的Intent的内容。但是，私有组件PrivateActivity没有对从Intent中获取的内容进行异常处理，故攻击者精心构造的Intent内容可以通过公开组件MainActivity让私有组件PrivateActivity崩溃，从而发生拒绝服务攻击。

//私有组件PrivateActivity

public class PrivateActivity extends Activity{

  private static final String SAMPLE_STRING_TEST=

    "sample_string_test";

@Override

protected void onCreate(Bundle savedInstanceState){

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

String value=getIntent().getStringExtra

(SAMPLE_STRING_TEST);

String subValue=value.substring(0);

Toast.makeText(getAoolicationContext(),

 subValue, Toast.LENGTH_SHORT).show();

}

}

//公开组件MainActivity

public class MainActivity extends Activity{

  @Override

  protected void onCreate(Bundle savedInstanceState){

  super.onCreate(savedInstanceState);

  setContentView(R.layout.activity_main);

  Intent intent=this.getIntent();

  if(intent.getBooleanExtra("allowed", false)){

  ComponentName componentName=new ComponentName

   (this, "PrivateActivity");

  intent.setComponent(componentName);

  this.startActivity(this.getIntent);

}

}

}

//攻击命令

adb shell am start -n com.privatecomponent/.

MainActivity --ez "allowed" true

1.3 本地拒绝服务漏洞介绍

本文将产生本地拒绝服务的原因分为5种：空指针异常导致的漏洞、类型转换异常导致的漏洞、数组访问越界异常导致的漏洞、类未定义异常导致的漏洞以及其他异常导致的漏洞^[10]。

1) 当应用程序没有对getAction()、getStringExtra()等函数获取到的数据进行空指针判断，从而产生空指针异常而导致应用崩溃，这称为空指针异常拒绝服务漏洞(NullPointerException)^[10]以getAction()函数为例，产生漏洞的伪代码如下所示：

//攻击者代码

intent.putExtra("serializable_key", BigInteger.valueOf(1));

startActivity(intent);     //启动受害者组件

//受害者代码片段

Intent i=getIntent();

if(i.getAction().equals("android.intent.action.MAIN "))

{

Toast.makeText(this, "Test！", Toast.LENGTH_LONG).show();

}

2) 当应用程序没有对getSerializableExtra()等函数获取到的数据进行类型判断就直接进行强制类型转换，从而产生类型转换异常而导致应用崩溃，这称为类型转换异常拒绝服务漏洞(ClassCastException)^[10]。以getSerializableExtra()函数为例，产生漏洞的伪代码如下所示：

//攻击者代码片段

intent.putExtra("serializable_key", BigInteger.valueOf(1));

startActivity(i);      //启动受害者组件

//受害者代码片段

Intent i=getIntent();

String test=(String)i.getSerializableExtra("serializable_key")

3) 当应用程序没有对getIntegerArrayListExtra()等函数获取到的数据数组元素大小进行判断，从而产生数组访问越界而导致应用崩溃，这称为数组访问越界异常拒绝服务漏洞(IndexOutOfBoundsExceptio)^[10]。以getIntegerArrayListExtra()函数为例，产生漏洞的伪代码如下所示:

//攻击者代码片段

ArrayList＜Integer＞cve_id=new ArrayList＜Integer＞();

intent.putExtra("cve_id", cve_id);

startActivity(intent);     //启动受害者组件

//受害者代码

Intent intent=getIntent();

ArrayList＜Integer＞intArray=

intent.getIntegerArrayListExtra("cve_id");

if (intArray!=null) {

for (int i=0; i＜CVE_NUM; i++) {

intArray.get(i);

}

}

4) 当应用程序无法找到从getSerializableExtra()、getParcelable()等函数中获取到的序列化类对象的类定义，从而发生类未定义的异常而导致应用崩溃，这称为类未定义异常拒绝服务漏洞(ClassNotFoundException)^[10]。以getSerializableExtra()函数为例，产生漏洞的伪代码如下所示：

//攻击者代码, SelfSerializableData这个类未定义

i.putExtra("serializable_key", new SelfSerializableData());

startActivity(i);     //启动受害者组件

//受害者代码

Intent intent=getIntent();

intent.getSerializableExtra("serializable_key");

5) 其他异常导致的拒绝服务漏洞：如IllegalArgumentException、UnsupportedOperationException异常等导致的拒绝服务。

1.4 相关研究及挑战

目前，针对应用组件拒绝服务漏洞，主流的漏洞挖掘工具是iSEC Partners公司设计的Intent Fuzzer工具^[11]。该工具运行在Android设备上，其工作原理是通过PackageManager获取系统中所有安装应用的信息，以及各应用中Activity、Service和Broadcast Receiver这3类暴露组件的信息，然后通过调用startActivity(Intent)、startService(Intent)、sendBroadcast(Intent)等启动函数发送Intent消息到Activity、Service和Broadcast Receiver组件中进行测试。但该工具不支持对Activity类组件进行大量的测试。此外，Intent Fuzzer工具还存在不能完全实现自动化测试、没有日志输出和仅发送空Intent消息等问题。

Maji等^[12]对Intent Fuzzer工具进行了改进，设计了JarJarBinks工具。该工具通过startActivityForResult(Intent，int)函数来启动应用程序的Activitiy，进而可以通过调用finishActivity()函数来关闭Actvity，回收系统资源，实现了对大量的Activity进行测试。与Intent Fuzzer相比，JarJarBinks工具不仅实现了对Activity类组件的测试，而且Intent测试用例增加了随机的Extras，实现了更广泛的测试。但JarJarBinks工具不能准确获得应用中Extras的type和name信息，因而仍然不能对组件进行深入有效的Fuzzing测试。

实际上，现有的工具都不能自动关闭应用崩溃时的系统弹窗，不能完全实现自动化测试；而且现有工具都是只对AndroidManifest.xml文件中注册的公开组件进行测试，不能对应用中动态注册的Broadcast Receiver组件进行测试，也不能对通用型的Android应用组件拒绝服务进行测试。

因此，为了实现基于Fuzzing的Android组件拒绝服务漏洞的自动化挖掘，其挑战在于如何在扩大测试用例覆盖范围的基础上，自动关闭应用崩溃时弹出的窗口，实现批量应用的漏洞挖掘，提高漏洞挖掘效率。

1) 如何扩大测试用例的覆盖范围？不仅要考虑到应用中动态注册的Broadcast Receiver组件的测试和私有组件的测试，还要考虑对Intent更多属性的随机测试，以及畸变策略的多样化。

2) 如何自动关闭应用崩溃窗口，实现完全自动化？使用Android Accessibility机制实现对程序崩溃时系统弹窗的实时监视和关闭，让模糊测试在每次被弹窗阻塞后得以继续执行，实现完全自动化的应用组件拒绝服务漏洞挖掘。

2 基于逆向工程和数据流的静态分析

静态分析主要进行逆向分析和数据流分析的工作，挖掘私有组件导致的拒绝服务漏洞。

2.1 逆向分析

首先，需要检测APK文件是否进行了加固处理，由于经过加固处理的APK文件逆向分析得不到应用程序真正的代码，所以本文不对其进行考虑。

对于未经过加固处理的APK文件，该工作主要是将APK文件进行解压缩，提取APK中的Dex、AndroidManifest.xml等文件。然后使用AXMLPrinter2.jar工具将二进制的AndroidManifest.xml文件解析成文本形式的xml文件，提取应用的组件和包名等信息。同时使用dex2jar工具将DEX文件转换成jar文件，再使用cfr工具将jar文件反编译成Java源码文件，得到代码中动态注册的Broadcast Receiver信息，组件间的调用关系以及各组件接收Intent消息的Extra数据名称和类型。将获取的这些信息保存于info.txt文件中，后面用于动态分析时确定待测组件以及根据变异策略生成测试用例。另外，还要使用baksmali.jar工具将DEX文件反编译成Smali文件，用于2.2节的数据流分析工作。

2.2 数据流分析

数据流分析工作主要是构建控制流图来表示公开组件对私有组件的启动情况，从而得到存在拒绝服务的私有组件名称和发生崩溃的启动路径。

控制流图的构建是基于DEX文件反编译后的Smali代码上的，避免了用现有工具生成控制流图时引入大量无关系统库函数的问题，提高了分析效率。构图时，以每个公开组件的入口函数作为入口点，分别构造组件内控制流图和组件间控制流图，然后将各部分控制流图连接成一个完整的控制流图^[13]。

生成组件内控制流图时，根据if-else, try-catch这类跳转指令对Smali代码进行分块，每一个代码块作为控制流图的一个节点，代码块之间的跳转作为控制流图的有向边，指向程序的执行方向，其中，Intent的接收者对接收数据时可能发生的异常进行了正确处理的，其有向边用实线表示，若没有，就用虚线表示。为了保证完整，需要同时对与组件生命周期内各种状态相关的系统回调函数进行控制流图的构建。然后再根据回调函数的执行顺序，在回调函数之间添加对应的有向边(实线还是虚线)。

生成组件间控制流图时，根据应用组件间的Intent调用关系，包括显式Intent调用和隐式Intent调用，将组件内控制流图连接起来，成为一个完整的控制流图。

由于控制流图是一个连通图，本文采用深度优先搜索(Depth First Search, DFS)^[14]算法对得到的完整控制流图进行路径搜索，获取控制流图中全部的未经try-catch指令异常处理的调用路径。以图 1为例，说明使用深度优先搜索算法搜索符合条件的路径的过程，其中，v0节点表示公开组件入口函数所在节点，v4节点表示私有组件入口函数所在的节点。

1) 首先建立一个存储节点的栈空间，将起始节点v0入栈，并将其标记为入栈状态。

2) 从v0节点出发，找到下一个相邻的非入栈节点v1、v2或v3，假设先访问v1节点，将v1节点入栈，并标记为入栈状态。然后判断v0和v1之间的有向边是否为虚线:若是，继续向下来到v1节点，重复步骤2)；若不是，从栈顶弹出v1节点，并将v1节点标记为非入栈状态，继续对v0的下一个除v1节点外相邻的非入栈节点重复步骤2)。

3) 由于这里v0和v1之间是实线，v0和v2之间是虚线，所以此时栈顶是v2节点。

4) 从v2节点出发，找到v2节点的下一个相邻的非入栈节点v4，将v4节点入栈，并标记为入栈状态。然后，判断v2和v4之间的有向边是否为虚线:若是，继续向下来到v4，由于v4是终止节点，因此得到一条路径；若不是，从栈顶弹出v2节点，并将v2节点标记为非入栈状态，继续对v0下一个除v1, v2节点外相邻的非入栈节点重复步骤2)。

5) 由于这里v2和v4之间是实线，v0和v3之间是虚线，所以此时栈顶是v3节点。

6) 从v3节点出发，重复步骤4)，由于v3与v4之间是虚线且v4是终止节点，所以找到一条路径v0 → v3 → v4。

7) 此时栈顶是v4节点。从栈顶弹出v4节点，并将v4节点标记为非入栈状态。

8) 此时栈顶是v2节点，由于v2节点没有除刚出栈的v4节点外的相邻非入栈节点，因此将v2节点出栈，并标记为非入栈状态。

9) 此时栈顶是v0节点，由于与v0节点相邻的节点都已被访问过，因此弹出v0节点，并标记为非入栈状态。此时栈空间为空，结束整个路径搜索过程。

利用深度优先算法获取到所有未经异常处理的公开组件启动私有组件的路径后。将这些路径以及对应的公开组件和私有组件名称保存于VulPath.txt文件中，后续结合相关的Extra信息用来生成特殊的造成系统服务级联崩溃的测试用例，用来测试私有组件。

3 基于Fuzzing和Accessibility的动态分析 3.1 模糊测试 3.1.1 测试用例生成策略

为了增大测试用例的覆盖范围，本文针对Intent的Component、Action、Category、Data、Extra这5种属性构造测试用例。其中，采用的Intent构建策略有六类。

第一类测试用例是不携带任何额外数据的Intent消息，即直接使用AndroidManifest.xml文件和DEX文件分析得到的组件包名和组件名设置Intent的Component属性，而其他属性为空^[15]。

第二类测试用例只设置了Action、Category、Data三种属性中的任意一种，其余两种属性为空或随机值。其中Action^[16]和Category^[16]属性的值均取自Android提供的标准值，Data属性的值取自构建的几类典型的Data URL。构建的几类经典的Data URL如表 1所示^[15]。

第三类测试用例设置了Action、Category、Data三种属性中的任意两种，另一种属性为空或随机值。同样，Action和Category属性的值均取自Android提供的标准值，Data属性的值取自构建的几类典型的Data值^[15]。

第四类测试用例则同时设置了Action、Category、Data三种属性。其中Action和Category属性的值取自Android提供的标准值，Data属性的值取自构建的几类典型的Data值^[15]。

第五类测试用例是在前四类测试用例的基础上增加对Extras属性的设置。此时，测试用例需指定Extras属性中的数据名称^[15]，其值已在DEX文件分析时获取，数据值则是随机的。为了提高效率，针对Extras属性常携带的几类数据类型，本文对不同的数据类型分别设计了典型的数值进行数据填充，如表 2所示^[17]。

第六类测试用例是针对VulPath.txt文件中信息和Extras属性构建的，用来测试通过级联反应引起的私有组件的崩溃。其中，Extra属性名称已在DEX文件分析时获取到，数据值是随机的。

通过上述的测试用例生成策略，可以生成与目标组件所接收的Intent的属性完全匹配、半匹配以及完全不匹配的Intent测试用例，最大限度地提高了测试用例的覆盖范围。

3.1.2 测试过程

模糊测试的流程为：

1) 基于测试用例生成策略构造大量的多类型的Intent。

2) 将待测试的应用安装到Android模拟器上。

3) 借助ADB工具将测试用例发送给目标应用的每一个公开组件和动态注册的广播组件。

4) 使用Logcat收集测试期间的各类日志信息。

5) 通过对日志信息中“Fatal Exception：main”字符串的监控来获取应用程序崩溃时的相关的日志信息，以及保存造成崩溃的测试用例。

这里仅将测试用例以显式Intent的方式发送给公开组件和动态广播组件。但是表 1构建的几类经典的Data URL数据中content://***数据值可以测试Content Provider组件，测试用例生成策略六可以用来测试私有组件。

3.2 应用崩溃监控

在实际测试过程中，当应用程序发生崩溃时，Android系统会进行系统级别的弹窗以提示用户应用程序已停止运行，需要手动关闭，这在很大程度上影响了自动化的实现。

本文利用Android Accessibility机制能够实时获取当前Android设备窗口状态改变信息和窗口元素信息的特点，通过监听窗口状态的改变来判断系统弹窗，获取窗口的元素信息，采用模拟点击技术关闭弹窗，成功解决了该问题，实现了完全自动化。其具体实现步骤为：

步骤 1  创建一个MyAccessibilityService类继承Accessibility机制提供的AccessibilityService接口类。

步骤 2  注册崩溃窗口监听事件。根据应用崩溃时，窗口上通常会出现“很抱歉，xxx已停止运行。”的提示特征对应用崩溃弹窗进行监听。

步骤 3  实现关闭窗口事件。如果出现了应用崩溃弹窗，则通过findAccessibilityNodeInfoByText函数找到窗口中的“确定”按钮，执行点击操作将弹窗进行关闭。自动化关闭窗口事件的伪代码如下：

   List＜AccessibilityNodeInfo＞

   sorry_nodes=event.getSource().

   findAccessibilityNodeInfosByText("很抱歉");

   if (sorry_nodes!=null & & !sorry_nodes.isEmpty()){

   List＜AccessibilityNodeInfo＞

   ok_nodes=event.getSource().

   findAccessibilityNodeInfosByText("确定");

   if (ok_nodes!=null & & !ok_nodes.isEmpty()){

   AccessibilityNodeInfo node;

   for(int i=0; i＜ok_nodes.size(); i++){

   node=ok_nodes.get(i);

   if(node.getClassName().equals("android.widget.Button") & &

   node.isEnabled()){

   node.performAction

   (AccessibilityNodeInfo.ACTION_CLICK);

   }

  }

 }

}

4 实验与分析

为了验证框架的有效性，本文基于该框架设计实现了工具——DroidRVMS，使用该工具对从Android应用市场下载的300个应用程序进行了组件拒绝服务漏洞挖掘实验，同时，使用开源的组件拒绝服务漏洞挖掘工具Intent Fuzzer^[11]对相同的测试样本进行漏洞挖掘，并将测试结果与DroidRVMS的测试结果进行对比，表明DroidRVMS具有有效性和实用性。

4.1 实验数据和实验环境

实验数据来源于5个主流的第三方应用市场，共300个，涵盖了系统、新闻、影音、办公、交通、社交、购物、游戏共8种类型的应用，应用的分布如表 3所示。

实验环境为安装有Android Nexus5模拟器的64位Windows 7系统计算机，Intel Xeon E3-1231 v3 3.40 GHz CPU, 8 GB内存。

4.2 实验结果分析

使用DroidRVMS对300个测试样本进行测试后共发现112个应用存在组件拒绝服务漏洞，其中导致应用拒绝服务的组件共674个。测试结果如表 4所示。

用Intent Fuzzer工具对相同的测试样本进行Fuzzing测试后，共发现78个应用中存在组件拒绝服务漏洞，419个导致应用拒绝服务的组件。图 2是两个工具的测试结果对比。

从总体数量上看，与Intent Fuzzer工具相比，在相同测试样本的情况下，DroidRVMS能够挖掘出更多的组件拒绝服务漏洞。

为进一步对实验结果进行分析，本文对两个工具发现的不同类型组件引起的组件拒绝服务漏洞数量和检测出的组件拒绝服务漏洞的异常分布情况进行统计，统计结果分别如图 3和图 4所示。

从图 3可以看出，与Intent Fuzzer工具相比，DroidRVMS能够发现除了Activity组件、Service组件和静态Broadcast Receiver组件的拒绝服务漏洞外，还能发现动态Broadcast Receiver组件的拒绝服务漏洞。此外，DroidRVMS发现其他三类组件的拒绝服务漏洞数量都比Intent Fuzzer工具多，说明DroidRVMS能够挖掘出更深层次的组件拒绝服务漏洞。

从图 4可以看出，与Intent Fuzzer工具相比，DroidRVMS能够发现除空指针异常外的更多类型异常导致的组件拒绝服务漏洞，说明DroidRVMS的覆盖范围更广。

由上述实验结果可知，本文设计实现的DroidRVMS能够有效地挖掘出应用中存在的组件拒绝服务漏洞，且比Intent Fuzzer挖掘的层次更深，覆盖范围更广。

5 结语

针对Android应用组件中影响范围广、危害严重的组件拒绝服务漏洞，本文提出了一种结合静态分析技术和动态分析技术的自动化漏洞挖掘框架。该框架通过逆向工程技术和静态数据流分析技术得到组件信息、Intent携带的数据信息和公开组件启动私有组件的路径信息，然后基于此基础上，采用Fuzzing技术和Accessibility技术，使用大量覆盖范围广泛的畸变样本对漏洞进行测试，实现自动挖掘组件拒绝服务漏洞的目标。最后，设计实验与著名组件漏洞挖掘工具Intent Fuzzer进行了比较，实验结果表明，DroidRVMS比现有的组件漏洞挖掘工具具有自动化、覆盖范围广、挖掘层次深、准确率高的优势，具有一定的有效性和实用性。

但是本文提出的漏洞挖掘方法仍然存在一些问题：

1) 在对应用进行Fuzzing测试时，本文根据静态分析结果构造的测试用例存在大量无效的情况，影响了测试的效率。故后面需要对应用进行更精确的静态分析来指导测试用例的生成，提供测试效率。

2) 本文只对未加固应用进行了组件拒绝服务漏洞的自动化挖掘，没有考虑加固应用，下一步需要研究对加固应用的漏洞挖掘。