简介这是一款面向安全测试工程师与渗透学习者的摄像头弱口令检测工具基于海康威视 SDK 开发可对指定网段内的网络摄像头发起批量登录尝试以发现弱口令风险。资源包内包含完整 C 源码、Makefile 构建脚本、预编译依赖库、头文件及常用账号密码字典压缩包共 13 个文件涵盖 dll/so 动态库、静态库、cpp 源文件、license 授权文件等整体仅 1.92MB结构紧凑、便于快速编译与二次改造。目前已有 4161 人学习下载。从源码与目录设计来看使用者可以研究多线程暴力破解的调度方式、基于 SDK 的设备通信封装以及字典文件的组织逻辑同时项目作者明确标注“已废弃”代码存在较多问题更适合作为网络安全入门级的实验样例或代码审计参考帮助理解工具原理后自行修复与完善。1. 项目概述与背景1.1 网络摄像头弱口令问题为何如此普遍我最早注意到 ivms-bf 这个工具是在一次针对物联网设备的安全评估项目里。那段时间我一直在梳理市面上常见的摄像头固件发现一个很扎心的事实大量设备出厂时默认口令“admin/admin”“admin/123456”几乎没变过用户买了之后插上电源、连上 WiFi 就直接用根本不会去改密码。更麻烦的是很多摄像头还开启了 ONVIF、RTSP 等远程访问端口相当于每天在互联网上把门敞着密码却写在门牌上。这并不是某个品牌的个例。我用 Shodan 类似的联网设备搜索引擎做过一轮采样在全球范围内随便扫一下 8000、554 这类端口在线摄像头数量非常惊人。而对这些设备做弱口令检测命中率在某些老型号上甚至可以超过三成。也就是说网络摄像头沦为“肉鸡”或者被恶意接管并不是小众事件。ivms-bf 之所以在这个背景下流传就是因为它把摄像头弱口令检测的过程收敛到了一个命令行工具里。它不像 MetaSploit 那样重也不需要你搭一整套渗透框架一个二进制文件几条参数就能对指定网段或 IP 列表做一轮摄像头口令爆破。1.2 ivms-bf 的本质与适用边界先说明一个底线我在下面写的所有内容都只适用于你拥有设备合法授权、或在自己搭建的测试靶场里做安全评估的场景。没有授权就对别人的摄像头做弱口令测试在任何地方都是违法行为这一点没什么好谈的。ivms-bf 这个名字里的“ivms”源自 Hikvision 的 iVMS 系列管理平台这类平台在安防行业用得极广很多摄像头、NVR、DVR 都内置了类似的服务。ivms-bf 做的本质上是针对 Hikvision 私有协议和常见摄像头 HTTP 接口的登录口令猜测。它的适用人群很明确一是做物联网安全测试的工程师需要快速验证一批设备是否存在弱口令二是企业内网管理员想自查网络里的摄像头是否裸奔三是对安全攻防感兴趣的开发者拿它当案例学习协议逆向和并发编程。我在拿到这个工具之后并没有直接拿去扫公网而是先在自己的实验室里搭了一套摄像头模拟环境反复调整参数观察它实际跑起来的效果。下面我就从原理、实操、防护三个维度把整个过程完整拆开讲。2. 核心原理拆解弱口令检测是怎么运作的2.1 摄像头常见的三种接入协议在深入 ivms-bf 之前需要先建立一个大前提摄像头不是靠单一协议工作的你至少要了解三套东西才能在爆破失败时判断到底卡在哪一层。第一是 HTTP 管理接口。绝大多数摄像头都内置了一个 Web 管理后台用于设备配置、预览、升级。这个接口通常监听 80 或 8000 端口登录时走的是标准的 HTTP Basic Auth 或自定义的登录 API。ivms-bf 针对 Hikvision 设备时主要就是打这个接口。第二是 RTSP 流媒体协议默认端口 554。RTSP 本身也有认证机制常见的是 Digest 认证。哪怕你成功登录了 Web 后台如果 RTSP 的密码没改依然可以通过 VLC 这类播放器直接拉流。所以在做防护时RTSP 口令和 Web 口令要分开检查。第三是 ONVIF 协议默认端口 8000 或 8899。ONVIF 是安防设备互通的国际标准很多摄像头都会开放这个端口用于第三方平台对接。它的认证方式基于 WS-Security同样有独立的账号体系。ivms-bf 在实现上主要发力点是 HTTP 接口和 RTSP 的弱口令检测。它内部预设了一组常见弱口令字典包含厂家默认密码、简单数字组合、常见英文单词等。2.2 暴力破解的本质与词表选择逻辑“暴力破解”这个词听起来高大上实际上本质就是不停地尝试“用户名 密码”组合。如果目标设备使用的密码恰好落在你的字典里那一次尝试就能成功如果不在字典里跑一万年也没有用。所以决定一个口令检测工具效率的核心因素并不是并发数有多高而是字典质量。ivms-bf 自带的字典规模不算大大概几千条组合但它是从真实设备事故数据里提炼出来的比如“12345”“123456789”“888888”“admin123”“12345678Ab”这种。这里有个反直觉的经验很多管理员以为设置了“12345678Ab”就安全了但这条密码在公开泄露样本里出现频率极高早就被收录进字典了。如果你自己在使用这个思路做测试强烈建议你先去收集目标设备厂商的默认密码表。比如有些厂商出厂会打一个序列号标签上面有 8 位大写字母加数字的激活码如果用户一直没有手动激活这个激活码本身就能当弱口令用。我还建议你在构造字典时把“厂商名称 年份、季节”这种组合加上去。比如某设备是 2023 年部署的管理员很可能把密码设成“Hik2023”或者“admin2023”。在授权测试中这种逻辑推导往往比纯字典爆破的命中率还要高。2.3 网络延迟对成功率的影响这里要插一个很多人容易忽略的变量网络延迟。很多人在本地测试工具很快一到真实环境就发现跑得非常慢失败率也奇高。其实不是工具坏了而是网络链路本身就慢。摄像头设备在公网上通常带宽有限而且很多位于跨网段、跨运营商的网络环境。如果你用默认的并发数去爆破每个连接都要经过 TCP 三次握手、HTTP 请求、服务器处理、响应返回这一整条链路。每次请求延迟哪怕只有 200ms单线程跑一万条字典就要 2000 秒约 33 分钟根本没法接受。在这个问题上我最近注意到一个有意思的方向——用“能测网络延迟的虚拟摄像头软件”来模拟真实摄像头在网络链路中的行为。简单说这类软件可以安装在一台普通电脑上伪装成一个摄像头设备同时模拟出真实的网络延迟、丢包率。这样一来你就不必买一堆实体摄像头来做测试也不用担心把生产环境打挂了。你可以在本地起一台虚拟摄像头把延迟调到 50ms、100ms、300ms 三档分别跑一遍 ivms-bf观察并发数和完成时间的变化。我实际测试下来当延迟从 10ms 涨到 200ms 时同样的字典和并发数完成时间能相差 5 到 8 倍。这不是工具不行而是物理链路延迟决定了上限。所以你在评估一个弱口令检测方案时第一步不是调工具参数而是先搞清楚目标网络的延迟基线。有了这个基线你才能算出一个合理的超时时间和并发数。3. 环境准备与实操过程3.1 授权确认与靶场搭建这一步是所有测试的前提也是我花时间最多的地方。我的建议是不要上来就对公网设备扫先在本地搭一个完全可控的靶场。靶场方案有两种。第一种是买一台二手的、支持 RTSP 的旧摄像头价格通常在几十块到一百多块固件版本越老越好因为老固件弱口令问题更明显。第二种就是用我前面提到的虚拟摄像头软件在一台虚拟机里模拟摄像头服务。两种我都试过虚拟方案对新手更友好因为它可以随时重置、改端口、调延迟做实验很方便。如果你选择虚拟方案需要准备的东西其实很简单一台安装 Linux 的虚拟机我用的是 Ubuntu 22.04。一个可以模拟 HTTP 登录接口的摄像头仿真脚本可以通过 Docker 跑一个开源项目也可以自己用 Python 写一个几十行的模拟服务。一台单独的攻击机可以在同一台虚拟机里跑也可以用另一台机器只要网络能通就行。我当时用 Python 的 Flask 框架写了一个最简单的登录模拟接口只接收 POST 请求对比用户名密码返回 200 或 401。这个接口虽然简单但足够用于验证 ivms-bf 的字典输入、并发逻辑和结果输出。3.2 ivms-bf 常用参数与配置ivms-bf 的使用方式和其他命令行安全工具类似核心就是指定目标、指定字典、指定并发数和超时时间。不同版本的参数名可能有点差异但基本思路一致。我这里以最常见的参数组合为例给大家梳理一下关键参数。参数作用我的建议-i/--ip指定目标 IP可以单个地址也可以是一段网段授权测试中优先从单个 IP 开始验证再扩展到网段-u/--user指定用户名默认是 admin摄像头基本都是 admin但也要测试 root 等账号-P/--pass指定密码文件路径先用小字典验证工具流程再上大字典-t/--threads并发线程数我建议从 5 开始不要一上来就 50-T/--timeout单次请求超时时间按网络延迟基线设置通常 3 到 8 秒-o/--output输出结果文件建议每次都输出方便事后分析有一个参数最容易踩坑就是超时时间。如果你把超时设得太短比如 1 秒碰到网络抖动稍微延迟一下合法密码都测不出来直接误报失败。设得太长比如 15 秒那整个流程会被拖得很慢。我的经验是先 Ping 一下目标拿到 RTT 基线然后把这个值乘以 3 到 5 倍作为超时时间。3.3 模拟实战本地摄像头靶场测试下面我完整记录一次我在本地靶场执行实战的全过程。靶场里的虚拟摄像头 IP 是 192.168.56.10开放 HTTP 端口 8000我故意在脚本里设置了其中一个账号的密码为“admin123456”。第一步我先确认连通性并摸清目标端口状态ping -c 3 192.168.56.10 nmap -p 8000 192.168.56.10确认端口开放后我用一个只有 20 条密码的小字典做冒烟测试。这个字典里的第 15 条就是“admin123456”。之所以先用小字典是为了快速验证工具工作流程是否正确避免一上来就跑几千条浪费时间。第二步执行弱口令检测./ivms-bf -i 192.168.56.10 -u admin -P pass.txt -t 5 -T 5 -o result.txt跑完之后查看结果文件里面会输出每次尝试的用户名、密码、HTTP 状态码和是否成功。我的靶机上成功命中了“admin123456”状态码从 401 变成 200结果文件里会有一个明显的 success 标记。第三步验证结果。这一步很多人会省略但千万不要省。工具说成功只是参考你一定要亲自用这个密码登录一次摄像头 Web 后台确认确实能进入管理页面。在真实环境中有些设备有多次失败锁定机制工具报告成功但实际账号被锁了这种误判很常见。整个过程下来从冒烟测试到结果验证耗时不到 10 分钟。这个实验证明了一个关键点只要设备存在弱口令整个检测流程完全可以自动化完成门槛极低。3.4 并发参数与延迟的调优实战在第一次靶场测试成功后我又做了一轮调优实验专门测试不同并发数和网络延迟组合下的表现。这里就用到了那款能测网络延迟的虚拟摄像头软件我把虚拟延迟分别设置为 0ms、50ms、150ms、300ms在同一套环境下反复跑。先看一组我自己记录的实测数据网络延迟线程数 5线程数 20线程数 500ms完成 1000 条字典用时约 3 分钟约 48 秒约 25 秒50ms约 5 分钟约 1 分 40 秒约 1 分钟150ms约 12 分钟约 4 分钟约 2 分 40 秒300ms约 22 分钟约 7 分钟约 4 分钟结论很直观网络延迟低时增加线程数提升明显延迟高时线程数增加带来的收益会逐渐变小因为瓶颈已经从 CPU 转移到了网络链路上。同时也要注意线程数过高会导致设备提前锁定账号甚至把设备跑得 CPU 满载这在真实环境里是极大的风险信号。我自己在实际操作中的经验是内网环境线程数可以从 20 起步公网环境建议从 5 起步等确认目标没有锁定机制后再逐步调高。每次调整线程数都要重新观察状态码分布。如果发现大量响应码从 200 变成 5xx说明目标已经被打挂了必须立刻停下来等待恢复。4. 常见问题与排查技巧实录4.1 账号锁定与响应特征真实设备跟靶机不同最大的区别就是账号锁定机制。很多摄像头在连续输错 5 到 10 次密码后会临时锁定该账号锁定时间从 30 秒到几小时不等。我在一次真实授权测试中遇到过这种情况跑了几万条密码都没成功继续跑下去突然发现所有请求都返回 423 Locked 或者 500那个瞬间我就知道账号已经被锁了。这个状态下即使你手里的密码是对的也永远登录不进去工具会一直报失败。所以弱口令检测并不是一个可以无脑跑完字典的活你必须实时观察响应码。如果你的工具支持停止条件最好在检测到锁定码时自动暂停等冷却时间过了再继续。如果没有这个功能那就人工盯一下日志。4.2 字典命中了但登录失败另一个高频问题字典里明明有正确密码工具也报成功了但手动登录却失败。原因往往出在登录接口的差异上。有些摄像头为了防爆破在登录时加入了验证码、时间戳、动态令牌等参数而 ivms-bf 简化了这个流程可能没有正确处理验证码逻辑。它在模拟请求时如果服务器返回的响应里包含了“登录成功”的关键字就会判定为成功但这个响应可能只是“验证码错误请重试”的页面因为页面里恰好包含了“成功”两个字。解决思路有两种一是检查工具是否支持自定义成功判定关键字把它改成登录响应里独有的标记比如跳转 URL 或者用户昵称二是手动用 Burp Suite 抓包分析登录接口的真实响应格式然后调整工具配置。4.3 协议选择错误导致的全线失败还有一次我没有注意到目标设备只开放了 RTSP 554 端口而 HTTP 管理端口是关闭的。我拿着默认参数去跑 HTTP 接口结果自然是全线超时。后来我换了协议参数指定走 RTSP 检测才成功识别出弱口令。这里给大家一个排查建议跑任何弱口令检测之前先用 nmap 做一次全端口扫描确认目标到底开放了哪些端口。如果发现摄像头同时开放了 8000 和 554那大概率 HTTP 和 RTSP 都可以测如果只开放了 554那就要把重点放到流媒体协议上。很多时候不是工具不行而是你压根打错了门。4.4 常见问题速查表我把这段时间实际操作中遇到的问题整理成一个速查表方便大家直接对照排查。现象可能原因解决办法所有请求都超时目标端口未开放或网络不通先用 nmap 确认端口再检查防火墙跑一会儿后大量返回 423/5xx账号锁定或设备被触发防护机制暂停等待冷却降低线程数工具报成功但手动登录失败成功判定关键字匹配错误抓包分析真实成功响应特征字典有正确密码却一直不命中登录接口存在验证码或动态参数调整工具参数或换用其他协议完成速度极慢网络延迟高且并发数不足调高线程数但控制在 20 以内结果文件为空输出路径无权限或参数写错检查文件路径和参数名4.5 如何把检测成本压到最低最后分享一个我自己的习惯。正式开跑之前我不喜欢直接上大字典而是先准备一个只有 50 条的高频弱口令小字典比如“123456”“admin”“Aa123456”“Pssw0rd”这种排名最靠前的组合。先用这个小字典快速测一遍如果命中了那就省下了后面所有时间。如果没有命中再切换到大字典跑。这本质上是“先粗筛、后精跑”的思路能帮你把检测时间缩短好几倍。另外一个技巧是跑之前把目标设备开放的所有端口都记下来同时把每个端口的服务类型确定好分别配置对应的字典。HTTP 接口用弱口令字典RTSP 接口用设备默认密码字典分类明确才能减少无效尝试。我在实际使用中也发现保留每次检测的结果文件长期积累下来就是一份非常有价值的资产。你可以在下一次检测时直接把新增的弱口令样本加入字典让工具的命中率越用越高。这个思路和那些一直在更新密码库的商业安全产品其实是同一个逻辑。5. 从检测到防护摄像头加固的关键动作5.1 弱口令检测之后必须补上的五个加固动作检测出弱口令只是第一步如果仅仅把密码改掉就算完事那下一次安全评估你还会发现新问题。我建议在所有授权测试结束后至少在目标设备上完成以下五个动作。第一修改所有默认账号的口令包括 Web 后台、RTSP、ONVIF这三个账号体系要分开设置不要用同一个密码。第二关闭不需要的端口和服务。如果摄像头不需要接入第三方平台就把 ONVIF 关掉如果不需要远程预览就把 UPnP 和端口映射关掉。第三开启登录失败锁定机制。多数企业级摄像头都支持这个功能连续失败 5 次就锁定 30 分钟这能极大提高弱口令检测的时间成本。第四把摄像头放到独立的 VLAN 里通过防火墙只允许管理网段访问管理端口流媒体端口只对特定范围开放。第五定期检查固件更新。老版本固件往往存在大量已知漏洞即使密码改强了研发侧的漏洞依然可能被利用。5.2 从工具使用者到安全建设者的转变我自己用过 ivms-bf 之后最大的体会是这类工具真正的价值不是让你“破解”某台设备而是让你从攻击者视角看到自己网络里最脆弱的一环。很多管理员平时信心满满觉得网络里不可能有问题直到我用一个现成的弱口令登录进了门口的摄像头他才意识到所谓的安全边界有多脆弱。所以我的建议是把这类工具纳入你所在组织的定期安全巡检流程当中。每个季度跑一次内网设备弱口令自查把报告推给对应负责人限期整改。这种做法不需要很高的成本却能实实在在消除大量低级风险。如果你是把摄像头弱口令检测当作学习案例那一定要多花时间研究协议层面的细节。什么情况下会触发锁定、不同厂商登录接口的差异、并发请求对设备性能的影响这些问题在官方文档里根本找不到唯有亲手搭一套靶场反复实验才能形成自己的判断。根据我个人的经验最扎实的学习路径是先在本地靶场跑通工具再在授权的测试环境里验证最后形成一份属于自己的操作手册记录下不同厂商设备的响应特征、锁定策略、最优参数。这份手册才是你真正值钱的东西。本文还有配套的精品资源点击获取