AEAD 随机数复用的利用链:三个前置条件与最小验证
96 位随机 nonce 在加密 2^32 次后碰撞概率约 1/2^32,仍在可接受范围,超过就该换密钥
这篇只讲机制与验证思路,所有测试都应该在授权范围内、对自己的环境做。
先说结论
三个条件全满足才是高危;只有一两个,多半是「理论上可以」。
- 条件一:入口可达(能碰到)
- 条件二:校验可绕(能通过)
- 条件三:影响可证(能造成后果)
- 验证:用无害 payload 证明,不落地
- 修复:堵住入口或加严校验,二选一
条件一:入口可达
96 位随机 nonce 在加密 2^32 次后碰撞概率约 1/2^32,仍在可接受范围,超过就该换密钥。
先确认这个入口是否对外、是否需要登录、是否有网关拦截。很多「漏洞」死在第一步。
条件二:校验可绕
AAD 不加密但参与认证,把用户 ID 放进去能防密文被搬到另一个账号下,也能挡重放。
校验的常见问题是「只做一次」和「只做黑名单」,绕过思路通常来自这两点。
条件三:影响可证
认证标签从 128 位截断到 32 位,伪造成本就从 2^128 降到 2^32,余量要留够。
| 影响等级 | 判断依据 | 处置 |
|---|---|---|
| 高 | 可读取敏感数据或执行代码 | 立即修,评估是否已利用 |
| 中 | 可越权访问部分数据 | 本周内修 |
| 低 | 仅信息泄露,且需高权限 | 排期修 |
| 误报 | 条件二或三不成立 | 记录并关闭 |

这个问题的几个已知事实
公开资料里比较确定的几条:
- 解密失败必须整体拒绝,先返回明文再校验标签等于完全没有校验
验证方法(无害)
用能证明问题存在的最小动作,不读取真实数据、不写入、不横向。
修复思路
nonce 用计数器实现时,进程重启后计数器归零是生产环境最常见的坑,计数器要持久化或改用随机。
修完必须回归:同一入口的其它路径、同一参数在其它接口、以及历史数据的兼容。
再补充几点
这几条不改变结论,但会改变你评估风险时的顺序。
- GCM 下同一密钥重复使用 nonce,能直接恢复明文,并且可以伪造认证标签
- 把 nonce 写成固定常量,测试通过就直接上线
- 解密后先交给业务处理,最后才验标签
- 随机 nonce 用了弱随机源,碰撞概率远高于理论值
能证明「三个条件都成立」,比能打穿更重要。
评论 (3)
补一句:修完要回归,很多人修一半。
终于有人讲清楚「为什么」而不是只给命令。
防御那节写得克制,没有教人打站,这点好评。
发表评论