14、Android BLE权限漏洞：BLUETOOTH权限滥用、BLUETOOTH_ADMIN权限风险、运行时权限绕过、后台扫描权限
BLE权限这块，说实话是Android安全里最容易翻车的地方之一。我这些年做蓝牙安全审计，见过太多App因为权限配置不当，直接把用户数据拱手送人的案例。今天咱们就把这几个核心漏洞点掰开揉碎了讲清楚。
14.1 BLUETOOTH权限滥用：你以为只是“普通权限”？
很多开发者觉得BLUETOOTH权限就是个普通权限，系统自动授予，没啥风险。嗯，这里要注意——这个想法本身就是最大的风险。
BLUETOOTH权限允许App执行基本的蓝牙操作，比如扫描设备、连接设备、传输数据。但问题在于，它没有限制App能访问哪些设备、能传输多少数据。说白了，只要用户给了这个权限，App就能跟周围所有蓝牙设备“聊天”。
核心风险点：
- App可以在后台持续扫描附近蓝牙设备，收集设备MAC地址、设备名称、信号强度等信息
- 这些信息可以用来追踪用户位置、行为模式，甚至推断用户身份
- 恶意App可以通过蓝牙通道向附近设备发送恶意数据包
我曾经审计过一个健身App，它申请了BLUETOOTH权限，但实际功能只需要连接自家手环。结果呢？它在后台偷偷扫描周围所有蓝牙设备，把MAC地址和扫描时间上传到服务器。这本质上就是在做用户轨迹追踪。
我的建议：只在你真正需要蓝牙通信的时候才申请BLUETOOTH权限。如果只是检测蓝牙是否开启，用BluetoothAdapter.getDefaultAdapter()就够了，不需要权限。
14.2 BLUETOOTH_ADMIN权限风险：这把“钥匙”太万能了
BLUETOOTH_ADMIN权限比BLUETOOTH权限更危险。它允许App执行管理操作，比如开启/关闭蓝牙、执行设备发现、修改蓝牙设置等。你想想看，一个恶意App拿到这个权限后能做什么？
| 权限 | 允许的操作 | 风险等级 |
|---|---|---|
| BLUETOOTH | 连接、扫描、数据传输 | 中 |
| BLUETOOTH_ADMIN | 开启/关闭蓝牙、设备发现、修改设置 | 高 |
| BLUETOOTH_SCAN (Android 12+) | 仅扫描 | 低 |
| BLUETOOTH_CONNECT (Android 12+) | 仅连接 | 中 |
为什么说它危险？因为BLUETOOTH_ADMIN权限可以强制开启蓝牙。想象一下这个场景：用户明明关闭了蓝牙，但恶意App通过这个权限悄悄打开蓝牙，然后开始扫描周围设备、发起连接请求。用户完全不知情。
避坑指南：我曾经见过一个App，它申请了BLUETOOTH_ADMIN权限，理由是“优化蓝牙连接体验”。实际上它在后台每隔5分钟就强制开启蓝牙扫描一次，把周围设备信息全部上传。这种滥用行为在Google Play审核时很难被发现，因为权限声明写得很模糊。
从Android 12开始，Google终于意识到了这个问题，把蓝牙权限拆分成了BLUETOOTH_SCAN、BLUETOOTH_CONNECT、BLUETOOTH_ADVERTISE三个运行时权限。但问题是，很多App还在用旧版API，兼容性问题导致这个拆分效果大打折扣。
14.3 运行时权限绕过：那些“巧妙”的漏洞
Android 6.0引入了运行时权限模型，要求App在使用敏感权限时必须弹窗让用户确认。但BLE权限这块，有几个经典的绕过方式。
绕过方式一：权限降级攻击
有些App在AndroidManifest.xml里声明了BLUETOOTH_ADMIN权限，但在运行时只请求BLUETOOTH权限。用户以为只给了普通权限，实际上App在后台偷偷使用管理权限。为什么会这样？因为系统在安装时就已经授予了manifest里声明的所有普通权限，包括BLUETOOTH和BLUETOOTH_ADMIN（在Android 12之前）。
// 恶意代码示例：manifest声明了BLUETOOTH_ADMIN
// 但运行时只请求BLUETOOTH权限
// 用户以为只给了普通权限
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.S) {
// 在Android 12之前，BLUETOOTH_ADMIN是普通权限
// 安装时自动授予，不需要运行时请求
bluetoothAdapter.enable(); // 直接开启蓝牙，用户无感知
}绕过方式二：隐式权限继承
有些App通过绑定系统服务来间接获取蓝牙权限。比如，App申请了ACCESS_FINE_LOCATION权限，然后通过这个权限间接获取蓝牙扫描结果。因为蓝牙扫描在Android 10之前需要位置权限，但扫描结果里包含了设备信息。
关键点：从Android 10开始，蓝牙扫描必须同时拥有BLUETOOTH_SCAN和ACCESS_FINE_LOCATION或ACCESS_COARSE_LOCATION权限。但很多App只申请了位置权限，没有申请蓝牙权限，照样能扫描——这就是漏洞。
14.4 后台扫描权限：最容易被忽视的“数据漏斗”
后台扫描权限，说白了就是App在后台（用户看不到的时候）还能继续扫描蓝牙设备。这个权限在Android 10之后被严格限制，但依然存在绕过方式。
我记得有个案例：一款天气App申请了后台扫描权限，理由是“根据附近设备提供本地化天气服务”。实际上它在后台持续扫描，把扫描到的设备MAC地址、信号强度、时间戳全部上传。这些数据组合起来，就能绘制出用户的移动轨迹。
后台扫描的典型攻击场景：
- App在后台扫描到用户家里的智能灯泡（MAC地址固定）
- 通过信号强度变化判断用户在家还是外出
- 结合时间戳，推断用户的作息规律
- 这些数据被卖给第三方，用于精准广告投放甚至入室盗窃
我的建议：如果你的App不需要后台扫描，千万别申请BLUETOOTH_SCAN权限的usesPermissionFlags属性。从Android 12开始，你可以通过PendingIntent的方式实现前台扫描，完全不需要后台权限。
14.5 知识体系总览
下面这张图把BLE权限漏洞的核心逻辑串起来了。我建议你仔细看看，理解每个权限之间的关联和风险传递路径。
14.6 实战防护建议
说了这么多漏洞，咱们得聊聊怎么防。我总结了几条实战经验：
- 最小权限原则：只申请你真正需要的权限。如果只需要扫描，别申请
BLUETOOTH_ADMIN。从Android 12开始，尽量使用BLUETOOTH_SCAN、BLUETOOTH_CONNECT、BLUETOOTH_ADVERTISE这三个细分权限。 - 运行时权限检查：不要假设manifest里声明了权限就能用。每次使用蓝牙功能前，都要检查权限是否被撤销。用户随时可以在设置里关闭权限。
- 后台扫描限制：除非绝对必要，否则不要申请后台扫描权限。使用前台服务+通知的方式，让用户知道你的App正在使用蓝牙。
- 数据最小化：扫描到的设备信息，只保留你需要的字段。不要存储MAC地址，用随机生成的设备ID代替。
重要提醒：从Android 12（API 31）开始，蓝牙权限的申请方式发生了根本性变化。如果你的App还在用旧方式申请蓝牙权限，赶紧更新。否则在Android 12+设备上，你的App可能无法正常扫描或连接蓝牙设备。
嗯，BLE权限这块内容确实不少。但只要你理解了每个权限的边界和风险，写代码时多留个心眼，大部分漏洞都是可以避免的。我见过太多开发者因为图省事，直接申请最高权限，结果给用户带来了安全隐患。记住：权限越小，风险越小。
公众号:蓝海资料掘金营，微信deep3321