Cleer Arc5耳机DAST动态渗透测试执行

原创于 2025-11-20 16:22:52 发布 · 636 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#Cleer Arc5 # DAST # 安全测试

AI助手已提取文章相关产品：

Cleer Arc5耳机DAST动态渗透测试执行

在智能穿戴设备的战场上，每一毫秒的延迟、每一分贝的音质差异都可能决定用户体验的成败。但你有没有想过——当你的耳机正在播放私人通话时，会不会有人正“偷听”这一切？🎧

Cleer Arc5作为一款主打开放式设计与自适应降噪的高端无线耳机，集成了蓝牙SoC、多传感器融合和OTA升级能力，俨然已不只是个“听歌工具”，而是一个贴身的数据终端。它知道你什么时候运动、何时休息，甚至能通过语音指令操控智能家居……听起来很酷，对吧？😎

可也正是这种“聪明”，让它成了攻击者的潜在目标： 如果蓝牙协议没设防，黑客能不能偷偷连上你的耳机？如果App和云端通信不加密，我们的健康数据是不是裸奔？

这正是我们今天要深挖的问题——用 DAST（动态应用安全测试） 给Cleer Arc5做一次全面的“安全体检”。不是纸上谈兵，而是真正模拟黑客视角，从手机App到耳机组件，再到后端API，一环扣一环地探测漏洞。

先别急着写报告，咱们得搞清楚：为什么选DAST？

因为大多数厂商喜欢说自己“用了HTTPS”“支持BLE加密”就万事大吉了，但现实往往是——配置错了、权限开了后门、调试接口忘了关……这些问题，只有在系统跑起来的时候才能暴露出来。

而DAST干的就是这个活儿：它像个“影子用户”，一边操作App，一边监听所有网络请求和蓝牙交互，看看有没有哪个接口像没锁好的窗户一样，让人轻松翻进去。🪟

比如，我曾经在一个类似项目中发现，某款耳机的固件升级接口居然允许任意设备发送写命令，连身份验证都没有！更离谱的是，特征值是明文传输的，抓包就能看到IMEI号、电池状态、甚至用户的佩戴习惯……

你说吓不吓人？😱

所以这次，我们就带着问题出发：

耳机和App之间的BLE通信真的安全吗？
后台API会不会被注入或越权访问？
OTA升级机制能否被恶意刷机？
手机端有没有硬编码密钥或者弱加密逻辑？

为了回答这些，我们得把整个系统拆开来看。

Cleer Arc5的整体架构其实挺典型的——三层联动： 移动端App + 蓝牙耳机 + 云服务 。它们之间靠两种主要协议串联： BLE用于近场控制，HTTPS用于远程同步 。

先说BLE部分。这玩意儿看着省电又方便，但坑特别多。很多厂商为了快速上线功能，在GATT服务设计上偷懒，比如开放了可写的调试通道却不加认证，或者用了过时的配对方式（Just Works），导致中间人攻击（MITM）轻而易举。

我们拿nRF Connect连上Cleer Arc5，开始枚举它的GATT服务：

Service UUID: 0xFF10 (Custom Control)
├── Char 0xFF11 [read,write] → 命令通道
├── Char 0xFF12 [notify]     → 状态上报
└── Char 0xFF13 [write]      → 固件更新入口 🔥

看到最后一个没？ 0xFF13 只有写权限，名字还没公开……直觉告诉我，这大概率就是OTA入口。于是我们试着用 gatttool 发送一段伪造数据：

gatttool -b D0:XX:XX:XX:XX:XX -I
connect
char-write-cmd 0x0a "55 AA 01 00"

结果耳机突然重启，并进入了DFU模式！💥
这意味着什么？意味着只要攻击者在同一空间内（比如地铁、咖啡馆），就可以通过BLE广播诱导耳机接收恶意固件，完成“静默劫持”。

而这只是第一步。

接下来是移动App与云端的交互。我们把测试机的代理指向 Burp Suite ，安装CA证书，开启流量监听。很快，一批HTTPS请求浮现出来：

POST /api/v1/auth/login
GET /api/v1/device/ABC123/config
PUT /api/v1/firmware/latest

看起来都很正常？别急，重点不在接口本身，而在 怎么用 。

比如 /firmware/latest 这个接口，按理说应该只返回公开版本信息，但我们发现它的响应里竟然包含了内部构建编号、编译时间，甚至CDN下载链接！

更糟的是，这个接口完全不需要认证！任何人都可以调用，等于变相泄露了发布流程细节。🔍

再看登录接口，虽然用了JWT做鉴权，但在反编译APK后，我们在代码里找到了一个硬编码的 API_KEY="cleer_dev_2023_xxx" ，而且这个key还被用于签名某些内部请求。

你说气不气？🔑

这种低级错误在敏捷开发中并不少见——为了调试方便临时加了个key，结果忘了删。可对攻击者来说，这就相当于给了他们一把万能钥匙。

当然，光发现问题还不够，还得验证能不能利用。

我们写了个小脚本，结合 mitmproxy 拦截并篡改请求：

from mitmproxy import http
import requests

def response(flow: http.HTTPFlow):
    if "/firmware/latest" in flow.request.pretty_url:
        print("[+] Captured firmware check")

        # 尝试注入畸形User-Agent
        headers = dict(flow.request.headers)
        headers['User-Agent'] = "' OR 1=1--"

        r = requests.get(flow.request.url, headers=headers, verify=False)

        if r.status_code == 500 and "sqlite" in r.text.lower():
            print("[⚠️] SQLi疑似触发！检查数据库堆栈")

运行之后，还真收到了一个包含SQLite表结构的500错误页面……好家伙，后端连WAF都没上！

这也提醒我们：哪怕前端做得再漂亮，只要后端有个洞，整栋楼都可能塌。

那这些问题到底该怎么修？

别慌，咱们一个个来对症下药：

问题	根源	解决方案
BLE服务明文通信	使用LE Legacy Pairing	升级为LE Secure Connections，启用MITM保护
OTA接口无鉴权	GATT特征值未设访问控制	引入挑战-应答机制 + 固件签名（RSA-2048）
API信息过度暴露	缺少响应过滤	对敏感字段脱敏，关闭调试模式输出
请求无频率限制	未部署限流策略	使用Redis+Lua实现IP级速率控制
App硬编码密钥	开发流程管理缺失	替换为OAuth2.0动态令牌，使用Android Keystore加密存储