前言

本文源于对山东大学网络空间安全学院李蕊博士的 IEEE 论文：Android 自定义权限揭秘：从权限提升到设计缺陷 的分析，旨在学习 Android 自定义权限机制的安全风险和攻击模式。

由 InForSec 主办的“移动互联网安全”论坛上，作者对该研究进行了分享，InForSec 已上传会议视频至 Bilibili ：山东大学李蕊博士：Android自定义权限机制安全性分析。

【InForSec 的会议纪要】 李蕊博士介绍了安卓中的两种权限：一种是系统权限，由系统 app 声明，保护系统资源；另一种是自定义权限，由第三方 app 声明，保护 app 资源。
以往工作对自定义权限的研究十分欠缺，李博士根据发现的自定义权限的威胁模型，将研究目标总结为：分析安卓系统中自定义权限机制的设计与实现，自动化检测其安全漏洞和设计缺陷。

李博士团队设计了自动化黑盒模糊测试工具 CuPerFuzzer ，对爬取的 17 万多个 APK 进行 Fuzz 并发现了多个 Android 系统高危的 CVE 漏洞，会议中重点分享了 CVE-2020-0148 和 CVE-2021-0317 漏洞原理与攻击效果演示。

自定义权限早期漏洞

正式开始介绍 Android 自定义权限的漏洞之前，先来简单下 Android 的权限机制。北京理工大学：Android自定义权限及其设计缺陷-陆永鑫.pdf 这篇文章里作者详细分析（感谢分享）了李蕊博士的研究论文的前世今生，本文很多材料借鉴该文，特此说明。

1.1 Android权限机制

关于 Android 的权限机制，百度搜一下一堆文章……此处不想赘述，直接引用上面提到的北理工公开材料。

1.2 自定义权限升级漏洞

陆永鑫硕士总结了 Android 自定义权限的历史安全研究：

Tuncay 的论文获取：Resolving the Predicament of Android Custom Permissions，此处附上一篇论文解读：CustomPermission。

下面介绍下他提到的第一类漏洞—— Android 自定义权限升级（custom permission upgrade）。该漏洞使得攻击者可在未经过用户交互的情况下，直接获取 dangerous 级别的系统权限。

下图总结了该漏洞的攻击场景：


攻击步骤

1. 首先攻击者创建一个 app，声明一个自定义权限，级别为 normal 或 signature，并且将自定义权限设置为系统权限组的一部分（如存储，或照相机）；
2. 攻击者更新此自定义权限的定义，将保护级别更改为 dangerous，并继续在相应的应用市场上推送其应用的更新，此时攻击者 app 将自动获取授权，同时自动获取同组其他危险权限，而不会告知用户。

漏洞原理

1. Android 处理自定义权限的方式与系统权限相同，对于 normal 和 signature 级别的权限在安装时授予，而对于传统应用程序（SDK<23），dangerous 权限也在安装时授予，但对于新应用程序（SDK>23），则在运行时被授予;
2. 当 System 系统权限从安装时授予变成运行时授予，意味着 这个 app 升级到了 SDK 23 以上，当 Custom 自定义权限升级，暗示着这个 app 有可能升级了，也有可能权限级别从 normal、signature 变成了dangerous ，但是系统并不具备区分这两种情况的能力；
3. 当恶意应用 app-test 更新修改了自定义权限声明，使保护级别从正常或签名变为危险时，系统错误地将这种情况视为系统应用程序的升级，并尝试升级现有的权限到运行时权限，则攻击者可在未经过用户交互的情况下，直接获取 dangerous 级别的系统权限。

官方补丁

系统可以以检查其源包是否是系统应用程序的方式判断一个权限是否是系统权限。若是自定义权限，则当权限保护级别从正常或签名变为危险时，系统将保持原有的保护级别。

1.3 confused deputy attack

Tuncay 发现的第二类漏洞：confused deputy attack（混淆代理攻击）。

该漏洞可以使操作系统向攻击应用授予被攻击应用的签名级自定义权限（俩应用为不同证书签名），以此获取对被攻击应用组件的未经授权的访问。Google 承认这是高危漏洞，因为它绕过了隔离应用程序数据与其他应用程序的操作系统保护。

下图总结了该漏洞的攻击场景：

攻击步骤

1. 攻击者创建两个 app，definer app A 自定义一个名称为 N 的权限，但将保护级别设置为 dangerous，attack app 仅在清单中请求该权限 N；
2. Definer app 需要先由用户安装，然后安装 attack app，在运行时将 definer app 的欺骗权限授予 attack app 后，definer app 可由用户卸载或由应用程序开发人员更新，以便事后安装被攻击应用；
3. 安装被攻击 app 后，attack app 能够向受害者发起攻击，以便自由访问被攻击 app 的受到签名保护的组件，即使它未使用与被攻击 app 相同的应用程序证书进行签名。

漏洞原理

1. 在更新或卸载 app 时，系统并不立即更新原有的自定义权限，而是在重新声明具有相同名称的新权限时撤销；
2. 由于 Android 在权限执行期间仅使用权限名称，因此无法区分具有相同声明名称的两个不同权限。因此，持有“暂时休眠”危险权限的应用程序会以未授权的方式访问受同名 signature 权限保护的组件。

官方补丁

授予签名权限之前加入检查过程，这一检查确保请求签名权限的应用程序与定义此权限的应用程序由相同的证书签名。

自定义权限近期漏洞

山东大学李蕊博士及其团队认为 Tuncay 发现的 Android 系统自定义权限漏洞即为可能属于冰山一角，需要一个自动分析工具来对 Android 系统的自定义权限机制进一步进行深入探测。最终目标应该是识别存在于权限框架中的设计缺陷，而不仅仅是已成功发现的个别攻击案例。

2.1 黑盒Fuzz工具原理

受 Tuncay 所发现的动机案例的启发，李蕊等人将分析过程抽象为特定 APP、特定操作的执行顺序（序列），目的是寻找能触发权限升级漏洞的序列，而权限机制的内部操作可以被视作一个黑盒，设计了自动化黑盒模糊测试工具 CuPerFuzzer 。

解释下测试用例构建

应用安装，应用卸载，应用升级，系统升级，这四种操作都可能触发系统更新赋权状态：

• 安装应用可能会导致加入新的自定义权限；
• 卸载应用可能会导致已有的自定义权限被删除；
• 升级应用可能使自定义权限更新或删除；
• 系统升级中可能会加入或删除已有系统的权限；

应用升级操作的基本原理是多次安装不同版本。使用 adb 和 fastboot 控制和系统升级，使用控制多台测试实现设备并行测试。

CuPerFuzzer最终的实验成果

李蕊团队使用 4 部 Pixel 2 手机，40195 个测试案例，耗时 319.3 小时(约13.3天)，平均一个测试用例执行了 114.4s。

最终，CuPerFuzzer 发现了 2,384 个测试用例触发了特权提升，包括 30 条关键路径。

最终将发现的漏洞概括为以下几类：

下面会介绍下已分配 CVE 编号的前四个漏洞的漏洞信息与原理。

2.2 悬空的自定义权限

该漏洞编号为 CVE-2021-0307，漏洞原理：

1. 当一个 APP 卸载或更新， PackageManager（PMS）会刷新所有权限的注册和授予状态；
2. 如果一个危险级别的自定义权限定义被删除，系统也会从APP中撤销它的授权；
3. 但是，如果被移除的自定义权限是安装时权限（普通/ 签名），则会保留相应的应用权限授予状态，导致权限悬空。

导致权限悬空的流程图如下所示：

漏洞攻击步骤：

步骤简单解析：

1. app-ds1-d 应用声明 com.test.cp 为普通权限并列入 PHONE 权限组，另外应用 app-ds1-r 请求这个权限；
2. 之后 app-ds1-d 应用将自己的权限升级由于为危险等级，安装应用后 PMS 进行了重新授权，由于 CALL_PHONE 和 com.test.cp 都是 PHONE 组，app-ds1-r 就可以在用户不能在电话的情况下获得 CALL_PHONE 权限。

漏洞修复

当系统删除自定义权限时，它对所有 APP 的授权应该被撤销。

2.3 不一致的权限组映射

该漏洞的漏洞编号为 CVE-2020-0418，该漏洞可以导致应用未经用户授权的情况下，获得所有系统危险权限。

漏洞成因

Android 所有 dangerous 权限都是基于组进行管理，如果应用已经获得了某一组里的某个权限，当它请求该组里的其它权限时会被自动授权。然而，李瑞团队发现系统权限和自定义权限的权限组信息是根据不同的机制来获取的，这导致 dangerous 系统权限的《权限-权限组》映射关系存在不一致。

1. 系统权限是依据 platfrom_permission 资源文件（比如位于 /system/etc/permissions 路径下的 platform.xml）来定义其《权限-权限组》 映射关系的；
2. 自定义权限则是由 PackageManagerService（即PMS服务）通过系统 app 里面的 AndroidMainfest.xml 文件来获取其 《权限-权限组》的映射关系；
3. 李蕊发现系统核心 app 所定义的 dangerous 权限都是都放在一个特殊的权限组中，命名为 android.permission- group.UNDEFINED。

利用该不一致和放入 UNDEFINED 组中的 dangerous 级别的自定义权限，应用能够未经许可得到所有 dangerous 级别的系统权限。

具体的攻击场景可用下图表示：

攻击步骤解析：

1. 给手机安装一个应用 test，赋予它一个系统 dangerous 级别的权限 WRITE_EXTERNAL_STORAGE（外部存储空间的写权限）；
2. 安装 test_update app 来对 test app 进行升级，升级包中定义了一个危险权限 com.test.cp 且权限组定义为 UNDEFINED，同时在 AndroidManifest.xml 文件中 <uses-permission> 写入所有系统危险权限；
3. 在 test app 中请求 com.test.cp 权限，结果竟是无弹窗给用户确认，然而却可以发现 test app 已经获得系统所有危险权限。

以上操作会将所有的系统危险权限也都映射到了 UNDEFINED 权限组中，而由于 test app 已经获得WRITE_EXTERNAL_STORAGE权限，那么其他系统危险权限自然也就都能获得。

官方补丁

官方补丁信息：CVE-2020-0418，删除了未定义权限组：android.permission-group.UNDEFINED。

2.4 自定义权限提升漏洞

该漏洞编号为：CVE-2021-0306，它可以使得恶意 app 可以在进行 Android 系统版本升级过程中无需用户同意，直接获得高版本操作系统新增的危险权限的能力。

漏洞成因

相比于 Tuncay 在 2018 年发现的自定义权限升级漏洞（本文1.2章节），李蕊发现 Android 官方虽然修复了在应用升级过程中权限定义不一致导致的权限提升问题，但是 Android OS 升级过程中也存在自定义权限定义不一致导致权限提升的漏洞！！

1. 在 Android 操作系统初始化期间，PMS 将被构建，用于 APP 安装卸载操作；
2. PMS 读取 packages.xml 和 runtime-permissions.xml 以获得存储的权限声明信息和授予状态；
3. PMS 扫描位于系统文件夹中的 APKs，然后将解析的权限添加到内部结构中；

需要注意的是，如果权限的当前所有者不是系统，则该权限将被覆盖。

漏洞利用

1. 在 Android 9 的手机上安装 app-ds3，它定义并申请了 Android 10 针对需要检测用户步数或对用户的身体活动（例如步行、骑车或坐车）进行分类的应用引入了 android.permission.ACTIVITY_RECOGNITION 运行时权限（Dangerous 级别），不同的是 app-ds3 将其定义为 normal 级别；
2. 将该手机升级至 Android 10，系统检查到当前 app-ds3 所拥有的 ACTIVITY_RECOGNITION 权限的所有者并不是系统，故自动将其覆盖，app-ds3 就此悄无声息地获得 Android 10 上的危险权限 ACTIVITY_RECOGNITION 的能力。

漏洞修复

在 Android OS 更新时，如果权限的当前所有者不是系统，对应权限的授权应该被撤销。

2.5 不一致的权限定义漏洞

该漏洞的编号为 CVE-2021-0317，该漏洞会导致恶意 app 在可以通过安装包升级修改自定义权限后（将 normal 提升为 dangerous 并加入 phone 权限组），当用户重启设备后即可在用户无感知的情况下获得 phone 权限组的能力。

漏洞原理

同样相比于 Tuncay 在 2018 年发现的自定义权限升级漏洞（本文1.2章节），李蕊发现 Android 官方虽然修复了在应用升级过程中权限定义不一致导致的权限提升问题，但是 Android OS 升级过程或设备重启过程中也存在自定义权限定义不一致导致权限提升的漏洞！！

同时不同于 2.4 章节所提到的漏洞的是，CVE-2021-0317 漏洞是用户完全自定义的新权限，而不是 Android OS 升级后高版本的操作系统会存在的权限。

• 一个 APP 安装操作也可以更新它自己定义的现有自定义权限，在此过程中，当保护级别从正常或签名变为危险时，系统将保持原有的保护级别，这样的设计是为了阻止 1.2 章节所提到的权限升级攻击；
• 但是这会导致出现以下情况：系统持有的权限定义与所有者 APP 提供的权限定义不同，即权限定义不一致；
• 如果系统中存在基于源包刷新权限授予状态的逻辑，如 OS 升级、设备重启等过程，就可能会出现权限升级问题。

攻击步骤

1. 在手机安装 test 应用，它定义并申请了一个 normal 级别的权限 com.test.cp（安装时会自动赋予该权限）；
2. 使用升级包升级 test 应用，将 com.test.cp 重新定义为一个危险级别的权限并列入 PHONE 权限组，同时在 AndroidManifest.xml 文件中 <uses-permission> 申请使用 com.test.cp 权限与 CALL_PHONE 权限（需要动态授权，安装后不会被自动授予）；
3. 此时 Android 会阻止 com.test.cp 权限的变更所带来的权限提升操作，将其保持原有的 normal 保护级别，但是 reboot 重启设备后却发现 test 应用已成功获得 PHONE 权限组的权限能力！！

漏洞修复

当权限定义更新，APP 对应权限的授权应该被撤销。

总结

针对发现的缺陷，李博士团队提出了3种通用的安全设计准则：

1. 准则1：权限定义的任何一个部分都应该始终存在；
2. 准则2：系统中权限的定义应与权限所有者的声明保持一致；
3. 准则3：如果权限的定义发生改变，则应该撤销已授予 app 中的该权限。

该论文和研究带来的个人启示：

1. Android 系统服务（如 PMS 服务）的缺陷漏洞也时有发生，对于漏洞挖掘者来说不要总觉得它“神圣不可侵犯”……
2. 对于庞大而复杂的研究对象，一个有效的黑盒 Fuzz 测试工具至关重要，需要学会从 Fuzz 出来的异常信息、有效反馈信息来提炼出有价值的漏洞；
3. 当你漏洞挖掘思路如同“北大荒”一样荒芜的时候，何不跟李蕊博士一样也去学习下他人的论文、他人的历史研究成果，从中提取出思路和方向，并琢磨如何玩出不同的花样……

本文参考文章与相关材料：

1. B站：山东大学李蕊博士：Android自定义权限机制安全性分析；
2. 议题涉及的完整漏洞Demo程序演示视频材料；
3. Android 自定义权限漏洞 Fuzz 测试工具 CuPerFuzzer ；
4. GOSSIP团队对该议题论文的简单翻译；
5. 北理工详细分析-Android自定义权限及其设计缺陷；
6. PDF论文下载地址：https://www.semanticscholar.org/paper；
7. 推荐一个安全大会论文pdf下载网站：https://typeset.io/papers。