0 引言

Android自面世以来，发展极为迅速，国际数据公司(IDC)统计数据表明^[1]，2016年Android智能手机市场占比为86.8%，同比增长5.1%.Android从1.0发展到如今的7.1版本，在性能和用户体验上都有了质的提升.Android的多任务处理机制^[2]使得用户可以在不同的应用程序之间方便的切换，当前进程被切换到后台时，多任务机制会让进程进入暂停的状态，只会在内存中保存应用的运行状态，因此不会占用CPU的资源.Android的多任务处理机制也使得用户在再次进入应用程序时，能够迅速启动，且其平滑的应用程序切换大大提高了用户体验.

然而，Android的多任务处理机制以及Activity的设计自身却存在一些缺陷，攻击者可以利用这些漏洞对用户进行攻击.Activity劫持已经是攻击者常用的手段，2015年USENIX上Ren等人^[3]分析了680多万个应用程序，发现任务劫持缺陷也普遍存在于Android各大应用市场的应用程序中.

Android目前存在的劫持方式主要为Activity劫持^[4].Activity劫持大部分采用了界面覆盖或强行关闭目标进程并弹出虚假界面的方式，通常通过监听系统日志、枚举当前进程等方式来实现其攻击目的.Activity劫持主要针对各类登陆界面账号信息和金融类相关软件支付界面，其目的在于获取用户的账号密码、支付密码等.由于缺少严格、专业的审核机制，无法保证所有平台上应用程序的安全性，造成了恶意软件的大范围传播^[5]，Activity劫持给用户造成了极大的损失.

Ren等人^[3]研究发现，与Activity紧密相关的任务，在当前大部分通用的Android下也存在设计上的不合理，可以被利用进行任务劫持，并提出了任务劫持的概念.与Activity劫持不同的是，任务劫持是基于Activity所在任务及返回栈相关属性进行劫持的一种手段.通过一定的属性设计，可以实现Activity在不同任务之间的转移及覆盖等行为.他们的研究显示，攻击者可以利用任务劫持攻击来实现用户界面(UI, user interface)欺骗，拒绝服务攻击和用户监控攻击.攻击者很可能会窃取登陆的证书，并且对用户的Activity进行勒索和监控.

已有研究^[3]将taskAffinity与allowTaskReparenting或FLAG_ACTIVITY_NEW_ TASK等标记相结合，可将Activity加入到同名任务或实现任务迁移行为，从而实现任务劫持攻击.但其构建的多数攻击模型存在较大限制，尤其在诱使目标应用加入恶意任务所在返回栈时(对应攻击模型HST#2、#4及#5)，HST#2、#5对目标应用的启动方式及相关属性有一定设定要求；HST#4仅对极少数launchMode为singleTask的应用有效，如部分系统自带应用，而此类应用数量较少，因此该模型通用性较弱.

在对taskAffinity及launchMode属性的研究中发现，Android在应用程序启动流程判定中存在一定疏漏，当系统后台有同名任务存在时，部分目标应用程序会出现无法启动甚至被恶意软件劫持等现象.

本文对taskAffinity及launchMode属性的部分组合进行了相关研究实验，从APP界面钓鱼及APP勒索、拒绝服务等方面提出了可行的攻击模型，该攻击模型几乎可以对当前所有上架软件进行攻击实现；同时本文对应用程序启动流程中的各类逻辑判定错误进行了梳理，解释了该攻击模型的原理，提出了可能的检测方案，并通过实验证实了攻防两方面方案的有效性.

与已有研究的区别在于本文在已有研究的基础上发现了新的攻击模型，攻击模型只作用于应用启动过程，同时首次提出了可行的检测方案.

本文后续各节内容如下：第1节对Activity相关属性及任务相关概念进行了介绍；第2节介绍了本文提出的程序劫持与任务隐藏两种攻击模型；第3节提出了具体的攻击场景；第4节给出了攻击实验的具体数据及分析；第5节提出了检测中的难点及检测方案，并给出检测结果和分析.第6节对本文进行了总结并提出了未来的工作计划.

1 Activity组件、任务及返回栈状态转换机制

本节将对Activity的生命周期及返回栈相关概念进行介绍，并对Activity与返回栈的关系进行阐明.

1.1 Activity生命周期

Android系统中，Activity具有运行(running)、暂停(paused)、停止(stopped)及销毁(destroyed)这四种状态^[6].

Activity启动入栈便处于运行状态，Activity处于可见状态并位于屏幕前端，在该状态下，用户可以与当前Activity进行交互操作.

Activity被透明Activity覆盖或部分被遮挡时则将处于暂停状态.此时Activity仍然处于可见状态，系统会为其维护内部状态，但由于失去焦点故不可与用户进行交互操作.

Activity移居后台或被完全覆盖时，则处于停止状态.此时Activity完全不可见，在系统内存不足时有可能被强行结束.

Activity被系统销毁时即为销毁状态，一般由用户操作或是系统强行销毁所致.

与Activity生命周期相关的函数分别为onCreate()，onRestart()，onStart()，onResume()，onPause()，onStop()，onDestory().相关函数与Activity状态之间关系如图 1所示.

1.2 任务与返回栈(Task and Back Stack)

任务，为用户在使用应用程序或执行某种工作时所使用到的Activity的集合^[7].返回栈用于存储这些Activity，任务即以返回栈的形式存在.Activity在返回栈中按照时间顺序排列，最后启动的Activity位于返回栈的顶端.

大部分的任务都开始于Home界面，当用户点击某个应用程序图标或者推送通知，相关任务将被置于前台.如后台任务不存在，则会为其新创建一个任务.在当前Activity中启动新的Activity，这个新的Activity便会位于返回栈的顶端，之前所有的Activity都被销毁后，任务也同时消失.

返回栈中Activity的顺序无法被改变，一旦按照Activity开启时间入栈，这个顺序将无法被重新调整.返回栈遵从后进先出原则，Activity的销毁顺序也同样无法修改.

任务是一个集合，它使得用户在切换界面时可以整体地进行移动.用户切换应用时，任务进入后台，返回栈将会被完整地保留，返回栈中所有的Activity处于停止状态.在所有Activity都隶属于同一任务时，返回栈原理图如图 2所示.

1.3 TaskAffinity属性的正常应用

TaskAffinity属性通常不单独使用，常见的用法是将其与allowTaskReparenting^[8]搭配进行使用.两种属性的结合可以实现Activity在不同任务之间的转移.例如在某个应用程序Activity中打开网页链接，打开网页链接动作的跳转Activity一般属于浏览器应用(例如Android原生浏览器Browser)，因此该Activity与浏览器具有一致的taskAffinity.在该界面退居后台瞬间，可以发生任务的跳转，即网页Activity将转移到浏览器所在任务中.在用户再次进入应用程序界面时便无法看到网页界面，但打开浏览器时可显示该网页.这是许多应用程序常用的方法.

若需要taskAffinity属性单独生效，需要将intent设定为FLAG_ACTIVITY_NEW_TASK或launchMode设定为singleTask.另一种常用的方式是将taskAffinity属性与FLAG_ACTIVITY_NEW_ TASK标记一同使用，这种情况多用于桌面插件或者通知栏插件.从当前Activity中启动的新Activity默认位于同一个任务中，倘若后台已有运行的应用程序，从桌面或者通知栏点击该应用程序对应的插件产生的新Activity将会被加入到应用程序的默认任务中，此时从当前界面返回将落入当前Activity下方的另一个Activity中^[9]，这不是桌面插件与通知栏插件所需要的效果.一般为了实现插件的便捷性，从桌面插件直接返回到桌面才是插件所需要达到的目的，此时便需要产生新的任务来完成这个需求.为插件产生的Activity重新分配一个taskAffinity，通过FLAG_ACTIVITY_NEW_TASK标记，可以创建新的返回栈，这样便可与原应用程序的任务区分开来，以实现退出即为桌面的效果.

2 攻击模型

本节将对程序劫持及任务隐藏两种攻击模型进行介绍，从攻击条件、攻击案例及原理分析三个方面进行详细的描述.

Activity有四种启动模式standard、singleTop、singleTask和singleInstance，其中standard模式是默认的启动模式，未对launchMode进行设置则默认为standard模式^[10].在对taskAffinity属性及任务劫持分析过程中，发现在不同launchMode下，可进行程序劫持和任务隐藏攻击，且两种攻击方式对绝大部分应用程序有效，适用性极强.两种攻击模型可用P∧Q →R来进行描述，其中P为目标应用，Q为恶意程序，R为攻击模型.下面对这两种攻击模型进行具体描述.

2.1 程序劫持 2.1.1 攻击条件及方式

当目标应用launchMode为standard或singleTop时，通过设定恶意程序taskAffinity与目标Activity一致，攻击者可以轻松劫持目标程序.

该攻击模型可表示为:

如图 3所示，此时恶意程序具有与目标Activity相同的taskAffinity，且潜伏在后台时，如果目标程序启动，则恶意程序从后台被调度到前台，从而获得控制权.数据分析显示，考虑到用户体验，大部分应用程序都不会将launchMode设定为singleInstance与singleTask，因此其启动方式一般默认为standard或singleTop，可见本攻击模型适用性极强.

2.1.2 攻击案例及分析

针对本模型，本文以QQ程序为攻击目标程序，假设恶意程序为hijackingtest，首先设定恶意程序taskAffinity与QQ程序一致(com.tencent.mobileqq)，然后启动应用程序hijackingtest，随后启动目标应用QQ.启动QQ后，屏幕上显示应用程序hijackingtest界面.

通过adb对应命令查看当前返回栈状态可以发现，名为com.tencent.mobileqq的返回栈中仅包含一个ActivityA(即隶属于应用程序hijackingtest的Activity)，如图 4所示.

通过Hook相关函数，本文得到以上示例案例中Activity生命周期函数调用的日志信息，如图 5所示.可见，启动应用程序QQ后，系统调用了应用程序hijackingtest中ActivityA的onRestart函数，即在当前情况下，QQ并未被启动，而是重新唤起了后台的hijackingtest.

2.2 任务隐藏 2.2.1 攻击条件及方式

对任意已运行目标程序，如果设定恶意程序的程序名称及taskAffinity与目标程序保持一致，且launchMode设定为singleInstance，则恶意程序运行后可以构建与目标程序同名的返回栈，并以不同任务ID存在于后台，从而可将目标任务隐藏于后台.具体如图 6所示.

该攻击模型可表示为:

2.2.2 攻击案例及分析

针对本模型，本文设定目标程序为支付宝，恶意程序为attack，设定恶意程序taskAffinity与支付宝一致(com.eg.android.AlipayGphone)，launchMode为singleInstance.

首先启动支付宝，其启动后会创建以其包名com.eg.android.AlipayGphone为名的任务.通过adb对应命令查看当前返回栈状态，具体如图 7所示，此时存在名为com.eg.android.AlipayGphone，ID为657的任务.

然后启动恶意程序attack，此时再次查看任务栈，如图 8所示，可发现任务中出现了两个不同ID的同名任务栈，但当前后台任务中仅能显示ID为658的恶意任务(仅包含一个Activity)，即目标任务从后台列表被隐藏.

2.3 攻击原理分析

以上两个攻击模型均与APP的launchMode有关，Android源码中对launchMode的处理主要位于ActivityStack.cpp文件的startActivityUnchecked-Locked^[11]函数中.

该函数的执行流程如图 9所示，首先对sourceRecord进行判断(当应用从桌面启动时，该值为null)，如果为null，则进行launchMode的判断.之后launchMode判定的关键代码显示，当launchMode为LAUNCH_SINGLE_INSTANCE时将调用findActivityLocked()函数，其他情况将调用findTaskLocked()函数.

1) launchMode=“standard”或“singleTop”

当launchMode为standard或singleTop时，其执行流程如图 10所示，首先进入findTaskLocked()函数，该函数将对当前已有任务的栈顶Activity进行遍历.当任务affinity与当前启动Activity一致时，返回该返回栈栈顶Activity，并赋给intentActivity.

在launchMode为standard或singleTop的处理流程中，将调用moveTaskToFrontLocked()函数将intentActivity所指后台任务移动到前台.

最终系统将调用resumeTopActivityLocked()函数，该函数最终会调用当前返回栈栈顶Activity的onRestart()函数.

可以得出，当launchMode设置为standard或singleTop时，倘若后台有同名返回栈存在，将返回该返回栈栈顶Activity，且直接对当前栈顶Activity执行重启动请求.

判定缺陷分析：设定singleTop与standard会出现启动已有任务，而自身目标程序无法启动的关键原因在于findTaskLocked()函数.一般来说，新启动的应用程序后台理应不存在其所需的任务，因此intentActivity应被置空.此时后面的判断机制将不被执行，因设定taskAffinity使后台存在了所需任务，intentActivity不再为空，函数返回值为当前返回栈中的顶端Activity，后面的判断机制依次执行，最终直接执行resumeTopActivityLocked()，使得顶端Activity被置于前台，而非创建所需的Activity.

2) launchMode=“singleTask”

因本文所提出的攻击方式与singleTask启动方式无关，此处不再赘述.

3) launchMode=“singleInstance”

当launchMode为singleInstance时，其执行流程如图 11所示，首先将调用findActivityLocked()，该函数将遍历当前所有返回栈中的Activity.因当前Activity为第一次启动，后台不存在与之匹配的Activity，findActivityLocked()函数将返回null.

接下来调用createTaskRecord()创建新任务，新任务创建成功后，调用startActivityLocked()函数启动新的Activity.

当该新任务创建成功后，若有相同affinity的Activity企图加入当前任务，findTaskLocked()函数将自动过滤加入请求，因此该任务中始终只存在一个Activity.

当launchMode为singleInstance时，若当前Activity为首次启动，无论后台是否存在同名任务，都将创建新的任务并将当前Activity压入任务返回栈中.此后该任务中便不可添加除当前Activity之外的其他Activity，该任务将一直以单Activity的形式存在，所有入栈请求都将被忽略.

判定缺陷分析：将launchMode设定为single-Instance时，倘若后台不存在同名任务，则该处理流程不存在任何问题.但一旦具有同名任务，虽有可复用的任务存在，系统仍然会创建一个新的任务并赋予不同的Taskid，致使系统中存在两个同名但不同id的任务.而系统运行任务列表中同一名称任务仅显示最近运行的任务，从而造成了两者位于同一任务的错觉.

分析四种launchMode处理流程后可以发现，出现上述几种现象的根本原因在于Activity启动流程过程中，未考虑到后台有同名任务存在的情况.当后台出现相同任务，该判定逻辑便不再严谨.

3 攻击实例

恶意软件可通过偷渡式下载^[12]等方式，引诱用户安装恶意软件，并实施攻击.

本节将根据上文提出的攻击模型，从钓鱼和勒索(阻止启动)两方面提出具体的攻击场景.攻击场景所需具体攻击条件如表 1所示.

3.1 钓鱼

攻击场景1：设置恶意程序界面与社交软件登陆界面保持一致，并通过一定手段驻留在手机后台.当用户在桌面点击开启社交软件时，将直接显示驻留在后台的虚假登陆界面，真实的社交软件将不会被启动，即可实现窃取用户登陆账号密码.

攻击场景2：设置恶意程序界面与目标登陆界面或付款界面保持一致，通过一定方法驻留在后台，并对目标软件进行检测，一旦检测到目标应用Activity启动，便启动自身，将虚假界面显示在屏幕上；或检测到目标Activity转移到后台，便在后台启动自身，将目标任务隐藏，替换并将其潜伏在后台任务列表中，等待用户的后台调用.此时通过从后台运行程序可以发现虚假界面位于目标应用同名任务中，但无法看到目标程序所在任务.

3.2 勒索、阻止启动

攻击场景3：恶意程序将自身设定为开机自启动，驻留在后台，并通过Activity相关属性(如excludeFromRecents)将其任务从后台任务列表中移除，从而使用户无法察觉恶意软件的存在，并以此阻止用户从后台关闭恶意程序.在当前情况下，点击目标应用图标将无法启动应用，而只能弹出恶意程序勒索界面.只要恶意软件存活，目标应用将一直无法启动.通过这种方式可以阻止通讯、社交、金融类应用启动，致使用户无法使用相关软件，并进行勒索.或者，也可以通过该种方式阻止安全类软件启动，为恶意软件长期驻留创造条件.

4 攻击实验及分析

在Android版本4.3.1、6.0.0、7.1.0下，对系统应用程序及多个知名应用市场下载量在100万以上的社交软件、手机银行软件进行实验后发现，绝大部分应用程序都可以通过设定launchMode实现钓鱼和勒索攻击.本文对国内多个知名应用商店中60款社交软件、金融软件等高人气软件及手机系统应用等进行攻击测试，结果表明58款均可通过程序劫持实现钓鱼、阻止启动攻击，60款可通过任务隐藏实现钓鱼攻击.部分软件实现效果如表 2所示.

无法进行程序劫持攻击的2款应用，即应用启动方式为singleTask的应用无法实现本文中程序劫持的效果，但该类样本并非无法攻击，同等攻击条件下其实现的攻击效果为Ren等人^[3]研究中对应的攻击模型HST#4.

实验数据显示96.7%的应用适用于本文提出程序劫持攻击模型，100%的应用均适用于任务隐藏攻击模型，且两类攻击模型所利用的系统判定漏洞截止Android 7.1.0尚未被修复，即可适用于当前所有的Android版本.

可以看出，几乎所有主流应用程序均无法避免以上几种攻击行为.因该攻击行为的实现基于Android自身的逻辑缺陷，因此无法从应用角度对劫持行为作出有效的防御.

5 检测

本节首先概述了当前攻击模型在检测中存在的难点，从任务返回栈内信息是否一致的角度提出了可能的检测方案，并对检测数据进行了统计与分析.

5.1 检测难点

在Android系统中，taskAffinity与launchMode均为正常的属性，且在Android应用中有较多的应用，尤其在第三方插件中使用较为广泛.对应用Activity的taskAffinity与launchMode属性进行设定，本身无任何恶意性，同时，taskAffinity属性在Activity相关日志信息中公开可见，软件开发者在开发过程中可任意使用该属性，因此无法简单地通过判定是否设定taskAffinity与launchMode属性来检测应用的恶意性.

5.2 检测方案

当前模型下，无法从应用程序的实现中对该种劫持行为进行规避，但可以从用户角度，实现对后台任务及栈中Activity归属进行实时监控，警示可疑的栈内变化.

阻止程序劫持和任务隐藏攻击模型存在一个共性，即taskAffinity属性一定与攻击目标保持一致.但是攻击目标taskAffinity属性通常为其自身程序包名，因此位于栈顶的恶意Activity，其包名一定与当前任务名不一致.因此，可提出如下两种检测方案：

方法1  强制每个Activity启动过程中增加自检模块，启动时自动进行当前任务与包名比对，并在异常时提出警示，判定流程如图 12所示.

方法2  在后台对当前所有任务与Activity进行监控，每当有新的Activity启动时，自动对当前所有任务与栈内底端(baseActivity)、顶端Activity(topActivity)进行信息比对，并在异常时提出警示，判定流程如图 13所示.

以上两种检测方案可作用于应用程序启动过程，应用程序启动时进行任务核对，实时对当前栈内信息进行检测，倘若栈内正常，则略过当前Activity，同时对taskAffinity属性为空的情况进行过滤，判定其为正常应用.将taskAffinity属性设定为空时，任务名称默认为其“包名/Activity名”，因此在检测过程中对该种情况进行过滤.

因正常模型下也有可能存在包名栈名不匹配的情况，所以不能简单地认定异常Activity一定为恶意Activity，因此有两种可供选择的方案：一是及时弹出警示信息当前栈内有可疑Activity存在，给予警示由用户自行判定；二是通过建立白名单以及用户添加信任列表来过滤正常的入栈请求，譬如设定合法第三方插件包名为过滤信息，并通过用户添加信任应用的方式来避免多余的警示提醒.

5.3 检测结果

从国内各大Android应用下载平台下载量超过100万的社交、金融及第三方插件中挑选了60个正常样本，并针对其中20款主流应用构建了恶意样本, 采取更为严密的方法2进行了恶意检测，20款利用该漏洞的恶意应用均被检出，1款正常软件在使用过程中被误报.

系统检出率达到100%，误报率仅为1.67%，有效地对文中的攻击模型进行了检测.

为测试本检测方案的性能损耗，本文对50款应用程序分别进行了测试，记录其启动耗时，检测前后平均耗时分别为1.903 5s及2.003 5s.对比前后平均耗时，可得出该检测方案的性能损耗约为5.3%.

6 结论

目前，Android劫持方面的研究大多为Activity劫持，从任务角度对攻击进行的研究分析相对较少.本文对Activity及任务的相关属性及机制进行了梳理与归纳, 通过对Android源码的分析，根据应用程序启动过程中的逻辑漏洞，提出了可能的攻击模型并给出了攻击模型的基本检测思想，验证了检测方案的有效性.

下一步研究将对检测系统进行进一步的优化，寻求更为准确的判定条件，降低检测误报率.