刚打完一场校内 CTF 比赛的深夜，当室友们都在打呼噜时，我正习惯性地在一个海外合规漏洞赏金项目（Bug Bounty）中漫无目的地寻宝。
这次的目标是一家颇具规模的云电台服务商（下文简称 ██████）。作为一个热爱捣鼓协议的“大学生安全研究员”，我对这类涉及实时流媒体的技术架构总是充满好奇。本以为这家大厂的安全防护会让我无功而返，但谁能想到，两段烂大街的默认密码，竟然帮我撬开了他们核心 API 的大门。
今天，我想和大家复盘一下这个漏洞挖掘全过程
0x01 故事背景
在做信息收集时，我锁定了他们系统中的一个关键资产：api.██████.com。这个 API 承载了平台下属无数个网络电台的实时数据交互。
顺着网线摸索，我发现了一个关键端点（Endpoint）：
https://api.██████.com/1/radios/stats/status
直觉告诉我，带有 stats（统计）和 status（状态）字眼的接口，往往包含敏感的业务数据。于是我迫不及待地用 Burp Suite 发送了一个无认证的 GET 请求，试图做个基线对比
GET /1/radios/stats/status HTTP/1.1
Host: api.██████.com响应不出所料：
HTTP/1.1 401 Unauthorized
www-authenticate: Basic realm="Access denied"
{"result":"error","error":{"code":"not_authorized","description":"Not authorized"}}
一个标准的 HTTP Basic Auth 防御墙。到这里，剧本似乎很平淡。但这套电台系统的底层架构引起了我的注意——通过报错特征和指纹识别，我判断其流媒体核心组件是经典的 Icecast。
既然是 Icecast……那它出厂自带的默认凭据，管理员删了吗？
0x02 漏洞利用
玩过流媒体架构的师傅们都知道，Icecast 有几组骨灰级的默认账密：source:password 和 admin:hackme。
正常来说，API 网关层应该有自己独立的认证体系（比如用户名=电台名，密码=面板生成的随机密码）。但我脑子里突然冒出一个假设：如果前台 API 和底层 Icecast 服务的鉴权逻辑耦合了呢？如果 API 并没有过滤底层的默认凭据呢？
说干就干，我迅速构造了第一个 Payload，使用 source:password 的 Base64 编码：
GET /1/radios/stats/status HTTP/1.1
Host: api.██████.com
Authorization: Basic c291cmNlOnBhc3N3b3Jk点击 Send，奇迹发生了。响应状态码从 401 Unauthorized 变成了：
HTTP/1.1 404 Not Found
{"result":"error","error":{"code":"object_not_found","description":"Object not found","context":{"model":"Station"}}}
看到这个 404，我差点在寝室喊出声！
为什么 404 值得激动？因为在 API 逻辑中，401 代表“你是谁？”，而 404 代表“我认识你，但你要找的资源不存在”。这意味着，系统接受了我的默认凭据，认证机制已经被成功绕过！服务器已经放行了我的请求，开始去数据库里查找电台资源了。
为了让证据更确凿（排除误报），我又做了两组对照实验：
- 测试管理默认凭据 (admin:hackme): 返回 404 Not Found。（同样绕过！）
2.测试无效凭据 (test:test): 返回 422 Unprocessable Entity，提示用户名/密码无效。
GET /1/radios/stats/status HTTP/1.1
Host: api.infomaniak.com
Authorization: Basic dGVzdDp0ZXN0
（Base64解码: test:test）
无效凭据被明确拒绝，证明认证系统确实在验证凭据
获取真实数据（数据泄露）
有了权限，我立刻找了一个公开的测试电台挂载点进行实测。
访问 /listeners 端点：
GET /1/radios/stats/listeners HTTP/1.1
Host: api.██████.com
Authorization: Basic [脱敏后的合法Base64]
篡改元数据（完整性破坏）
本以为到此为止只是个敏感信息泄露，然而接下来的发现推翻了我的假设。在翻阅文档时，我发现了一个 /metadata 的写操作接口。既然读权限被绕过了，写权限呢？
我尝试发送了一段恶意的元数据：
GET /1/radios/stats/metadata?data=HACKED+-+Vulnerability+Proof+of+Concept HTTP/1.1
Host: api.██████.com
Authorization: Basic [脱敏后的合法Base64]服务器响应：
{"result":"success","data":true}
API 返回了 True！ 此时此刻，所有正在收听该电台的听众，他们播放器上显示的“正在播放的歌曲名”，瞬间变成了我设置的 HACKED – Vulnerability Proof of Concept。
(注：作为白帽子，验证成功后我已在1秒内将元数据恢复原状。)
0x03 漏洞影响
如果在报告里只写一句“存在越权漏洞”，那就太没有灵魂了。让我们把这个漏洞放在真实的商业场景中来看：
- 商业情报裸奔 (Data Leakage)：
攻击者可以实时监控任意电台的听众数量。对于大型商业电台来说，听众基数直接与广告定价挂钩，属于高度机密的商业情报。竞争对手只需写个脚本，就能把全网电台的底裤看穿。 - 大规模名誉破坏 (Data Integrity)：
多达 12 个核心 API 端点受到影响（包括 updatemetadata.php）。这意味着攻击者可以随时篡改数千个电台正在播放的“歌曲信息”，这对于品牌的公信力是毁灭性的打击。
0x04 防御与反思
从攻击者回归建设者，这个漏洞的 Root Cause（根本原因）非常典型：过度信任底层组件的默认配置，且在接口层缺乏独立的纵深防御。
API 网关直接透传了 HTTP Basic Auth 给底层的 Icecast，而没有在网关层对凭据进行严格的白名单鉴别。
针对这类问题，我给出了以下加固建议：
- 强制轮换默认凭据：这是最基础的操作！立刻删除 Icecast 中的 source 和 admin 默认密码。每个电台实例在初始化时，必须强制生成高强度的随机密码。
- 解耦认证体系（增加接口层独立认证）：前端 API 不应该依赖底层的组件密码来进行身份验证。在 updatemetadata.php 等敏感接口前，应该增加额外的 API Key 或 Bearer Token 校验。
- 收敛攻击面（访问控制）：对于 /radio/* 这类仅供内部通信或指定客户端使用的接口，直接在 Nginx/反代层实施 IP 白名单限制，从网络层阻断恶意探测。
结尾碎碎念：
网络安全往往就是这样，最致命的破绽，往往藏在那些“大家都觉得理所应当”的默认配置里。作为一名还在念书的白帽子，这次实战让我深刻体会到了“验证每一个假设”的重要性。不要放过任何一个看似普通的 401 报错，因为墙的后面，可能就是一片广阔天地。
Stay Hungry, Stay Foolish. 我们下个漏洞见！