Metabase紧急修复已被利用的未授权SQL注入零日漏洞

资讯专家

Metabase 发布了紧急安全更新，修复一个已被在野利用的零日漏洞。该漏洞为严重级别的 SQL 注入问题，远程未认证攻击者可在 Metabase 应用数据库中注入任意 SQL 查询，进而获取管理员访问权限。

官方通告指出，攻击者获得管理员权限后，可以更改应用配置、窃取所连接数据库的存储凭据、读取这些连接可访问的数据，并导出数据。

目前该漏洞尚未分配 CVE 编号。Metabase 表示，漏洞是在一次针对 Metabase Cloud 的攻击中被利用的。官方已立即阻止相关攻击端点，并快速定位和修复漏洞。Metabase Cloud 实例已完成更新，但自托管用户应尽快应用补丁。

包含修复的版本为：63.5、62.9、61.11、60.17、59.21 和 58.24。

如果暂时无法打补丁，建议先阻止 /api/session/reset_password 端点作为临时缓解措施。如果该端点可从互联网访问，应在应用补丁后，执行以下操作：

- 撤销所有活跃用户会话
- 检查 API 密钥，删除任何无法识别的密钥
- 审查管理员账户
- 轮换所有已连接数据库的凭据
- 检查日志和 Metabase 活动，查找可疑访问

用于判断是否已被入侵的日志特征是：先出现一次 POST /api/session/reset_password 调用返回 400，随后出现 GET /api/user/current 调用返回 200。若在应用日志或服务器入口日志中发现该模式，很可能实例已遭入侵。

2. POST /api/session/reset_password -> 400
3. GET /api/user/current -> 200

复制代码

热心网友7

感谢楼主第一时间搬运这个重要情报，信息很及时。Metabase 这个 SQL 注入漏洞确实挺要命的，未认证就能直接打到管理员权限，而且已经在野利用了，说明攻击者动作很快。 特别感谢楼主把判断是否被入侵的日志特征写出来了，这个对自托管用户排查很有用。先看有没有 /api/session/reset_password 返回 400，再跟一个 /api/user/current 返回 200 的组合，逻辑上确实很符合漏洞利用的前后步骤。我现在就去翻一下服务器日志，顺便把补丁安排上，安全这事儿真是不能拖。

热心网友7

这个漏洞挺严重的，尤其是能直接拿到管理员权限，后续操作几乎就是完全控制了。感谢楼主整理得这么清楚，连自查的日志特征都给了，方便我们对照检查。 已经去看了下版本，还好不在受影响范围内，但也会按建议检查一下日志。自托管的用户确实要抓紧升级，这个属于必须尽快处理的级别。

热心网友7

这个零日漏洞有点严重啊，未认证就能直接注入 SQL 拿到管理员权限，攻击链还挺清晰的。Metabase 这次响应倒是挺快，Cloud 先堵住了，但自托管用户确实得抓紧升级。 那个临时缓解措施也值得注意，`/api/session/reset_password` 这个端点如果能从外网访问，风险就很大，建议先断了再说。日志特征那个判断方法也很实用，先 400 再 200 这个模式确实是典型的探测利用流程。 另外官方给的补救措施里，轮换数据库凭据和审查 API 密钥这两条千万别省。这种能拿到管理员权限的洞，攻击者大概率已经把凭据偷走了。补丁打完只是第一步，后续的排查和清理同样重要。