论文阅读2023_Usenix Security_Credit Karma-Understanding Security Implications of Exposed Cloud Services

简介

本文当中，研究人员关注了移动应用中广泛使用的云服务，判断其中云服务凭证的过度特权将会产生一系列的问题，由此提出了一种自动化的方法来提取应用中的云服务凭证，推断凭证操作云服务的能力，并验证这些能力是否超出了应用程序的合法需求（即过度授权）。

背景

移动应用程序（应用）的日益普及导致了对后端云服务的强烈需求，例如数据存储、用户认证和通知推送等。云服务上存储和处理的海量敏感用户数据也促使攻击者将注意力转移到云平台，引发了一系列泄漏用户个人信息和公司/政府机密信息的事件。

事实上，应用已经成为了保障云服务的一个薄弱环节。之前的多项研究报告了应用中残留的云凭证会造成不安全的云访问。特别地，Zuo [75]系统地研究了应用中的云凭证，并指出高特权凭证（比如根用户凭证）的滥用是导致云数据泄漏的重要原因。因此，我们可以对常规云用户凭证进行分析，判断它所拥有的细粒度的操作云服务的能力，以便更好的理解其潜在的安全影响。

解决思路

本文通过回答三个关键问题，来系统地研究暴露的云凭证，从而帮助更好地理解应用如何使用常规云用户凭证以及其安全影响：
1）应用开发者在访问云服务时向云凭证授予哪些能力？
2）应用开发者是否经常授予超过应用所需要的能力？
3）超过需要的能力在何种情况下有害（当与其他看似无害的能力结合时，一种非特权的额外能力是否会导致针对云服务的大规模攻击）？

要回答这些问题，我们需要解决两个挑战。
1）与评估应用在其操作系统上的权限（比如Android Permission）不同，如何识别应用在其后端云服务上拥有的能力尚未得到充分解决。缺乏对云服务的可见性使得对应用的分析成为唯一可行的方法，但单独分析应用很难全面了解该应用在云服务上拥有的所有能力。
2）由于云服务的访问控制模型的复杂性和配置策略的不透明性，准确且细粒度的描述应用在其云服务上的能力很困难。

为了解决第一个挑战，本文利用了一种称为induced transaction failure的动态探测方法来补充静态应用分析，进而在不影响数据安全的情况下来推断应用操作云服务的能力。
而针对第二个挑战，本文力图构建最基本的访问控制列表–<主体，客体，云操作>，以消除不同云服务的特定访问控制模型和策略造成的歧义。这项工作将这些想法和一套应用分析技术相结合，构建了一个名为PrivRuler的工具，使我们能够系统地调查应用中使用的云凭证，并识别可能导致用户数据泄露的凭证。

PrivRuler设计

设计如下图所示

1.构建应用数据集

作者团队通过使⽤爬⾍爬取 Google Play [34]来构建应⽤程序数据集。⾸先使⽤ google-play-scraper [53]收集了所有应⽤程序的包名，并随机洗牌下载应⽤程序之前的包名称。因为作者团对研究的是云服务相关，因此有必要进行⼤规模检测（即数百万个应⽤程序）来判断应⽤程序是否使⽤云服务。

为了应对这⼀挑战，作者团队采⽤了两级流⽔线设计。

第⼀阶段，我们通过简单地测试云服务 SDK 的存在来筛选应⽤程序数据集。我们解压应⽤程序并检查⽤于与云后端通信的某些包是否存在于应⽤程序的解压⽂件结构中（例如， com/amazonaws/）。这样的包名称通常不会被混淆，这使得 SDK 存在检测变得简单明了。这个阶段产⽣快速但不太准确的结果。
第⼆阶段，我们通过识别是否在应⽤程序中调⽤了特定的云服务 API来更准确地检测云服务是否确实被应⽤程序使⽤。具体来说，我们⾸先从云服务⽂档中编译出我们感兴趣的云 API 列表。然后我们运⾏ FlowDroid为应⽤程序构建⼀个全局调⽤图，并通过全局调⽤图搜索可访问的云 以及其API。

此时我们已经找到使用云服务的那批程序，进入下一步，从这些从应⽤程序中提取凭据。

2.从应⽤程序中提取凭据

接下来，PrivRuler 从应⽤程序中提取云服务凭证。此类凭据是云服务需要在执⾏云操作时对应⽤程序进⾏⾝份验证和授权。为了提取这些凭据，作者团队应⽤了⼀套程序分析技术。

正则表达式匹配。云凭证通常表现出某些模式，例如，AWS 访问密钥符合AKIA[0-9A-Z]16 （表 5 中提供了更多凭证⽰例）。通过在反编译的应⽤程序代码中搜索此类模式，我们能够提取出许多直接内置到应⽤程序中的凭据。
部分匹配如图所示：

程序切片和动态执行结合方法，在许多情况下，凭据是转换的结果，例如字符串操作、加密/解密过程等，正则表达式匹配在重建凭据⽅⾯受到限制。所以采用程序切片和动态执行相结合的程序分析方法。
具体来说，作者团队从 FlowDroid 计算的应⽤程序⼊⼝点开始，通过整个应⽤程序分析构建⼀个反向程序依赖图。
然后，我们将云 API 的凭证参数标记为感兴趣的值，并进⾏反向程序切⽚以识别可能影响凭证参数的所有指令和变量。切的时候注意，根据已有研究结论，由于云凭证是静态和不变的，它的值应该来⾃程序中的⼀些不变性来源（例如，常量、资源和清单⽂件）。
创建程序切⽚后，我们动态执⾏切⽚以重构凭证。使⽤我们的原型，作者团队通过重新组装影响凭证构造的程序语句，为程序切⽚上的每个⽅法构造⼀个简化的⽅法。然后我们创建⼀个执⾏器⽅法来按照依赖图的顺序调⽤这些简化的⽅法。

接下来，重写应⽤程序的启动器活动，以确保在应⽤程序启动时调⽤执⾏器⽅法。同时，将云 API 添加为记录点，并检测简化的⽅法以确保在云 API 之前记录云凭据。我们通过在未修改的 Android 模拟器中直接启动应⽤程序来执⾏程序⽚段。使⽤ Android 模拟器的好处是它可以有效地解决⼤部分程序依赖性，例如框架 API。然⽽，有些情况可能会阻⽌我们执⾏切⽚和收集凭证，例如，当切⽚取决于⽤⼾输⼊的环境条件时。幸运的是，在我们的评估中（第4.5 节），我们发现这种情况很少⻅，因此我们将其解决⽅案的开发留给未来的研究。

3.将凭证映射到能⼒

下⼀步是判断这些凭证应该怎么对应到其相应的云服务。由于云服务的⿊盒性质，给定某一凭证，以原始策略格式恢复其功能是不可⾏的。
作者团队以访问控制元组的方式表示其映射关系。访问控制元组<OP, OBJ>说明了可以对哪个云对象 (OBJ) 执⾏什么云操作 (OP)。它以尽可能细的粒度捕获功能，同时将访问控制策略的细节视为⿊盒。能⼒映射包含凭据启⽤的访问控制元组列表。

要构建功能图，静态应⽤程序分析是不够的，因为⽆法从应⽤程序中恢复凭证具有但未使⽤的额外功能。为了解决这个问题，我们使⽤动态探测技术，使⽤凭证探测云服务并检查云服务如何响应。
这项技术涉及两个主要挑战。
⾸先，如何通过探测构造<OP, OBJ>元组。
其次，如何在不影响单个应⽤程序⽤⼾的情况下安全且合乎道德地探测云服务。

重构操作 (OP) 很简单，因为可能的云操作只是以移动 SDK 中的云 API 的形式公开。因此，我们可以通过探测云服务是否授权调⽤云 API 来枚举它们。更具挑战性的部分是决定哪些云对象（OBJ）可以被那些云操作访问。
云对象是未知的，并且在不知道它们的情况下，探测将直接失败，因为没有有效对象的探测被云服务视为格式错误。

为了解决这个问题，作者团队观察到云对象主要分为两个概念类别，即容器和元素 。

容器对象通常由应⽤程序开发⼈员在应⽤程序启动之前在云中静态创建，其⽬标是“包含”应⽤程序⽤⼾产⽣的所有数据。对于容器对象，它们的静态是⾃然决定了它们需要嵌⼊到应⽤程序中。因此，我们可以以类似于我们从应⽤程序中提取云凭证的⽅式提取它们的值（即对象名称）

元素对象通常由各个应⽤程序实例在运⾏时动态创建、访问和删除。它们属于各个应⽤程序⽤⼾。元素对象⽆法从应⽤程序中静态恢复。然⽽，我们发现它们的值不会影响操作是否被授权，因为云策略通常是在容器对象的粒度上指定的。因此，我们可以插⼊具有有效云操作和容器对象的⽆效元素对象，以构建有效的动态探测请求。通过将探测请求发送到云服务并检查它们的响应，我们可以因此确定凭证是否被授权执⾏操作，从⽽为凭证构建能⼒映射。

4.检测云凭证是否有过度的特权

通过⽐较凭据具有的功能与应⽤程序所需的功能来确定凭据是否具有过度特权。我们依靠静态应⽤程序分析来确定应⽤程序所需的功能。具体来说，我们使⽤应用数据集中确定的云 API作为所需的云操作集。

此时抛出一个问题我们如何枚举应⽤程序可以但不能访问的容器对象，我们结合三种方法来解决这个问题。
第一种方法，我们利⽤特殊的“listContainerObjects”API（例如，s3:ListAllMyBuckets）来获取凭据可以访问的容器对象列表。此类 API 除了凭证本⾝外不接受任何参数，并返回与云项⽬关联的容器对象列表。虽然简单明了，但这种⽅法在实践中受到限制，因为“listContainerObjects”API 本⾝对应于⼀种功能，许多应⽤程序开发⼈员有意将其从凭据中删除。
第二种方法，guilty by association，我们从同⼀开发者在 Google Play 上的所有应⽤程序中收集凭据和容器对象，并交叉验证他们的访问权限。理由是开发⼈员倾向于为不同的应⽤程序设置相同或关联的云设置。因此，很可能会发⽣能⼒逃逸和错误配置。在实践中，我们发现这种⽅法在识别凭据可以访问的许多对象⽅⾯⾮常有⽤，我们永远⽆法通过分析单个应⽤程序来了解这些对象。例如，我们在智能⻔铃应⽤程序中发现了⼀过度特权的 AWS S3 凭证。该凭证不仅允许访问⻔铃的所有⽤⼾数据，还允许访问来⾃家庭中其他应⽤程序的⽤⼾数据，例如室内和室外摄像头（详情请参阅第4.2节）。
第三种方法也是guilty by association但强调是从⼀个对象的⻆度来看。具体来说，我们构建⼀个⽆向图，其顶点是<app, container object>元组。只要容器对象的名称是⾮通⽤值（即⾄少包含两个词汇或包含⾮词汇的字符串，例如vioozer-videos-raw⽽不是照⽚或数据），就会将容器对象添加到图中。如果 1) 顶点具有相同的容器对象名称，则我们在两个顶点之间绘制⼀条边；或 2) 顶点对应于同⼀个应⽤程序。之后，我们在每个连接的子图中交叉验证对容器对象的访问。这种⽅法不仅可以让我们找到凭证的更多隐藏功能，还可以发现⼀些有趣的发现，即由不同开发⼈员发布并具有不同凭证的应⽤程序共享对相同容器对象的访问。

5. 识别易受攻击的应用程序

并⾮所有额外功能都同样有害。为了指导漏洞确认和修补的优先级排序， PrivRuler 具有另⼀个组件，该组件决定何时过度权限可能导致漏洞，攻击者可以利⽤该漏洞对应⽤程序⽤⼾发起⼤规模攻击。
我们采⽤的⽅法是由启发式驱动的。具体来说，我们调查了权限过⾼的应⽤程序，以了解如何滥⽤额外的功能（尤其是当它们与应⽤程序所需的其他功能结合使⽤时）来对应⽤程序⽤⼾进⾏攻击，并将常⻅的攻击模式总结为启发式。然后，我们应⽤启发式⽅法来识别可能容易受到⼤规模类似问题影响的应⽤程序。
由于资源有限，我们专注于⼀些⾼调的云操作和围绕它们的潜在
攻击，例如⻥叉式⽹络钓⻥攻击，攻击者可以在其中对应⽤程序⽤
⼾发起⼤规模（和有针对性的）⽹络钓⻥活动，数据泄漏攻击，攻
击者可以在其中进⾏⼤规模收集应⽤⽤⼾的敏感数据，以及攻击
者可以任意修改其他应⽤⽤⼾依赖的应⽤数据的数据污染攻击。
攻击示例如下：

6.探测行为可能会造成连接失败

虽然动态探测使我们能够确定应⽤程序凭据在云服务上拥有的功能，但它会产⽣安全和道德问题。任何读取（或写⼊）云对象的云操作都可能导致数据泄漏（或污染）攻击，尤其是当对象对应于应⽤程序⽤⼾的个⼈数据时。因此，要确保不会因动态探测云服务⽽导致数据泄露或修改。
为了解决这个问题，我们引⼊了⼀种称为动态探测的诱导事务失败的技术，核⼼思想是将云操作模为事务。通过在交易中注⼊故障，云操作最终⽆法执⾏，从⽽导致⽆法化访问或更改应⽤程序⽤⼾的数据。然⽽，通过策略性地注⼊故障，我们可以通过检查云操作的错误代码来间接推断正在使⽤的凭证的能⼒。

未完待续