本文源于对山东大学网络空间安全学院李蕊博士的 的分析，旨在学习 Android 自定义权限机制的安全风险和攻击模式。

由 InForSec 主办的“移动互联网安全”论坛上，作者对该研究进行了分享，InForSec 已上传会议视频至 Bilibili ：。

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

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

正式开始介绍 Android 自定义权限的漏洞之前，先来简单下 Android 的权限机制。 这篇文章里作者详细分析（感谢分享）了李蕊博士的研究论文的前世今生，本文很多材料借鉴该文，特此说明。

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

1.2 自定义权限升级漏洞

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

Tuncay 的论文获取：，此处附上一篇论文解读：。

下面介绍下他提到的第一类漏洞—— 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 级别的系统权限。

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

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

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

1. 安装被攻击 app 后，attack app 能够向受害者发起攻击，以便自由访问被攻击 app 的受到签名保护的组件，即使它未使用与被攻击 app 相同的应用程序证书进行签名。

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

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

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

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

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

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

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

最终，CuPerFuzzer 发现了 2,384 个测试用例触发了特权提升，包括 30 条关键路径。
最终将发现的漏洞概括为以下几类：
下面会介绍下已分配 CVE 编号的前四个漏洞的漏洞信息与原理。

2.2 悬空的自定义权限

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

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

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

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

2.3 不一致的权限组映射

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

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

利用该不一致和放入 UNDEFINED 组中的 dangerous 级别的自定义权限，应用能够未经许可得到所有 dangerous 级别的系统权限。
具体的攻击场景可用下图表示：

1. 在 test app 中请求 com.test.cp 权限，结果竟是无弹窗给用户确认，然而却可以发现 test app 已经获得系统所有危险权限。

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

2.4 自定义权限提升漏洞

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

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

1. 在 Android 操作系统初始化期间，PMS 将被构建，用于 APP 安装卸载操作；
2. PMS 扫描位于系统文件夹中的 APKs，然后将解析的权限添加到内部结构中；

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

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

2.5 不一致的权限定义漏洞

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

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

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

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

1. 在手机安装 test 应用，它定义并申请了一个 normal 级别的权限 com.test.cp（安装时会自动赋予该权限）；
2. 此时 Android 会阻止 com.test.cp 权限的变更所带来的权限提升操作，将其保持原有的 normal 保护级别，但是 reboot 重启设备后却发现 test 应用已成功获得 PHONE 权限组的权限能力！！

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

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

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

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

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

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