NcatBot系列软件重大安全事故回顾

网络安全绝非儿戏！！！

事件简述

参考资料

2025年9月5日晚，公网上大量未配置访问令牌（token）的 OneBot 服务被攻击者批量调用，诱导 QQ 机器人发布不当言论，导致众多 Bot 账号和群聊被平台封禁。由于 NapCat 框架默认把服务监听在 0.0.0.0 且用户多为新手，未设 token 的实例最多，因此成为“重灾区”。事件暴露出 OneBot 协议“token 可选”以及部分框架默认配置过于宽松的安全缺陷。也提醒开发者必须把安全性置于易用性之前，强制或显著提示用户完成最小化安全配置。

NcatBot（本俱乐部所属项目）本体相关代码审计

附带启动相关安全隐患

• 沿用了 NapCat 的 WebUI 弱 Token，没有做强制修改。此次攻击主要针对 OneBot 端口，没有针对 NapCat WebUI 的入侵，故 NcatBot 系列软件幸免遇难。
• 默认采用无 Token、强制监听本地的策略，但是仍然可以通过设置来监听 0.0.0.0。幸而能够正常查看文档获知 ws_listen_ip 的用户都具备一定网络安全意识，采用了强密码或者严格防火墙。强制监听本地策略是本次 NcatBot 用户群体免受攻击的主要原因。

文档相关安全隐患

• Linux 安装部分的文档中，直接不加风险说明的详细指导了用户开放防火墙端口，对于部分新手用户，存在极高的被攻击隐患。
• 远端模式的文档中没有说明潜在的安全隐患，文档编写经验不足。

预期改进

• 增强对启用远端模式的限制，对于有隐患的操作提高操作门槛。
• 本地模式严格检查 WebUI 和 Websockets 的安全状态。
• 文档设计充分考虑安全因素，避免有隐患的引导。

启发

网络安全不是儿戏，作为开源软件开发者，尤其是涉及到开放公网端口的软件开发，一定要认真审计代码中的潜在风险。不要把安全托付给用户的认知。

当易用性和安全性要做出 TradeOff 时，安全性是绝对不可牺牲的；法律风险比用户减少问题大得多。

多听从社区的安全建议，不要固执己见；没有不值得利用的漏洞，只有你没想到的作用。

网络安全就在身边，不要把 “小软件”、”个人配置” 的网络安全不当回事，明知有风险时不可抱有侥幸心理；来自公网的恶意无处不在，在 NAT 后生活了十几年的我们在初期也许还不能完全意识到这种恶意，那就让这次经历成为一次宝贵的教训。

守护网络安全，从你我做起。