论文总结—app-in-app应用程序生态系统内资源管理风险

介绍

这是一篇来自CCS 2020的论文《Demystifying Resource Management Risks in Emerging Mobile App-in-App Ecosystems》。这篇论文首次对应用内系统中的资源进行系统研究，揭示了一些高危漏洞，并开发出自动化工具对11个应用进行测量。

前置知识

app-in-app定义

app-in-app是一种新的移动计算模式，其中子应用的原生类应用软件通常由主流的一些移动应用管理，来丰富应用的功能，形成“all-in-one app”的生态系统。子应用可以通过主机应用程序访问系统资源。子应用的功能在主机应用中相当于常规的应用功能（拍照，录音，银行，购物等）。

Android权限

Android权限分为系统权限和自定义权限。系统权限是由开发者决定是否开放的，自定义权限是我们在使用一个APP时自己授予的权限。自定义权限有三个保护权限：normal，signature和dangerous。前两个是安装时权限，在安装的过程中，通过弹框提醒用户进行许可。后一个是运行时权限，例如，读取用户的联系人是一种危险的权限。如果一个应用程序声明它需要一个危险的权限，用户必须显式地授予该应用程序权限。
如果应用程序在它的清单中声明它需要一个正常的权限，系统会在安装时自动授予该权限。系统不提示用户授予正常权限，用户也不能撤销这些权限。
如果某个app获得某个特权组的dangerous权限，当它请求别的dangerous权限时就会被自动授予，无需弹框请求。
关于Android权限更详细的参考如下：Android 基础知识：Android 应用权限详解

IOS权限

关于IOS权限详细的参考如下： Provisioning Profile & Entitlements

app-in-app范式

一个app-in-app系统是受主机应用程序控制的，主机应用程序分配给子程序资源，也包括一些子应用程序需要的操作系统资源。因此，主机应用程序的行为就类似与操作系统，为子应用程序提供自己的API（也称子应用API），以便其进行访问。此外，主机应用程序也使用自己的基于权限的访问控制机制，调节子应用程序对关键资源（如GPS位置、麦克风、摄像头、蓝牙、照片等）的安全访问。
可以在应用内平台上同时运行的子应用的数量上限是公开的和固定的（Chrome中为8个，微信中为5个，HostAppA中为4个），当达到限制时，主机必须终止子应用程序以启动新应用程序。

研究背景

先前对移动权限再授权的研究表明：一个特权应用可能会通过未受保护的公共接口，将操作系统资源泄露给恶意的应用。然而，对于app-in-app系统，主机应用可以调节子应用程序对敏感信息的访问，从来可以避免移动权限再授权的风险。但是，主机没有操作系统级别的资源管理信息，它很难正确地去管理系统资源。
由于子应用程序在主机窗口中呈现，恶意的子应用程序很难和主机应用以及其他安全关键服务（如银行，电子商务等）区别开来，难以防范钓鱼技术。

app-in-app结构

为了让子应用程序提供本地应用程序体验，每个主机应用程序为子应用程序提供了子应用程序API，以访问不同资源。通常子应用程序都是用脚本语言开发的，其功能通过主机跨平台运行时实现的。其结构如下：

1. 子应用层：所有子应用程序存在的地方
2. 子应用程序进行时：为系统和主机应用程序资源提供通用抽象，子应用程序将子应用程序API调用连接到本地层，本地层执行主机应用程序的本地权限，并访问主机资源或调用相应的系统API来访问系统资源

以子应用程序调用WIFI功能为例，在脚本层调用子应用程序API（connectWiFi）会触发封装库，然后调用本地的函数dispatcher.dispath(“connectWiFi”)将控制流桥接到本地层。
主机程序桥接的两种技术：WebView和React Native。

资源管理的安全模型

1. 子应用程序权限：子应用程序使用传统的权限标签分配模型来保护子应用程序API。如果一个子应用程序API访问敏感资源时，主机应用程序将执行子应用程序权限，以调用子应用程序API。
2. 隔离：每个子应用程序都有由主机应用程序分配的唯一ID。每个子应用程序都有一个唯一的数据存储，由主机应用程序管理。
3. 子应用程序审查：所有子应用商店也要求在发布前对子应用进行审查。子应用程序审查过程包括风险评估以及其他标准，以确定子应用程序是否违反用户隐私或数据安全要求。

与现有应用封装系统的比较

和app-in-app系统相似，其他方法也可以通过“封装”的方法使一个app运行在另一个app中。

1. Android插件框架：一种应用程序虚拟化技术，通过该技术，“主机”应用程序可以从其APK文件中加载其他Android应用程序（称为“插件”应用程序），以在主机自己的进程中运行。这是通过包装用于调用插件应用程序的系统API来实现的，插件应用程序在执行过程中共享主机的UID和权限。
2. 应用程序沙盒：在受信任的沙盒应用程序的上下文中，将不受信任的应用程序封装在受限制的执行环境中，该应用程序提供仿真层来抽象底层操作系统，并插入不受信任应用程序和操作系统之间的所有交互。（例如，系统调用、绑定IPC）
3. 浏览器扩展：一个小程序在支持HTML5（用于受控系统资源访问）和扩展API（用于浏览器资源访问）的情况下定制web浏览器，以及PhoneGap应用（或基于HTML5的移动应用），其中中间件框架（例如PhoneGap、Cordova、Ionic）用于允许开发者使用web技术创建移动应用。

APINA flaw

系统资源暴露

Escaped sub-app API

子应用程序API受子应用程序权限保护，子应用程序权限应该和操作系统所需要相关API的权限一致，比如，操作系统需要权限去使用安卓的RECORD_AUDIO，子应用API如wx.startRecord应该由子应用权限scope.record保护。
包装受权限保护的系统API的某些子应用程序API完全向任何子应用程序开放，而不需要子应用程序权限，从而暴露敏感的系统资源，这就是Escaped sub-app API。
举个例子，未受保护的微信子应用API wx.getWifiList进行了WIFI Scan获取了敏感信息。WIFI Scan由底层操作系统进行保护，防止信息泄露，在Android中属于dangerous的location权限ACCESS_COARSE_LOCATION andACCESS_FINE_LOCATION，在IOS中属于entitlement Hotspot Helper。但是未经权限保护的子应用API在没有权限允许时却可以调用相关权限。

子窗口欺骗

浏览器突出子应用程序用户界面错误

一般而言，IOS的Safari和Android的Chrome都会在与浏览器窗口分开的整个专用窗口中打开每个子应用，就像本地应用一样——没有浏览界面，如地址栏等。在用户确认后，浏览器可以在手机主屏幕上安装一个网络应用程序，如果在Manifest文件中指定了“独立”或“全屏”，则此类Web应用程序将全屏显示。当用户导航到Web应用范围外的URL时，突出显示地址栏提醒用户正在访问的地址。
Web应用程序旨在支持范围外浏览，并允许用户自由导航到其他Web域以获取服务，例如通过Facebook/Google登录、通过PayPal支付等。问题是，当受害者用户导航到范围外，例如，Facebook登录页面时，恶意Web应用程序实际上可以导航到模仿Facebook的范围内网络钓鱼页面，显示虚假的突出用户界面，以误导性地告知受害者她在真实的Facebook域上。通过这种方式，恶意Web应用程序可以收集受害者用户的秘密，如Facebook密码。

移动钱包用户界面错误

微信和HostAppA都有移动钱包，电子商务子应用可以利用移动钱包为用户提供便捷的支付流程。例如，亚马逊子应用程序在用户点击“使用微信钱包结账”按钮后，将调用子应用程序API（例如，微信中的wx.requestPayment）来触发主机的钱包；然后，主机从子应用程序收回屏幕的中央部分，以显示其钱包UI（图4a中突出显示），供用户输入钱包密码并完成付款。这样的上下文可以限制用户在结账时反射性地提供钱包密码，因此提供了一个实际的欺骗目标。
当受害者用户点击恶意电子商务子应用程序中的“check out”按钮时，会弹出假钱包窃取用户信息。

子应用生命周期劫持

子应用程序的任务具有限制（Chrome中为8个，微信中为5个，HostAppA中为4个）。当达到任务限制后打开另一个子应用程序时，主机应用程序会静默地执行强制回收过程：关闭第一个打开的子应用程序，回收其任务，以启动新的子应用。
一旦恶意应用程序可追踪到回收，即知道哪个子应用程序已被回收以及何时被回收，它可以偷偷地将钓鱼任务插入“最近”屏幕，以模仿默默回收的子应用程序。为此，需要获取主机任务回收的相关信息，这是可行的，因为存在各种难以消除的信息泄漏渠道。恶意本地应用程序可以在最近屏幕中插入虚假任务，以模拟回收的子应用程序。

测量

识别系统资源暴露

其思想是查找不受子应用程序权限保护的子应用程序API，而其相应的系统API受权限保护。方法通过动态分析跟踪子应用程序API触发的系统API调用，然后利用系统API权限映射导出子应用程序API所需的权限，其将与相应的子应用权限进行比较，如果子应用程序API不受任何子应用程序权限保护，而其相应的系统API受Android危险权限或iOS权限保护，则找到了Escaped sub-app API。

1. 生成测试用例：利用了Mozilla的funfuzz，一个JavaScript工具包，我们构建的子应用程序使用所有测试用例来调用子应用程序API。
2. 追踪系统API：首先在主机应用的本地层识别dispatcher.dispatch方法，然后查看子应用程序API调用的系统API。具体来说，可以通过检查封装库的函数调用的对象别名（dispatcher）和函数名（dispatch）。封装库通常在主机应用程序中打包的JavaScript文件中找到（如assets/folder），因此只要根据获得的别名在本地层中识别dispatcher对象。
   使用了Xposed模块来勾住Webview API addJavaScriptInterface(obj,alias)并检查参数，如果alias参数和dispatcher别名匹配，则obj就是我们查找的dispatcher对象。对于React Native来说，就是勾住API createNativeModule来获取对象，然后调用对象的getName方法获得它的别名，如果别名与dispatcher匹配，则对象为我们要查找的对象。
3. 合成API权限映射：自动提取系统API的显示声明权限，开发网络爬虫去自动获取开发者手册并提取每个API描述。
4. 报告缺陷：如果子应用程序API没有受子应用权限保护，而它相关的Android API受dangerous权限保护，就找到了系统资源暴露缺陷了

查找UI欺骗缺陷

监控主机UI响应于每个子应用程序API调用的变化，以识别由API调用触发的子窗口，然后确定其是否携带敏感内容。

1. 首先构建一个空UI的测试子应用程序
2. 运用子应用程序API测试用例，通过测试子应用调用每个子应用API，并进一步检查调用前后的UI屏幕截图，使用Media Projection API开发屏幕服务，通过OpenCV cv2.absdiff API 进行屏幕比较，使用在线OCR服务从子窗口截图中提取字符串。从字符串中，进一步利用121个敏感数据关键字的列表和关键字对列表来识别携带敏感内容。与移动操作系统一样，应用内应用系统也为子应用提供了一组子应用API，以动态生成UI组件，为了控制误报，根据子应用程序API文档中的API类别省略了此类子应用程序API。

测量角度

1. 漏洞范围
2. 对Android和IOS进行比较
3. 漏洞攻击后果

经验教训和缓解战略

APINA风险来自于主机应用在管理操作系统资源方面的应用程序级能力有限、缺乏操作系统级支持以及缺少子应用程序API标准。

Escaped Sub-app API

消除风险需要主机具有关于资源控制（例如API权限映射）的完整操作系统级知识。尽管当今的程序分析技术很难得出完整的系统API权限映射]，但可以通过开发人员文档分析显著提高其准确性和全面性，可以开发基于自然语言处理（NLP）的技术，以获得关于API许可策略的更完整的知识。
需要将子应用API及其许可政策标准化

子应用窗口欺骗

子应用和主机之间实现更高程度的UI隔离：子应用的窗口应始终与主机的窗口分开，并且主机不应从子应用窗口中回收任何窗口部分。这可以通过主机支持的附加保护来缓解。具体而言，主机应用程序可以继续监控其子应用程序的UI（例如，通过PixelCopy API来进行监控子应用程序窗口）

子应用生命周期劫持

短期防御措施是将所有子应用程序资源放在手机的内部存储中，因此可以缓解当前跟踪子应用程序生命周期终止的漏洞。
长期解决方案需要考虑如何使子应用任务动态可伸缩，以确保子应用回收不再可追踪，从而从根本上消除攻击面。