运维123 - TrustAsia
type: channel
link: https://www.sddts.cn/index.php/tag/TrustAsia/
items: LiteSSL ACME DNS-01 鉴权漏洞技术分析

LiteSSL ACME DNS-01 鉴权漏洞技术分析
type: item
date: 2026-01-22T06:58:15+00:00
description: 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: 验证通过，授权状态 VALIDB. 漏洞利用流程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: 找到有效缓存 未检查账户一致性 S-->>A2: 直接签发证书C. IP 获取问题除核心鉴权漏洞外，还存在辅助问题：速率限制基于错误获取的内网 IP（10.254.14.70）将反向代理服务器的内网 IP 当做客户端 IP三、厂商响应1. 应急响应时间线时间事件T+0V2EX 帖子发布，漏洞披露T+2hTrustAsia 官方回应，关闭证书签发接口T+4h定位问题，开始吊销错误签发的证书T+12h完成受影响证书吊销（100+ 张）T+24hMozilla 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…