G.O.S.S.I.P 阅读推荐 2022-09-08 Identity Confusion

在上个月末刚刚结束的USENIX Security 2022中，来自复旦大学系统软件与安全实验室与霍普金斯大学曹寅志老师研究组合作的关于移动应用小程序生态安全问题的论文Identity Confusion in WebView-based Mobile App-in-app Ecosystems斩获了今年USENIX Security 2022的杰出论文奖。今天我们非常荣幸的邀请到了论文的作者来为我们介绍一下这篇杰出的研究工作😆

论文主要聚焦于移动应用小程序生态安全问题，揭示了微信、支付宝、抖音、今日头条等一批主流软件面临的严重安全威胁，避免了数十亿用户的信息安全风险，论文工作也得到国内外学术界和产业界的高度认可！

过去几年中，坐拥庞大用户基数，在社交、新闻、金融等不同重点领域中成为龙头般存在的国内外企业，相继推出了各自的小程序生态（App-in-app Ecosystem），例如微信、支付宝、今日头条、Microsoft Teams等超级应用（Super-app）。这些超级应用选择将自身部分业务逻辑开放给第三方开发者其基于此构建轻量化的小程序（Sub-app），同时能为自身带来更丰富的内容和更多样化的功能。这些小程序运行在超级应用提供的基于WebView定制的运行环境中，其不仅可以从各个三方云服务器动态加载代码运行，还能够利用超级应用提供的各种特权功能接口（Privileged API）访问敏感系统资源（例如地理位置，麦克风，摄像头等）以及用户隐私数据（例如账户信息、联系人、注册手机号等）。

这其中存在一个关键性安全问题—如何判别谁能访问这些特权接口—一个属于访问控制范畴的经典问题。然而小程序生态中对敏感接口调用者的身份定义多种多样，而且都不够原子性，普遍存在对特定“身份”权限过宽，违背最小特权原则而且容易伪造的问题，作者将该其定义为“身份混淆（Identity Confusion）”。

作者针对市面上流行的超级应用展开了深入的研究分析，对这些生态中采用到的身份标识进行系统性调研分类，并进一步探究基于该类身份构建的访问控制存在何种安全漏洞，这些安全漏洞造成的影响是怎样的。

研究点一：小程序生态系统分析

作者首先对小程序生态展开了初步调研分析，分析围绕流行小程序生态运行时架构、小程序编程模型和生命周期、现有身份检查类型、以及特权API使用情况四个方面开展。

作者首先结合静态识别WebView组件的使用以及搜索引擎确认是否支持小程序，从知名应用商店（Google Play、豌豆荚等）中找到15个流行的超级应用。作者通过逆向工程技术，分析并归纳总结出小程序生态的运行架构模型。

如上图所示，有三个关键组成部分：

1. 内嵌的浏览器实例. 例如Android系统中的WebView组件，或iOS中的WKWebView。

2. 运行时特权API. 提供给小程序访问各种各样资源，不同的超级应用能够提供不同的资源和API。

3. Web-to-mobile通信桥梁. 超级应用通过分发模块（Dispatcher），将来自小程序对特权API的调用事件分发到特定的Java函数进行处理。注意，在不同的超级应用中实现的方式会不尽相同。

小程序类似于轻量级网页应用，也是由JavaScript，HTML，CSS语言组成，运行于内嵌浏览器环境中，并且能够通过Web-to-mobile桥梁访问到超级应用提供的特权API。通常情况下，用户可以通过扫描二维码，或点击特定链接来启动指定小程序，在这一过程中，超级应用也会自动从自己拥有的小程序应用市场中动态下发该小程序的代码。此外，这个被启动的小程序还能自行从云端加载额外的网页代码。

值得注意的是，这些代码都能够通过Web-to-mobile通信桥梁发起对特权API的调用，而且作者发现，超级应用实际上提供了大量的特权接口，其中只有少部分通过官方文档等方式公开给小程序开发者，还有近50%是实际存在但未公开于官方文档中。据作者分析，这部分隐藏的API有很多是高度敏感的，能够访问敏感的系统资源或者调用超级应用本身的敏感业务模块。

同时，超级应用为了对来自小程序的敏感API调用进行安全检查，也在调用链中的两个关键地方实现了身份鉴权：一是在小程序进行外部资源加载的时候；二是WebView实例中运行的代码要访问特权API时。本文也进一步分析并总结了这些身份检查的策略和方式，如下表：

基于此，本文将小程序生态中的身份标识分为三种：

1. 域名（Domain Name）. 作为web资源域的一部分，代表了一个云端服务器以及从该服务器上获取到的所有云端代码资源。

2. 小程序ID（App ID）.  由超级应用为小程序分发的唯一标识符。

3. 能力（Capability）. 从超级应用或服务端协商生成的秘密字符串，小程序调用特权API时需携带该字符串。作者发现，有两种凭据分发方式。在第一种方式中，一个小程序通过调用隐藏API来向超级应用获取凭据。第二种方式中，该凭据的生成是在小程序服务端，经过与超级应用的服务端完成双向验证后才可生成。

经过调研，本文发现，大部分超级应用会混用多种身份检查来保障安全，并且在加载资源时和访问特权API时这两个关键环节都会进行身份检查。而且由于不同超级应用会有不同的身份检查策略（Policy）和定制化情况，使得具体的检查过程更加碎片化和个性化。但同时，这些混用的身份标识也使得安全检查变得复杂，彼此之间又难以补全，进一步导致身份混淆漏洞的出现。

研究点二：身份混淆漏洞分析

威胁模型假设

基于对小程序架构和资源身份标识的分析，本文提出了两类安全威胁模型：

1. 漏洞小程序，即正在运行的小程序是不存在恶意行为的，但是存在其中一种身份混淆漏洞，导致远程攻击者可以用这个漏洞小程序为跳板发起攻击。本文发现，有大量流行小程序可以用作攻击跳板，甚至包含不少超级应用自身提供的各类常用小程序。攻击者只需散布恶意二维码或者恶意链接即可发起这类攻击。

2. 恶意小程序，即攻击者可以上传一个恶意的小程序，并诱导受害者使用，同时释放攻击。

身份混淆漏洞

然后，本文对小程序架构进行了深入的安全分析，总结并提出了三类身份混淆漏洞：

1. 基于域名的混淆. 即特权API的调用者域名与实际检查的域名不一致。更进一步，作者将此种混淆分类两个维度上：

   a. 由条件竞争带来的基于时间维度的混淆。本文通过对WebView各类事件回调接口的分析发现，由于WebView内核本身的多线程特性，这些接口本身难以准确的实时获取当前页面的域名信息，例如onPageStarted()，loadURL()等，而这些接口却大量被超级应用直接用于各类身份获取和安全检查中，直接导致调用者身份被混淆的问题。此外，作者还进一步发现，超级应用本身的API分发调度机制（Dispatcher），也通常采用多线程设计，也会与身份检查线程产生竞争而进一步导致身份混淆。

   b. 由嵌套网页结构带来的基于框架维度的混淆。作者的调研分析指出，大部分WebView提供的事件处理函数都无法获取精确到框架粒度的域名信息。

   
   

2. 基于小程序ID的混淆. 即一个具有高权限身份的小程序中的任意网页资源都能访问特权API，使得加载到该漏洞小程序运行环境中的恶意网页也拥有了同等权限。该混淆漏洞的关键在于能向特权小程序中注入恶意网页。作者指出三种漏洞方式：

   a. 资源加载白名单检查匹配不严格。

   b. 错误的资源URL解析方式。

   c. 资源加载检查缺失。
3. 基于能力的混淆. 即象征着特权的秘密字符串能够被攻击者获取，从而越权调用特权API。作者发现两种制造混淆的方式，分别对应两类获取能力的方法：

   a. 借助隐藏API获取。

   b. 借助暴露的服务端接口获取。

研究点三：漏洞检测与安全评估

作者通过静态分析技术从6,000个流行应用中找到了存在小程序生态框架的47个超级应用，针对每个类型的身份混淆漏洞设计了对应的漏洞检测脚本，验证了47个被研究的超级应用普遍存在身份混淆的安全问题，其中部分超级应用存在不止一种身份混淆。具体来说，9个超级应用没有采取任何安全措施来保护超级应用的敏感功能接口。剩下38个超级应用对资源加载的检查存在安全漏洞，15个超级应用采取了基于域名的访问控制机制并且都遭受域名混淆漏洞的影响。还有两个超级应用中的能力管控存在疏漏，也可能造成访问控制的失效。

研究指出，身份混淆漏洞会导致以下三种严重的安全后果:

1. 越权访问。

2. 钓鱼攻击。

3. 隐私泄露。

具体来说，38个超级应用都可能遭受越权攻击，其中31个存在钓鱼，35个存在潜在的敏感信息泄漏。作者通过漏洞验证技术（PoV）进一步证实这些应用的安卓版本和iOS版本均受漏洞影响，对广大用户群体产生严重的安全威胁。

该研究对小程序生态的安全发展有重大参考价值，研究团队与国家信息安全漏洞共享平台CNVD、涉及厂商积极协作，并提供漏洞修复方案，以共同维护小程序生态中的用户信息安全，得到各方的高度赞赏！

论文下载：https://www.usenix.org/system/files/sec22-zhang-lei.pdf

论文slides：

https://www.usenix.org/system/files/sec22_slides-zhang_lei.pdf

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2022-09-08 Identity Confusion