企业官网建设流程全解析

分析

valdikss.org 上的分析博客非常详细，这类事情通常在操作失误时才被发现。阅读分析内容时，直观展示经验价值。关键在于细节，`acme.sh` 非常小。处理信息会失去相关性顺序，通常会浏览文档找时间数字串联事情。

关注 2023 年 4 月 18 日左右可能涉及 `acme.sh` 的事件，并记录之后发生的事情。

acme.sh

[ACME] 是用于建立从证书颁发机构颁发和更新 TLS 证书信任机制的协议，[acme.sh] 是借助该协议帮助自动化此过程的 shell 脚本可执行文件，在 jabber.ru 服务器上运行以促进 TLS 证书更新。

2023 年 4 月 18 日左右与 `acme.sh` 相关重要事件包括：2023 年 6 月 8 日，一个远程代码执行漏洞被披露，最终被分配 CVE 编号 [CVE - 2023 - 38198]；2023 年 6 月 9 日，发布了修复版本。4 月 18 日运行 acme.sh 的 jabber.ru 服务器使用的版本易受此漏洞攻击。

CVE - 2023 - 38198

在首次披露该漏洞的 GitHub 问题中，有人指出这个漏洞被名为 “HiCA” 的证书颁发机构利用来颁发证书。GitHub 问题中有 shell 插值混乱及绕过禁止或过滤字符的操作。

该漏洞本质在于网络数据与 ACME 客户端处理数据表现形式的差异，调试日志内容与原始数据相近但有缺失。

有效负载会执行操作，引发更多操作，最后一张截图虽非 ACME 标准操作，但本质无害，促进了公钥基础设施验证，解释了 HiCA 利用漏洞的意图，但对 “如何实现” 解释不多。

如何实现

该漏洞涉及 ACME 挑战类型为 http - 01、某种形式的命令注入、漏洞存在于 `Token` 字段、某些字符不被允许等方面。

通过对 [ACME 服务器] 进行修改，尝试简化 GitHub 问题中的有效负载，但无法让将 [输入字段分隔符] 重新定义为 `IFS = ^` 的操作生效，ACME 涉及太多预处理层，无法用这种方式实现远程代码执行。

坚信至少有一种情况正确：一是自己太笨无法让 IFS 技巧绕过过滤器；二是 HiCA 在记录时间范围内积极研究和更改有效负载。IFS 技巧常被僵尸网络运营商滥用，让人思考 HiCA 精通此技巧却做良性操作的原因。

自己动手

GitHub 中列出的令牌响应试图将 IFS 重新定义为 `^`，但在尝试的系统或变体中都不起作用，也无法通过 acme.sh 的字段解析。

预期机制是通过特定技巧组合在解释和解析层次中创建和使用字符，以绕过 acme.sh 的 ACME 颁发流程。

采用嵌套空格编码方式编码 shell 命令绕过过滤器，得出新的有效负载。解开命令是对 Base64 编码内容进行解码并传输到 python3 标准输入。

因 Linux 中文件路径组件最大长度限制，需进行代码精简，编写简单加载器连接回服务器读取并执行 Python 代码。在服务器上，将 Python 反向 shell 管道输入解释器，在另一个端口捕获 shell。

acme.sh 客户端会无限期挂起，不会触发错误，唯一可疑迹象是标准的 Python3 解释器。有高权限 shell 可清理或保留 `/tmp` 中的利用代码，`/tmp` 目录在系统重启时会清空痕迹。

进程树显示 sh 运行 acme.sh 下有 python3 进程。成功利用漏洞需控制 ACME 客户端和 CA 响应的网络路由。

总结

一次假定合法的操作涉及秘密重定向网络流量，颁发多个欺诈性 CA 签名证书，因忘记更新证书或拆除拦截操作被发现。同时存在隐蔽的远程代码执行漏洞被利用，窃听者可复制证书用于 TLS 拦截且不留痕迹。

可能永远无法确切知道 jabber.ru 的 CA 签名 TLS 窃听事件发生了什么。时间线和概念验证漏洞利用表明，ACME 协议虽严谨，但运行协议的软件是薄弱环节，ACME 客户端仍存在漏洞，有恶意 CA 或控制网络路由时，漏洞易被利用。

事件发生后，有博客探讨未来防范此类攻击：。