一台 360 摄像头，65535 个端口只开了 1 个，我却看见了它的实时画面

发表于 更新于 分类于

作者按：本文所有测试均在本人自有设备、自有局域网内完成，仅用于安全研究。文中内网地址、MAC、真实口令均已打码，请勿对他人设备做同类操作。

0. 起因：闲着也是闲着，扫一下家里的摄像头

家里局域网里蹲着一台 360 智能摄像机，平时只用 App 看画面。某天突然想：它到底在网上”露”了几个口子？

于是有了这次从零开始的黑盒评估。

有意思的是，我的扫描环境没装 nmap。没关系，Python 标准库（socket）就够写一套能用的扫描器——后面会讲怎么做。

1. 资产测绘：先搞清楚对面是谁

目标是一台接入 Wi-Fi 的摄像头，内网地址记为 192.168.x.19（已打码）。

三步走：

  • 连通性：ping 通，TTL=64，典型嵌入式 Linux 特征。
  • MAC 归属：查 OUI 库，厂商指向 成都全景智能科技——这正是 360 摄像头常见的代工厂。
  • 协议指纹：RTSP 的 WWW-Authenticate 头里直接写了 realm="360Camera"，身份坐实。

小技巧：光看 IP 没用，MAC 的 OUI 前三位 + 协议 banner 是最快的设备指纹组合。

2. 端口扫描：干净得有点反常

全端口 TCP 扫描（1–65535）结果：

项 结果
开放 TCP 端口 仅 554（RTSP）
服务标识 ireader/media-server
Web 管理界面 无
SSH / Telnet 无
ONVIF / UPnP / SSDP / mDNS 全部静默

65535 个端口只开了 1 个，没有远程管理后台，也没有命令行入口。再丢 8 类畸形输入进去（超长字段、非法方法、截断报文等），服务端全部正确处理，无崩溃。

客观说，这块比同价位一堆消费级摄像头要干净——很多廉价摄像头会顺手多开 80、23、8080 一堆口子。

攻击面小，是好事。但”唯一入口”往往意味着：它必须足够硬，否则一破全破。

3. 唯一的入口 RTSP：问题出在这里

554 端口跑的是 RTSP（实时流协议）。我做了三件事：

3.1 发现了一个”认证 oracle”

这是我这次最意外的发现。

按规范，RTSP 的摘要认证应该是”认证失败”和”认证成功但请求有误”不可区分的。但这台设备给出了截然不同的状态码：

  • 密码错误 → 稳定返回 401 Unauthorized
  • 密码正确 → 进入业务处理，返回 400 Bad Request

我用对照组验证过：admin / 错误密码 五次全 401，admin / 正确弱口令 十次全 400，复现率 100%。

这意味着什么？ 攻击者不需要真的拉流，发一个请求看返回码，就能判定密码对不对。没有锁定、没有限速、没有告警——一个常见弱口令字典，几小时就能穷举完。

3.2 出厂默认口令已失效，但用户口令很弱

测试发现 admin / admin 这种经典出厂组合已经不通了（厂商至少改过一版默认值）。但设备开启 RTSP 取流后设置的那个口令，落在常见字典 Top 100 里——属于典型的”人设的弱密码”。

这条要讲清楚：这锅不完全是厂商的。很多用户开 RTSP 时随手设个好记的密码，等于把门虚掩。

3.3 两个空实现，不算漏洞

未认证状态下 GET_PARAMETER / SET_PARAMETER 返回 200，但 Content-Length: 0，判定是 no-op 空实现，不构成可利用漏洞。如实记录，不夸大。

4. 决定性一击：真的把实时画面拉下来了

拿到正确流地址（云台一路 /live/101、枪机一路 /live/201）后，走完整 RTSP 握手：

1
2
3
DESCRIBE → 200 OK（拿到完整 SDP）
SETUP    → 200 OK
PLAY     → 200 OK

两路都成功取到了 16KB 实时 RTP 数据：

  • 视频编码：H.265
  • 音频编码：PCMA（G.711）
  • 会话已建立

翻译成人话：任何在同一局域网、知道那个弱口令的人，打开 VLC 输一行地址，就能实时看这两路画面。

1
2
vlc rtsp://admin:********@192.168.x.19:554/live/101
vlc rtsp://admin:********@192.168.x.19:554/live/201

（上面口令是打码占位，真实口令切勿外传。）

5. 风险定级

场景 等级 说明
仅局域网内 高 同网段任意设备可偷看实时画面
路由器做了 554 端口转发 / UPnP 映射公网 严重 全球任何人可访问

关键不确定性在路由器那一侧：我无法从内网确认它有没有被映射出去。这条决定了风险是”高”还是”严重”，得你自己去查。

顺带一提，组件 ireader/media-server 有 3 个已知的释放后使用（UAF）型 DoS 漏洞（CVE-2022-40016、CVE-2024-24262、CVE-2024-24260，均 CVSS 7.5）。版本号抓不到，我没做实际利用（那会打挂设备），但建议把固件升到最新。

6. 给你的防护清单（干货）

按优先级：

  1. 立刻改 RTSP 密码
    360 App → 该摄像头设置 → RTSP 取流，换成 16 位以上随机串。别用生日、电话、admin 系。

  2. 查路由器公网映射

    • 端口转发 / 虚拟服务器里有没有 554 指向这台摄像头
    • UPnP 是否开启 → 建议直接关掉并清空映射表

  3. 不用 RTSP 就关掉
    不接 NVR / NAS / Home Assistant 的话，直接关 RTSP 视频流开关。关掉后它在网络上几乎零端口，日常用 App 看完全不受影响。

  4. 升固件
    走 App 官方渠道升到最新，堵上组件层已知漏洞。

7. 结语

这次评估最有意思的地方在于反差：

攻击面极小、协议栈稳健，却被一个弱口令 + 一个认证状态泄漏打穿。

设备本身做得不差，真正的风险来自”唯一入口缺乏防爆破机制” + “用户随手设的弱密码”。安全不是某个端口开没开，而是最弱那根链条扛不扛得住。

把上面 4 条清单过一遍，这台摄像头就能从”高/严重”回到”安心”。

免责声明：本文所有操作均在作者自有设备与授权网络内完成，用于安全科普。未经授权对他人设备、网络进行扫描或访问属于违法行为，后果自负。文中已对一切可定位到具体设备的敏感信息做脱敏处理。

— 完 —