PendingIntent-security | LLeaves Blog

type

status

date

slug

summary

0x00 参考

💡

本文完全摘录自OPPO 子午安全实验室heeeeen等人在BlackHat的汇报和公众号文章

此处仅作学习记录，指路原文，感谢前辈们的杰出工作和分享

https://mp.weixin.qq.com/s/lB3yV1-VE3X-CmqN2T5KCw

https://mp.weixin.qq.com/s/ifrErL88_8wN36WT8QbLvg

EU-21-He-Re-route-Your-Intent-for-Privilege-Escalation-A-Universal-Way-to-Exploit-Android-PendingIntents-in-High-profile-and-System-Apps.pdf

0x01 重定向Intent

1. PendingIntent

PendingIntent 是 Android 中的一种特殊 Intent，它允许其他应用或系统以创建者的应用身份执行指定的代码。常用于通知、闹钟和小部件等需要在将来某个时间触发操作的场景。具体而言，当创建一个 PendingIntent 时，实际上为其他应用或系统组件提供了一个授权，允许它们在未来的某个时刻以创建者的应用身份执行指定的操作。

设置PendingIntent.FLAG_UPDATE_CURRENT 标志位，如果已有相同的 PendingIntent 存在，则更新其内容。没有设置PendingIntent.FLAG_IMMUTABLE 则说明 PendingIntent 可变。这个PendingIntent对象可以发送给其他App使用，其他App调用PendingIntent.send时，就能够以PendingIntent源App的身份和权限发送PendingIntent中的base Intent。其他App甚至还可以提供一个新的Intent，对base Intent进行改写。

2. BroadcastAnyWhere漏洞

用户在 Settings 应用中尝试添加一个账户，Settings 应用调用 AccountManagerService 的 addAccount 方法。AccountManagerService 在处理 addAccount() 请求时，会创建一个包含 PendingIntent 的 options Bundle 对象。这个 PendingIntent 的 base Intent 是一个空的 Intent（即未指定具体的操作或目标组件）。AccountManagerService 通过回调函数将这个 options Bundle 对象传递给目标 Authenticator 应用（即 AppB）的 addAccount() 方法。由于 PendingIntent 的 base Intent 为空，恶意的 Authenticator 应用可以利用这个 PendingIntent，填充任意的 Intent 内容，由于这个广播PendingIntent由system_server AccountManagerService(uid 1000)所创建，代表了系统的身份和权限，且并未设置base Intent的其他字段，因此恶意程序可以以系统权限(UID 1000)发送任意的广播。

3. PendingIntent使用场景

PendingIntent在Android系统的使用中又如此广泛，在IPC通信中的使用仅为冰山一⻆。
PendingIntent还可以广泛存在于SliceProviders、通知(Notifications)、媒体浏览服务(MediaBrowserServices)、窗口小部件(AppWidgets)、定时器管理器(AlarmManager)当中，这就触及了本议题要解决的第一个问题:Android中这些广泛使用的PendingIntent是否有可能被App获取，如何获取

#SliceProvider

SliceProvider 是 Android 中的一种组件，用于提供应用程序的切片（Slice）。切片是一种 UI 模块，可以在其他应用程序（如 Google 搜索）中显示应用程序的内容。SliceProvider 继承自 ContentProvider，并负责定义和提供这些切片。

content://android.settings.slices/action/toggle_nfc这个URI共享给别的应用使用，用户不必打开Settings，就可以在其他应用界面中对NFC开关进行操作

Slice中的动作SliceAction，实质是通过PendingIntent实现的。

按照SliceProvider的设计，作为SlicePresenter的App可以通过调用系统APISliceVIewManager.bindSlice 去bind一个特定URI的SliceProvider，或者直接使用更加底层的SliceProvider call函数去获得一个Slice，进而获得Slice中的PendingIntent

#Notifications

通知在Android系统中应用极为广泛，用于在状态栏中对用户进行提示，几乎为每个App所使用，是安卓开发者最常使用PendingIntent的地方，如下为发送通知的示例代码

通过 setContentIntent 方法对通知设置了一个contentIntent PendingIntent，使用户在点击通知的正文时，触发PendingIntent，跳转到AlertDetails。除了contentIntent外，通知中还可以设置其他按钮，通过actionIntent进行设置，下面的通知示例表明了通知中的各种PendingIntent。另外，通知还可能包括另外一个deleteIntent PendingIntent，在被用户删除通知时触发。

#MediaBrowserService

媒体浏览器服务MediaBrowserService与音乐播放有关，可以让其他App发现、浏览媒体内容并控制播放。媒体浏览服务中也可能使用PendingIntent来作为回调。那么其他App可以实现媒体浏览器MediaBrowser来连接MediaBrowserService，进而获取PendingIntent。

MediaBrowser与MediaBrowserService的实现架构如图所示。MediaBrowser作为客户端，实现了UI、媒体控制和媒体浏览的功能，连接MediaBrowserService，获得媒体内容层次结构的表示，如播放列表、媒体库等等，并获得有关播放状态的回调信息。

#AppWidgets

4.不安全PendingIntent的通用利用方法

我们需要辨别什么样的PendingIntent是不安全的。前面描述的公开漏洞案例，均为劫持base Intent为空Intent的广播PendingIntent。

在 Android 12 之前，尽管开发者文档对使用 隐式 Intent 构建的 PendingIntent 提出了安全警告，但并未详细说明具体的安全风险或可能造成的危害。使用隐式 Intent 构建的 PendingIntent 是否真的存在安全问题？只有找到一种能够针对这种 PendingIntent 的具体漏洞利用方法，才能真正证明这些安全问题确实存在。

#深入`Intent fillIn`改写机制

寻找利用方法之前，需要深入探索PendingIntent的改写机制，这决定了其他App获得PendingIntent以后，如何对base Intent进行改写。这个机制由Intent.fillIn函数提供：

在上述代码中，this对象指向当前Intent，other为其他Intent。如果当前Intent中的成员变量为空，则可以被other中相应的成员变量覆盖。比较特殊的是Intent中的component和selector成员，即使当前Intent中的component和selector为空，也不能被other所改写，除非PendingIntent设置了FILL_IN_COMPONENT或者FILL_IN_SELECTOR标志。除此之外，由于讨论隐式设置了Action的情况，此时this.action不为null，从而无法被设置。

#PendingIntent重定向攻击

在获取一个 PendingIntent 之后，其关联的基础 Intent（即 base Intent）中的一些成员，如 action、category、data、clipData、package、flags、extras 等，都有可能被修改；但是 component 和 selector 这两个成员无法被修改。特别是，当 base Intent 是一个 隐式 Intent 时，action 已经被设置，并且无法被修改。因此，攻击者无法像之前 Android 系统中的 broadcastAnyWhere 漏洞那样，通过劫持 PendingIntent，在 base Intent 中重新添加 action，从而隐式地打开一个受保护的组件。

这里就来到了问题解决的关键点，由于package可以指定，回想到以前在Intent Bridge漏洞中的利用方法，我们可以通过设置intent中的flag来巧妙地解决这个问题。Intent提供了有关临时授权的标志:

FLAG_GRANT_READ_URI_PERMISSION: Intent携带此标志时，Intent的接收者将获得Intent所携带data URI以及clipdata URI中的读权限

FLAG_GRANT_WRITE_URI_PERMISSION: Intent携带此标志时，Intent的接收者将获得Intent所携带data URI以及clipdata URI中的写权限

简言之，恶意App对PendingIntent进行了指向恶意App自己的重定向，通过对PendingIntent base Intent的部分修改(修改包名、授权标志和data/clipdata)，使其以受害App的权限打开恶意App自身，这样恶意App在被打开的瞬间即获得对受害App私有数据的读写权限。具体的利用方法如图所示：

漏洞示例：

#CVE-2020-0188 AOSP Settings SliceProvider

影响版本Android10 补丁 2020-6月补丁

在MainActivity 中首先拿到指定content://android.settings.slices 的slice ，进而从中提取到pendingIntent 。进而设置Intent的pkg和data以及flags ，最后发送。在这个过程中，pendingIntent的action 因为是隐式指定的（即不为空），所以无法重新设置。

然后注册MyActivity 指定android.settings.SETTINGS 的action 即可

实现MyActivity 读取即可

成功读取

修复

#CVE-2020-0389 AOSP SystemUI RecordingService

影响版本Android 10 补丁 2020-9月补丁

修复

#A-166126300 MediaBrowserService

#Some High Profile Apps AppWidgets

#CVE-2020-0294 System Service

5. 危害

上述多个案例均可造成通讯录这类个人敏感信息泄露，但实际上，由于PendingIntent重定向攻击还具有写数据的能力，因此可能造成更大的危害。

例如，很多App都具有热更新功能，一般将dex/jar/apk/so等文件放在自己的私有目录中，如果这些私有目录可以被 grantUriPermission=true 的ContentProvider所引用，就可以利用PendingIntent重定向攻击去改写热更新文件，将攻击者自己的代码注入到其中，实现以受害App的权限执行任意代码。

对于CVE-2020-0188和CVE-2020-0294这类源于系统uid的PendingIntent，由于在UriGrantsManagerService当中进行了限制，因此在原生系统中的危害很有限，只能读取特定的几个Content Provider。

但是由于Android系统的定制化，上述限制可能在OEM厂商中被打破，造成更大的危害（这部分内容可以在我之前的博客中找到，OEM厂商在进行二次开发时加入了很多放行条件，位漏洞的进一步利用打开了缺口）。

Google对安卓系统中这类漏洞的修复，起初是将base Intent设置为显式Intent，指定明确的组件。后来均使用FLAG_IMMUTABLE修复，当使用这个flag时，PendingIntent的base Intent将无法通过Intent.fillIn 函数改写。

6. 安全指导

0x02 自动化分析

作者等人编写了一个自动化扫描工PendingIntentScan，该工具基于Soot这一Java静态分析框架对apk进行数据流静态分析，其体系结构如图所示。

首先，使用Soot将apk的字节码转换为Jimple形式的IR，然后搜寻一系列生成PendingIntent的API，并挑选出没有使用FLAG_IMMUTABLE的：

然后，通过Soot提供的ForwardFlowAnalysis对PendingIntent的Intent参数进行检查，查看是否调用下列函数。如果都没有使用，则认为PendingIntent是不安全的：

这个工具目前开源在https://github.com/h0rd7/PendingIntentScan，可以迅速发现apk中存在的不安全PendingIntent