最近，不少做物联网和时序数据的同行应该已经注意到，Apache IoTDB 2.0.10 被披露出一批相当严重的问题。核心并非某个函数实现出错，而是整体认证设计存在重大缺陷。
简单来说：系统把主要防守力量集中在 SQL 会话这条主路径上，登录校验、权限检查都做了。可一旦请求改走管道接收（pipe）、旧版管道或集群内部 RPC 等接口，认证几乎形同虚设。
具体表现非常直接：
- 管道配置平面的授权开关采用“失败即开放”策略。也就是说，权限判断出错或未配置完善时，系统默认允许操作，而不是拒绝。
- 内部 RPC（例如 10710、10730 等端口）上的大量关键操作根本不验证身份，谁连上谁就能调用。
- 最终结果是，攻击者可以借这些非 SQL 入口直接加载恶意类、写文件、删数据，甚至提升权限。部分场景下，只要默认账号未修改，或能连通对应端口，就能直接 RCE。
这已经不是某个功能点的小 bug，而是架构层面的疏忽：开发时默认“SQL 入口是主入口，其他入口仅供内部使用，安全上可以放松”。可在实际部署中，不少环境要么把这些端口直接暴露，要么集群节点之间网络互通，风险随之被放大。
目前来看，2.0.10 版本是重灾区。上游虽然已经修复了部分问题，但修复尚未正式发版，因此仍运行 2.0.10 的线上环境风险未解。
如果你正在使用 IoTDB，尤其是开启了管道功能或部署了集群，建议尽快自查以下几项：
- 确认当前版本，持续关注官方新版本发布。
- 检查默认密码是否已经修改。
- 管道相关端口与内部 RPC 端口尽量不要对公网或不可信网络开放。
- 有条件的情况下，可以先关闭管道功能，或严格限制访问来源。
这类“主路径上锁、旁路敞开”的设计，在很多中间件里都曾经出现。IoTDB 这次不过是再次提醒我们：只要系统暴露的接口不止一个，安全就必须覆盖所有入口，不能只盯着最常用的那一条。
POC:
| 
发表于 4 小时前
|
查看: 2|
回复: 0
