【论文总结】Demystifying Resource Management Risks in Emerging Mobile App-in-App Ecosystems

11011b

已于 2023-05-11 14:21:38 修改

阅读量153

点赞数 1

文章标签：小程序安全

于 2023-05-09 19:28:31 首次发布

本文链接：https://blog.csdn.net/m0_56280274/article/details/130547350

版权

解开新兴移动应用中的资源管理风险的神秘面纱

一、背景:

应用软件的快速发展，使得行业竞争加剧，常用软件需要不断开发新功能以吸引用户，由此使得 $“ A pp - in - a pp ”$ 迅速兴起，以满足人们多样性需求，提供全方位服务，让用户投入更多时间。但 $“ A pp - in - a pp ”$ 与其开发平台的关系与软件和操作系统之间的关系存在巨大不同， $“ A pp - in - a pp ”$ 开发平台无法提供操作系统基本的安全策略，使得 $” A pp - in - a pp “$ 存在巨大安全隐患。这类安全隐患称为**“APINA 缺陷”**。

“App-in-app”:

基于本地应用开发的子应用（把本地应用比作操作系统， $“ A pp - in - a pp ”$ 就如同是其中的应用），例如:微信中的小程序就是 $“ A pp - in - a pp ”$ 。

二、移动"App-in-app"系统

1.架构

为了使子应用获得类似原生应用的体验，每个主应用都为子应用提供了一套子应用API，以便子应用访问不同的系统资源，通常使用脚本语言(JavaScript)进行开发。
通常主机应用由一个子应用层和一个子程序运行层组成，前者为所有子程序所在处，后者是为系统和主机应用提供资源访问的统抽象。子应用运行时将自身API连接到主机应用的原生层，由原生层强制执行子应用权限来调用相应API访问资源。

2.资源管理上的安全机制

"App-in-app"系统使用传统的权限标签分配模式来保护子应用的API，当子应用请资源时会给予子应用API权限，如果是敏感资源，则需要主机应用增强子应用权限以调用应用API。

传统的权限标签分配模式：

传统的权限标签分配模式通常是基于角色的访问控制（Role-Based Access Control，RBAC）模型。这种模型将用户分配到不同的角色当中，每个角色都拥有一组特定的权限和访问控制规则。对于一个系统中的某个资源，管理员可以指定哪些角色能够访问该资源，并设置相应的访问权限。

3.对比现有应用程序封装系统

除移动"App-in-app"系统外，其它方法也可以实现类似功能，例如“安卓插件框架”和“移动应用沙盒”。与其它方法不同，移动"App-in-app"系统为子应用访问系统资源建立了自己的API生态系统，因此需要付出巨大的努力来构建和维护安全机制。这种安全机制在面对访问复杂系统资源的子应用API来说是不全面的，从而容易产生新的攻击面。并且相比于其它专门用于应用封装的解决方案，移动"App-in-app"系统中的主机通常功能丰富，这些功能也通常与子应用共享，从而在互动中产生了新的攻击面。这些攻击面的总和即为我们所说的”APINA 缺陷。

安卓插件框架：

通过包装用于调用插件应用的系统API，使得主机应用可以从APK文件中加载其它安卓应用，从而在主机自己的进程中运行，使得这些应用程序在执行过程中共享主机的UID和系统权限。

移动应用沙盒：

在一个可信的沙盒应用的背景下，将不受信任的应用封装在一个受限的执行环境中，通过提供一个模拟层，并在不受信任的应用和操作系统中间插入所有交互，以减少对底层操作系统的直接接触。

三、主要的APINA 缺陷

1.系统资源暴露

子应用通过子应用API访问系统资源，但是由于子应用API权限策略存在缺漏，导致子应用API权限和相关系统权限要求不一致，使得部分敏感系统资源不知不觉中暴露给未经授权的子应用，导致系统资源暴露问题，而这些被暴露的API被称为"逃脱的子应用API"，。

2.子窗口欺骗

为了满足 $“ A pp - in - a pp ”$ 和本地应用间功能级之间的相互作用这一特征，本地应用并没有将自己与应用程序完全隔离开，使得浏览器的突出UI混淆问题格外突出，由于子应用是在独立于浏览器窗口的专用窗口中打开，而子应用中打开的链接窗口与子应用所处窗口存在明显区别，很容易识别钓鱼网站，但这也导致用户过于相信专用窗口，而由于这些子应用支持范围外浏览，因此当用户浏览其它网络域的服务时很容易被导航到一个仿窗口的钓鱼页面从而被误导。
此外也存在移动钱包的UI混淆问题，由于用户在点击结账后会调用子应用的API来触发本地应用的钱包输入密码进行付款，这会导致用户在点击结账后下意识的相信付款界面。如果恶意程序如果在点击结账后显示伪造的钱包界面而不是调用真正钱包的API接口就会导致密码泄露，并且很难被移动反钓鱼技术识别。

3.子应用生命周期劫持

受操作系统限制，每个主机应用只能创建固定数量的任务，当一个额外子应用在达到任务限制后被打开时，主机应用会回收第一个打开的子应用以启动新的应用，为了避免打断用户体验而未通知用户这就会产生一个新的攻击面“屏幕替换”。并且由于主机应用真正外部存储中创建了文件夹来缓存子应用资源，而这种外部存储也会被本地应用监控，以推断出被回收的子应用，从而在屏幕上插入伪造的假任务以模仿被回收的子应用程序来诱导用户输入隐私信息。

屏幕替换：

恶意应用通过外部资源文件伪造被回收的子程序应用界面，而用户并不知道真正的子应用程序已经被系统回收，错以为被伪造的子应用程序是真的，从而相信伪造的子应用程序。

四、如何查找’'APINA 缺陷"

为了查找现存的’‘APINA 缺陷"，本文建立了一个自动分析工具-Apinat，通过使用这个工具来帮助识别容易受到’'APINA 缺陷"影响的本地应用。

1.查找系统资源暴露

(1) 设计思路

通过动态分析跟踪子应用 $A P I$ 触发的系统 $A P I$ 调用，再利用系统 $A P I$ -权限图得出子应用 $A P I$ 所需权限，将这些权限与相应的子应用权限进行比较，如果一个子应用 $A P I$ 没有受到任何子应用权限的保护，而其对应的系统API受到系统保护，那么就会发现一个逃脱的子应用 $A P I$ 。

(2)具体实现

<1>生成测试样例
使用 $M oz i ll a$ 的 $f u n f u zz$ 来递归生成测试用例，所有测试样例再统一由搭建的子应用程序来调用API。如果某个API所有测试用例都失败了就手动检测来解决格式化输入、有状态调用等问题。

递归生成测试用例:

样例对象为键值对，键为基本类型，但是值的类型可以是基本类型也可以是对象，从而会在值中继续递归构建对象。

有状态调用：

在调用一个 $A P I$ 之前需要先调用另一个 $A P I$ .
<2>跟踪系统API
由于子应用 $A P I$ 的执行需要通过 $d i s p a t c h er . d i s p a t c h$ 函数进入主机的原生层，因此本文首先识别主机应用原生层中的dispatcher.dispatch 函数，然后跟踪dispatcher.dispatch的调用图，找到子应用 $A P I$ 调用所触发的系统 $A P I$ .

识别主机应用原生层中的dispatcher.dispatch函数：

因为 $W e b v i e w$ 和 $R e a c t$ $N a t i v e$ 是将 $d i s p a t c h er . d i s p a t c h$ 方法暴露给 $J a v a S cr i pt$ 层的桥梁技术(虽然函数名在不同主机应用中有所不同，但可以通过检测 $E n c a p s u l a t i o n$ $l ib$ 库中的函数调用确定),因此我们只需要根据获得的别名来识别原生层的调度对象即可。为此，本文中实现了 $Xp ose d$ (一个用于记录安卓应用执行的框架)模块来关联 $W e b v i e w$ $A P I$ ,通过在运行时检查参数确定是否为我们寻找的调度器对象。对于 $R e a c t$ $N a t i v e$ 则有所不同，我们需要关联它的 $A P I$ $cre a t e N a t i v e M o d u l es$ 来获取其暴露在 $J a v a S cr i pt$ 层中的 $J a v a$ 对象，然后再使用 $Xp ose d$ 模块调用每个暴露的对象的 $g e tN am e$ 方法来获取它的别名，再和之前一样检查是否与发现的调度器别名匹配即可找到 $d i s p a t c h er . d i s p a t c h$ 方法。

跟踪dispatcher.dispatch的调用图:

$Xp ose d$ 模块会关联 $d i s p a t c h$ 方法和安卓 $A P I$ ，通过检查他们各自的堆栈调用痕迹来，以此查找哪些系统 $A P I$ 被调用来满足子应用程序的 $A P I$ 调用。为了解决 $d i s p a t c h$ 方法有时不直接调用安卓 $A P I$ 而是使用额外的线程来调用的问题，本文在 $Xp ose d$ 模块中实现了基于 $H an d l er$ 机制的线程关联技术。

<3>合成API-权限映射
因为系统 $A P I$ -权限映射是不完整的，从而产生逃脱的子应用 $A P I$ 。为了推导出完整的映射，在本文中，通过编写网络爬虫、提取关键词来使用文档分析来补充最新的映射。从而合成 $A P I$ -权限映射.

使用文档分析来补充最新的映射

通过自动提取开发操作手册中明确声明的系统 $A P I$ 的权限来补充，但是文档的表述并不全是完整的，可能会误导人类读者，不过，如果是对整个移动操作系统的语料库进行详尽的、基于机器的搜索，能得到比当今最先进映射更完整的映射。具体为使用网络爬虫实现)
<4>报告缺陷
对于 $A n d ro i d$ 来说，如果子应用 $A P I$ 没有受到子应用权限保护，而其对应 $A n d ro i d$ $A P I$ 受到危险权限的保护，那么当前子应用 $A P I$ 即为”逃脱的子应用 $A P I$ “，即系统资源暴露缺陷。
对于 $i OS$ 来说，由于系统 $A P I$ -权限映射获取难度极大，本文将”逃脱的子应用 $A P I$ “从 $A n d r i o d$ 扩展到了 $i OS$ ,通过检查子应用 $A P I$ 对应的 $i OS$ $A P I$ 是否需要权限来确定是否存在”逃脱的子应用 $A P I$ 。

(3)结果分析

实验环境:在 $G oo g l e$ $P i x e l$ $2$ 手机和 $i P h o n e$ $8$ 上的 $11$ 个主机应用程序，在 $3$ 个 $A n d ro i d$ 版本（ $8.1 、 9 、 10$ ，对应 $A P I$ 级别 $27 、 28 、 29$ ）和两个 $i OS$ 版本（ $12 、 13.4$ ）上进行。
实验结果: $A p ina t$ 发现 $39$ 个系统资源暴露漏洞：它们全部影响 $A n d ro i d 8.1 、 9$ 和 $10$ ；其中 $13$ 个影响 $i OS 12$ 和 $13.4$ 。

2.查找UI欺骗缺陷

(1) 设计思路

$A p ina t$ 通过寻找应用程序中可以成为攻击目标的敏感子窗口，如果这些敏感子窗口也存在敏感信息，那么就可以报告这些为子窗口欺骗的潜在目标。

(2)具体实现

$A p ina t$ 监控主机 $U I$ 在响应每个子应用的 $A P I$ 调用时的变化，以此识别由 $A P I$ 调用引发的子窗口，通过分析是否携带敏感内容来决定是否要报告。

分析是否携带敏感内容：

通过使用 $M e d ia$ $P ro j ec t i o n$ $A P I$ 在 $A n d ro i d$ 上开发屏幕投影服务来捕捉屏幕截图。再使用 $Op e n C V$ $c v 2. ab s d i ff$ $A P I$ 来进行截图对比。对于确定的子窗口，通过使用在线 $OCR$ 服务从子窗口屏幕截图中提取字符串， $A p ina t$ 会将提取的字符串和敏感数据关键词列表进行比对来识别敏感数据。

(3)结果分析

$A p ina t$ 检测到 $5$ 个与 $U I$ 欺骗漏洞相关的子应用程序 $A P I$ ，本文中手动确认了它们都会触发显示包含敏感信息的子窗口。此外，它们都会影响 $A n d ro i d$ （版本 $8.1 、 9 、 10$ ）和 $i OS$ （版本 $12 、 13.4$ ）。从性能方面来看，在一台搭载 $I n t e l i 5$ $2.7$ $G Hz$ $CP U$ 和 $8$ $GB$ 内存的桌面电脑上，截屏比较和 $OCR$ 分析的时间少于 $5$ 秒,有较高的效率。

五、警醒和缓解措施

1.警醒

一方面，当在操作系统只是建立第三方子生态系统时，应当采取谨慎的态度。第三方类似于操作系统的应用程序努力提供一个安全的、自包含的环境。其是否会削弱操作系统的安全性并为现代移动应用程序带来新的风险，需要通过评估新的子生态系统和操作系统之间的安全漏洞来确定。另一方面， $A P I N A$ 风险来自于主机应用程序管理操作系统资源的有限应用程序级别能力、缺乏操作系统级别的支持以及缺失子应用程序 $A P I$ 标准。因此，未来需要进行非常实质性的、联合的努力来从根本上消除 $A P I N A$ 风险。
同时本文测量研究显示，流行的主机应用程序通常容易受到 $A P I N A$ 漏洞的影响，这表明今天的应用程序中内置应用程序系统厂商还需要进一步的努力。并且本文的发现还突显了先前的操作系统经验不能完全消除新范例所带来的新风险，这警示我们面对其新攻击面时需要进行全面评估。

2.缓解措施

要解决 $A P I N A$ 缺陷问题不是一件简单的事，是需要大家长期共同努力的，为此提出以下临时应对方法以解决燃眉之急。

(1)系统资源暴露

本文设想了两个可能的未来方向，可能推出更可行的解决方案。
一方面，可以通过开发人员文档分析显著提高程序分析技术准确性和全面性。在未来，我们可以开发基于自然语言处理（ $N L P$ ）的技术，以推导出更完整的 $A P I$ 权限策略知识。借助这些技术，分析可以覆盖更广泛的文献范围，包括 $i OS$ 文档、研究论文、技术报告等，这将有助于推导关于资源管理策略的最新知识。
另一方面，应用内应用社区可以合作制定子应用程序 $A P I$ 及其权限策略的标准，以方便 $A P I$ 权限映射的推导。

(2)子窗口欺骗

在子应用程序和主机之间实现更高程度的UI隔离：子应用程序的窗口应始终与主机的窗口分开，主机不应从子应用程序的窗口中夺取任何窗口部分。若恶意的子应用程序模拟崩溃然后在子应用程序窗口中显示欺骗内容以类似于主机，则可以通过主机提供的额外保护来缓解。

(3)子应用生命周期劫持

短期的防御方法是将所有子应用程序资源放置在手机的内部存储器中，以防止被恶意程序推导出被回收的子程序。
但这会有一个问题，即这样会耗尽手机内部存储器上的有限空间的担心。对此长期的解决方案需要考虑如何使子应用程序任务具有动态可扩展性，以确保子应用程序回收不再可跟踪，从而从根本上消除攻击面。不过，这需要现代操作系统对新兴的应用程序内应用程序范式提供支持。

个人总结

汇总

本文首先介绍了移动"App-in-app"系统的基本架构以及资源管理上的安全机制(传统的权限标签分配模式),通过对比现有应用程序封装系统发现移动"App-in-app"系统为子应用访问系统资源建立了自己的API生态系统，这种安全机制在面对访问复杂系统资源的子应用API来说是不全面的，容易产生新的攻击面即“APINA 缺陷”。随后细致探讨了“APINA缺陷”的三种类型：“系统资源暴露”、“子窗口欺骗”、“子应用生命周期劫持”。为了查找现存的’'APINA 缺陷"，本文建立了一个自动分析工具-Apinat，为了检测可能存在的’APINA 缺陷"，本文针对“系统资源暴露”和“UI欺骗缺陷”进行了相关测试样例的生成，并针对二者采取了不同的方法进行实验以查找可能存在的漏洞，最后针对实验中发现的漏洞提出了一些暂时性的方案来缓解燃眉之急。

实验思路

首先，对于“系统资源暴露”问题，其是由于子应用API权限和相关系统权限要求不一致，引起的，因此我们可以通过动态分析跟踪子应用 $A P I$ 触发的系统 $A P I$ 调用，再利用系统 $A P I$ -权限图得出子应用 $A P I$ 所需权限，将这些权限与相应的子应用权限进行比较即可查找到逃逸的子应用 $A P I$ 。具体的说，我们首先采用递归的方式生成测试样例，而后通过跟踪子应用 $A P I$ 的执行，绘出权限调用图，再通过分析文档合成 $A P I$ -权限映射，最后即可通过对比分析是否产生逃逸的子应用 $A P I$ 。

对于“UI欺骗缺陷”，本文通过 $A p ina t$ 监控主机 $U I$ 在响应每个子应用的 $A P I$ 调用时的变化，以此识别由 $A P I$ 调用引发的子窗口，通过图像识别提取字符串，将获取的字符串和敏感数据关键词比对，通过是否存在敏感关键词来决定是否要报告。

个人构思

对于“系统资源暴露”问题，一个比较暴力的想法是：因为“系统资源暴露”问题无非就是某些子应用在没有授权的情况下调用了高于自身等级的特权 $A P I$ ，我们可以将所有特权 $A P I$ 标记,再通过未获取授权的子应用去尝试获取这些特权 $A P I$ ，如果成功获取到那么就显然存在逃逸的子应用 $A P I$ .。

对于“ $U I$ 欺骗缺陷”，我们通过阅读文章可以发现，大部分“ $U I$ 欺骗缺陷”都是诱导用户到其它仿造子应用窗口的钓鱼网站，并且为了增加欺骗性，钓鱼网站通常与官方网站几乎完全一样，特别是在隐私数据获取上，因此我们可以通过记录涉及敏感信息的真正子应用窗口，再比子应用跳转打开的其它网络域的子窗口，通过图片对比，一定程度上比大量字符串的提取比对会更加具有效率。

11011b

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
【论文总结】Demystifying Resource Management Risks in Emerging Mobile App-in-App Ecosystems

应用软件的快速发展，使得行业竞争加剧，常用软件需要不断开发新功能以吸引用户，由此使得App−in−app迅速兴起，以满足人们多样性需求，提供全方位服务，让用户投入更多时间。但App−in−app与其开发平台的关系与软件和操作系统之间的关系存在巨大不同，App−in−app开发平台无法提供操作系统基本的安全策略，使得App−in−app存在巨大安全隐患。这类安全隐患称为**“APINA 缺陷”**。
复制链接

扫一扫