[2022-1-13] Preventing and Detecting State Inference Attacks on Android

Record Date: Jan.13 2022

Preventing and Detecting
State Inference Attacks on Android
Author: Andrea Possemato、Dario Nisi、Yanick Fratantonio
Institute: EURECOM

一、作者信息

Andrea Possemato：https://dblp.org/pid/227/9091.html
Yanick Fratantonio：https://dblp.org/pid/11/10929.html
https://mobisec.reyammer.io/

二、钓鱼和状态推断攻击

网络钓鱼攻击：Android恶意软件的一个常见功能是进行“网络钓鱼”。网络钓鱼攻击在移动平台上尤其有问题，因为它们不能提供足够的信息让用户可靠地区分合法应用程序和欺骗其UI的恶意应用程序。为了让攻击更有效，常常依靠状态推断攻击。
状态推断攻击：android的一个关键的安全特性是应用程序沙箱。他的机制旨在加强不同应用程序之间的安全边界，并保护敏感信息。在这些敏感信息中，有一个是给定应用程序当前的“状态”。对于“状态”，我们指的是，例如，一个应用程序当前是否在后台，前台，或正在这些状态之间转换。旨在确定另一个应用程序状态的攻击被称为状态推断攻击，这与网络钓鱼攻击特别相关。

三、漏洞分析框架

该框架由六个不同的模块组成。首先，它枚举了攻击面:这个过程涉及三个模块:Extractor(1)，该模块用于提取Android服务；SecurityChecker(2)模块删除了当调用时会导致任何类型安全冲突的“候选”服务或方法；ClassFinder(3)，对于每个服务，它从设备中提取实现它的类的名称(管理器和接口)。一旦服务和类被列举出来，Extractor和SecurityChecker模块就会提取并分析这些类实现的所有方法。所有调用不会引起SecurityException的方法都会被Stimulator模块(4)自动调用，而在后台，UI-Interaction Automator模块(5)会注入不同类型的UI事件来模拟用户启动一个潜在的敏感的应用和它交互。最后，数据分析模块(6)处理收集到的结果。最后的分析步骤是离线执行的，而之前的所有模块都在设备本身上运行。
1. 枚举攻击面
l 所有的Android服务都应该通过以下方法之一公开给系统:addService,publishBinderService或registerService。
l 使用Java Parser解析源代码，并通过查看上面列出的方法提取系统中静态包含的所有服务。为了避免丢失对服务的引用，我们使用命令行程序“service”来提取运行在测试设备上的服务。然后将这两个列表合并在一起。
l 动态分析枚举攻击者可以访问的服务：将所有非系统权限授予我们的测试应用程序，然后与给定的服务通信，同时在后台监视安全异常和违规。
2. 自动化API调用
l 语义参数生成：uid,pid,startTime,id,packageName
l 一般参数生成：采用一种自动方法，并使用递归算法来实例化所有的对象，该算法试图通过迭代所有可用的构造函数来实例化一个对象，并递归地尝试创建一个有效的对象序列，以匹配至少其中一个。所有的基本数据类型及其相应的包装类都用随机值填充。
l 参数生成策略：两种策略。在第一种策略中，一个方法被多次调用而不改变参数。这意味着，对于每个方法，参数只创建一次。在第二个策略中，参数在每次调用方法时都会发生变化。
l 用户界面交互：分析以下几种状态：app还没有启动的时候，用户打开app并与之交互的时候，用户停止app的时候，以及用户恢复app的时候。交互注入多个“事件”的同时，在后台stimulator模块重复调用当前测试中的API。交互模块是建立在androidviewclient之上的。
3. 结果分析
l 检查每个参数-返回值字段在调用过程中其值是否随操作而改变（丢弃过于稳定和过于嘈杂的字段）。
4. 实际评估
Android 8.1，运行在最新可用的Nexus 5X (带有安全补丁，2018年12月)
Android 9，运行在小米MI A2(2019年8月)

24，18个确实存在漏洞，6个假阳性

四、状态推测攻击检测

l 所有现有的技术都结合了静态和动态分析，这可能导致这些方法出现误报。
l 为了保护用户不受未知漏洞的影响，本文研究了一个附加组件的可行性，该组件旨在成为一个运行时防御和检测系统，以在状态推断攻击发生时识别它们。
l 本文设想了基于两个关键假设的防御机制，并通过大规模实验进行了验证。
1. 假设1：所有利用状态推断攻击的现有恶意软件都会实现轮询行为
从所有的Android恶意软件家族中选择了50个样本数据集，这些恶意软件在过去四年中被发现，已知会发起状态推断攻击。特别分析了Anubis、LokiBot、ExoBot、BankBot、RedAlert、MisteryBot、BianLian、Asacub和Gustuff的样本和变体。
人工分析
结果：
恶意软件采用的技术：postDelayed(),AlarmManager,anonymous Thread,IntentService和while循环。所有恶意软件轮询的延迟范围为600毫秒到1秒（最大值）。恶意软件一旦启动就不会停止这种行为（即轮询会持续一段时间）。
2. 假设2：良性应用很少依赖于轮询，当它们依赖轮询时，其行为的性质与恶意应用的行为不同。
10108个具有代表性的应用程序的数据集：9066个“顶级应用”，安装量至少为5000万台。从安装数量从10M到50M不等的应用程序中随机选择了1042个。数据集的20%作为“训练集”，80%作为“测试集”。Android 9-Pixel 3A。
检测系统：1、运行应用程序5分钟。2、记录受监控应用程序执行的所有binder通信。3、标记至少每两秒一次的速率调用的API（最低恶意软件频率的两倍）,同时至少持续60s。
结果：
l 良性应用也存在轮询行为
n API来自GUI (Audio/Video/DRM)
n 详细研究了每个API，发现这些API都不会导致滥用或状态推断攻击。因此，我们可以安全地将这些API列入白名单。
l 启动阶段
n 在良性应用的“启动阶段”内是活动的高峰。（API调用频率）
n 随着应用程序从“启动”阶段过渡到“静止”阶段，活动级别（以API调用频率衡量）降低。因此这和恶意软件是不同的。
3. 状态推断攻击检测系统
l Binder类代码修改
n 修改exeTransaction方法（在系统服务收到请求时调用）
n 记录系统中每个UID的每个API调用（时间戳和目标）
l 对至少60秒每2秒1次调用的速率（即阈值最小频率为0.5HZ）执行API调用的应用程序发出警告。
l 阈值非常保守：它是恶意软件使用的轮询频率的一半
4. 测试
测试集上的设备检测系统（8066应用程序）
对39个app发出警告：
l 10个应用程序只轮询我们发现的易受攻击的API之一getProcessMemoryInfo（CVE-2020-0372）。执行轮询的代码属于第三方库用来持续追踪应用程序内存使用情况的崩溃分析。
l 10个嵌入攻击性广告库的应用程序。用于监视网络状态的API，可能用于收集与附近网络相关的信息（用户跟踪，仍然不利于隐私）。
l 9个良性应用程序由“App Locker”（行为类似于恶意软件，因此无法将此行为与恶意应用程序区分开来）构成。
l 10个应用程序的轮询行为是由糟糕的编码实践引起的。
性能分析：增加了1.98%的开销

五、对比

SCAndroid:
l 只考虑客户端api—在Manager中实现的api，依赖于AOSP文档。相反，本文的分析考虑了更广泛的攻击面—客户端和服务器端组件公开的方法的完整列表。本文依靠AOSP项目的源代码来确定要测试的api列表。
l SCAnDroid执行了一个过滤步骤，只考虑名称以前缀开头的api，比如get、query、has或者is，假设只有命名类似的方法才可能构成漏洞。相反，本文的过滤过程是基于Android系统的内部功能。
l SCAndroid通过反射获取API调用返回值。存在两个问题：1、调用这些方法时可能会永久修改返回值，并且可能会丢失一些数据。2、不能保证存储在对象中的所有信息都可以通过其公共或私有方法访问。
LeaveMeAlone- runtime information gathering attack：
l AppGuardian依靠以前已知的漏洞收集特定应用程序的运行时信息。所有此类漏洞最终将由谷歌修补，从而阻止这种方法发挥作用。
l 一些易受攻击的api不需要任何敏感的许可，这使得使用这些漏洞的恶意应用程序很难被自动审查过程检测到。
l AppGuardian严重依赖白名单来实现他们的方法。
l 容易受到竞争条件的影响。恶意应用和Guardian都依赖于相同方式:如果恶意应用赢得了比赛(并检测到一个受害者应用已经启动)，它可以在Guardian有机会杀死它之前进入前台。

六、结论

● 1 设计了一个自动发现脆弱API的框架并发现了18个脆弱API
● 2 提出并论证了轮询行为可以区分善意和恶意的app
● 3 实现了对状态推断攻击的检测防护方案