LiteSSL ACME DNS-01 鉴权漏洞技术分析
一、事件概述
1. 事件背景
2026 年 1 月，用户 00oo00 在 V2EX 社区披露了 LiteSSL ACME 服务存在严重的鉴权漏洞，该漏洞允许攻击者盗签他人已通过 DNS-01 验证的泛域名证书。LiteSSL 是 TrustAsia（亚洲诚信）推出的免费 ACME 证书服务。
2. 影响范围
A. 影响用户数
初步排查涉及 100 多张证书
B. 影响时长
从服务上线至漏洞披露，持续数月
C. 影响功能
所有通过 DNS-01 方式验证的域名证书（包括泛域名证书和普通域名证书）
3. 严重程度
P1 级安全漏洞（CA 信任体系核心问题）
二、漏洞原理
1. 直接原因
LiteSSL 的 DNS-01 challenges 验证缓存机制存在两个关键缺陷：
- 验证缓存有效期过长（30 天）
- 未验证签发请求是否来自同一 ACME 账户
2. 根本原因分析
graph TD
A[攻击者发现目标域名] --> B[查询证书透明度日志]
B --> C[找到目标域名的过往证书记录]
C --> D[使用自己的 ACME 账户申请相同域名]
D --> E{服务器检查缓存}
E -->|缓存有效 30天| F[跳过 DNS 验证]
E -->|缓存失效| G[要求 DNS 验证]
F --> H[成功签发证书]
G --> I[验证失败]
3. 技术细节
A. 正常 ACME DNS-01 验证流程
sequenceDiagram
participant C as ACME 客户端
participant S as ACME 服务器
participant D as DNS 服务器
C->>S: 请求域名授权
S->>C: 返回 DNS-01 挑战
C->>D: 更新 TXT 记录
C->>S: 通知验证就绪
S->>D: 查询 TXT 记录
D-->>S: 返回验证记录
S->>C: 验证通过，授权状态 VALID
B. 漏洞利用流程
sequenceDiagram
participant A1 as 攻击者 A (原账户)
participant S as ACME 服务器
participant D as DNS 服务器
participant A2 as 攻击者 B (新账户)
A1->>S: 申请 example.com 证书
S->>D: DNS-01 验证
D-->>S: 验证成功
S-->>A1: 签发证书
Note over S: 缓存验证结果 30 天
A2->>S: 使用新账户申请 example.com
S->>S: 检查缓存
Note over S: 找到有效缓存<br/>未检查账户一致性
S-->>A2: 直接签发证书
C. IP 获取问题
除核心鉴权漏洞外，还存在辅助问题：
- 速率限制基于错误获取的内网 IP（10.254.14.70）
- 将反向代理服务器的内网 IP 当做客户端 IP
三、厂商响应
1. 应急响应时间线
| 时间 | 事件 |
|---|---|
| T+0 | V2EX 帖子发布，漏洞披露 |
| T+2h | TrustAsia 官方回应，关闭证书签发接口 |
| T+4h | 定位问题，开始吊销错误签发的证书 |
| T+12h | 完成受影响证书吊销（100+ 张） |
| T+24h | Mozilla Bugzilla 报告发布 |
| T+36h | 问题修复，根因分析同步 |
2. 处理措施
A. 立即措施
- 关闭 LiteSSL 证书签发接口
- 将所有 ACME 授权域名状态从 VALID 重置为 REVOKED
- 吊销所有受影响的证书（遵循 CAB/F 24 小时要求）
B. 根本修复
- 修复 DNS-01 验证缓存的账户隔离问题
- 缩短验证缓存有效期
- 修复 IP 获取逻辑
C. 透明披露
- 在 Mozilla Bugzilla 发布初步报告
- 在 V2EX 原帖持续更新处理进展
- 计划后续发布根因分析
四、技术深度分析
1. 漏洞本质
A. EAB 绑定问题
- LiteSSL 使用 EAB（External Account Binding）标识账户
- 验证缓存与 EAB 绑定，但未校验请求账户与缓存账户的一致性
- 导致任何账户都可以利用其他账户的验证缓存
B. 缓存策略缺陷
- 30 天的缓存有效期远超行业标准
- Let's Encrypt 通常为 30 天，但配合账户隔离机制
- 长有效期扩大了攻击窗口
2. 实际攻击场景
A. 攻击前提
- 目标域名必须曾在 LiteSSL 签发过证书
- 目标域名使用 DNS-01 方式验证
- 验证缓存仍在有效期内
B. 攻击限制
- 无法用于任意域名（必须有过往签发记录）
- 无法获取原证书的私钥
- 需要配合其他攻击手段（如 DNS 劫持）才能实现中间人攻击
3. 与历史事件对比
| 事件 | CA | 问题 | 后果 |
|---|---|---|---|
| DigiNotar (2011) | DigiNotar | 恶意签发伪造证书 | CA 破产，根证书被吊销 |
| StartCom (2016) | StartCom | 签发流程不规范 | 被 Chrome/Firefox 移除信任 |
| TrustAsia (2026) | TrustAsia | ACME 验证缓存隔离失效 | 主动披露，快速修复 |
五、安全影响评估
1. 直接影响
A. 受影响证书类型
- 仅影响通过 ACME 协议签发的免费证书
- 商业证书和 API 签发的证书不受影响
- 主要影响使用 DNS-01 验证的域名
B. 攻击者能做什么
- 为他人域名申请新证书
- 证书私钥由攻击者控制
- 可用于搭建钓鱼网站
- 配合 DNS 劫持可实现中间人攻击
C. 攻击者不能做什么
- 无法获取原证书的私钥
- 无法吊销他人的合法证书
- 无法影响未在 LiteSSL 签发过的域名
2. 间接影响
A. 信任体系冲击
- CA 的核心职责是确保签发证书的鉴权准确性
- 此漏洞违反了 CA/Browser Forum 基线要求
- 可能影响 TrustAsia 的品牌信誉
B. 生态影响
- 用户对免费 ACME 服务的信任度下降
- 引发对其他 CA 类似问题的担忧
- 强调了证书透明度（CT）日志的重要性
六、经验总结
1. 厂商做得好的地方
A. 响应及时
- 收到通知后 2 小时内关闭服务
- 24 小时内完成证书吊销
- 积极与社区沟通
B. 处理透明
- 在原贴持续更新进展
- 主动披露 Mozilla Bugzilla 报告
- 承认问题，不推诿责任
C. 修复彻底
- 从审慎角度，重置所有授权状态
- 计划发布详细根因分析
- 考虑建立 SRC 安全响应中心
2. 需要改进的地方
A. 设计缺陷
- 缓存机制未考虑账户隔离
- 缓存有效期设置过长
- IP 获取逻辑存在基础错误
B. 测试不足
- 此类基础鉴权问题应在测试阶段发现
- 缺少安全审计和渗透测试
- 未充分考虑 ACME 协议的安全边界
C. 监控缺失
- 缺少异常签发行为监控
- 没有证书透明度日志的自动监控告警
3. 行业启示
A. CA 运营教训
- 免费服务和付费服务需同等安全标准
- ACME 协议实现需严格遵循 RFC 规范
- 信任是 CA 的核心资产，一旦破坏难以恢复
B. 安全开发建议
- 鉴权系统需进行威胁建模
- 缓存机制必须考虑权限边界
- 多层防御：缓存隔离 + 速率限制 + 异常检测
C. 社区监督价值
- 白帽子披露对生态安全至关重要
- 透明的漏洞披露流程有助于建立信任
- 社区反馈渠道的有效性（邮件、在线客服）
七、技术建议
1. 对用户
A. 立即行动
- 检查是否使用 LiteSSL 签发的证书
- 如受影响，按 TrustAsia 指引重新申请证书
- 监控证书透明度日志，检测异常签发
B. 长期措施
- 启用证书透明度监控（如 Cloudflare CT Monitor）
- 使用信誉良好的 CA（Let's Encrypt、DigiCert 等）
- 定期审查证书来源和有效期
2. 对 CA 运营者
A. ACME 实现建议
- 严格按照 RFC 8555 实现鉴权逻辑
- 验证缓存必须与账户强绑定
- 缩短缓存有效期或实现即时失效机制
B. 安全加固
graph LR
A[ACME 请求] --> B{账户验证}
B -->|失败| C[拒绝请求]
B -->|成功| D{缓存检查}
D -->|命中且账户匹配| E{缓存时效}
D -->|未命中或账户不匹配| F[强制 DNS 验证]
E -->|有效| G[使用缓存]
E -->|失效| F
F --> H[更新缓存]
H --> I[签发证书]
G --> I
C. 监控告警
- 监控同一域名的多账户签发行为
- 异常证书签发行为告警
- 定期审计证书透明度日志
3. 对 ACME 客户端开发者
A. 安全最佳实践
- 为每个用户使用独立的 EAB
- 避免共享 EAB 给多用户使用
- 实现 ARI（ACME Renewal Information）特性
B. 集成建议
- 优先支持直连 ACME 模式
- 如需代理模式，确保严格的账户隔离
- 支持证书自动更新和吊销
八、相关技术标准
1. ACME 协议规范
- RFC 8555：ACME 协议定义
- RFC 8737：ACME 账户绑定外部账户
- RFC 8738：批量证书申请
2. CA/Browser Forum 基线要求
- 版本 1.8.0：域名验证要求
- 证书透明度要求
- 密钥泄露响应要求
3. 证书透明度（CT）
- RFC 6962：证书透明度协议
- 所有公开信任的证书必须录入 CT 日志
- 用户可通过 crt.sh 等服务查询证书记录