我们使用 StepSecurity Harden-Runner 分析了 XZ Utils 的构建过程，并观察到了后门的注入。此分析展示了构建过程中运行时安全监控的重要性，以及它如何帮助检测此类供应链攻击。
引言
最近的 XZ Utils 供应链安全事件震动了整个行业。XZ 是一种通用数据压缩格式，几乎存在于每个 Linux 发行版中，无论是社区项目还是商业产品发行版。
根据 CVE-2024-3094，构建过程会提取源代码中存在的伪装测试文件，然后使用该文件恶意修改 liblzma 代码中的特定函数以注入后门。
我们使用 StepSecurity Harden-Runner 分析了 XZ Utils 的构建过程，并观察到了后门的注入。
观看此视频了解 XZ Utils 构建过程的完整分析，或阅读博客文章：
Try StepSecurity for Free
事件与攻击者策略
该事件涉及构建过程中的以下恶意修改：
- build-to-host.m4 文件的修改：此文件在 5.6.0 和 5.6.1 版本的发布 tarball 中被篡改。
- 压缩文件的添加：两个恶意文件被压缩并添加到源代码仓库的 tests/files 文件夹中。
攻击者有意避免直接在源代码中嵌入目标文件或修改构建指令来链接它，因为这些操作会引起怀疑。相反，他们选择了一种更隐蔽的方法，通过添加测试文件和修改发布 tarball 中的 build-to-host.m4 文件（该文件不在源代码中）。这种策略确保了恶意修改会在构建过程中发生，而构建过程通常不受严格监控。因此，此恶意修改不会被静态分析工具检测到。攻击者依赖这种监控缺失来逃避检测。
Harden Runner：保护构建过程
StepSecurity Harden-Runner 为 GitHub 托管和自托管运行器环境提供网络出口控制及 CI/CD 基础设施安全保护。它已被 Microsoft、Google、CISA、DataDog、Intel 以及数百个其他组织用于增强其 GitHub Actions 安全性。
Harden Runner 的主要功能包括：
- 实时监控：在构建过程中持续观察文件写入操作，以发现异常活动。
- 异常检测：识别与预期构建行为的偏差，标记潜在的安全威胁。
- 详细洞察：提供全面的报告和构建过程洞察，帮助确定问题的确切性质和来源。
通过将 Harden Runner 集成到您的构建系统中，您可以增强安全态势，确保任何篡改行为都能被及时检测并缓解。
使用 Harden Runner 分析事件
GitHub 仓库与工作流
正在构建的代码托管在此 GitHub 仓库中。代码最初来源于 Debian 的仓库，特别是 debian/5.6.0-0.2 标签。
用于运行这些步骤的 GitHub Actions 工作流配置如下：
- 从仓库检出代码
- 运行 configure 脚本生成 Makefile
- 执行 make 步骤构建 XZ Utils 二进制文件
工作流集成了 Harden Runner 来监控和分析构建过程。以下是工作流执行中的 Harden Runner 洞察：
Harden-Runner 观察到的文件写入事件
"文件写入事件"选项卡显示了构建过程中写入的每个文件、写入该文件的进程以及进程参数。
XZ Utils 构建过程
XZ Utils 的构建过程分为两个主要部分：
- Configure 步骤：此步骤涉及运行 configure 脚本生成 Makefile
- Make 步骤：然后使用 Makefile 构建 XZ Utils 二进制文件
1. Configure 步骤：
在 configure 步骤中，被篡改的 build-to-host.m4 文件导致 Makefile 被修改。执行了多个 sed（流编辑器）命令来就地修改 Makefile，添加了对名为 bad-3-corrupt_lzma2.xz 的测试文件的引用。
Harden Runner 分析：使用 Harden Runner，我们实时观察到了这些变化。以下是 configure 步骤期间可疑修改的屏幕截图。
在文件写入事件查看器中，点击 "src/liblzma/Makefile" 会显示写入 Makefile 的不同进程。在之前未篡改的发布 tarball 的构建过程中，Makefile 仅由第一个 mv 进程写入。
另一方面，在 5.6.0 版本的构建中，您可以清楚地看到多个 sed 命令写入 Makefile。这是由于 build-to-host.m4 文件中的恶意代码，该文件位于 "m4" 文件夹中并在 configure 步骤期间运行。
构建过程中 Makefile 被恶意篡改
点击任何 sed 命令并向上查看进程树可以显示进程参数。
Makefile 中添加了对 tests/files 文件夹中 "bad-3-corrupt_lzma2.xz" 文件的引用。
Harden-Runner 通过在构建过程中监控进程调用来获取此信息。对于 PID: 6645 的进程，您可以看到对 tests/files 文件夹中 "bad-3-corrupt_lzma2.xz" 文件的引用被添加到 Makefile 中。对于 PID: 6650 的进程，您可以看到 "xz -d" 命令被添加到 Makefile 中。这将在后面导致 "bad-3-corrupt_lzma2.xz" 被解压并使用 bash 执行（更多内容见下文）。
2. Make 步骤：
在 make 步骤中，修改后的 Makefile 被运行，导致以下可疑活动：
- 目标文件的创建：另一个测试文件被解压以创建目标文件，这是不寻常的，因为目标文件通常使用编译器创建
“liblzma_la-crc64-fast.o” 文件截图
"liblzma_la-crc64-fast.o" 文件由 dash(shell) 而不是编译器写入
在 "src/liblzma" 文件夹中，如果您查找 "liblzma_la-crc64-fast.o" 文件并点击它，您会注意到它是由 dash（Debian Almquist Shell，bash 的 POSIX 兼容实现）写入的。请将此与屏幕截图中另一个由 linux-gnu-as 写入的目标文件进行比较，linux-gnu-as 是一个汇编器，用于汇编 GNU C 编译器的输出以供链接器使用。
如果您点击 dash 进程，您可以向上查看进程树并查看进程参数。
测试文件 "good-large_compressed.lzma" 被解压和解码以创建恶意目标文件
在这里您可以看到测试文件 "good-large_compressed.lzma" 被解压，对文件进行了一些处理，然后再次解压并取出一部分内容作为目标文件写入。这在构建过程中是一个巨大的危险信号，因为目标文件应该通过编译和链接代码来创建，而不是通过解压压缩的测试文件。您稍后会看到这个目标文件如何被链接以创建另一个目标文件，然后用于创建 xz utils 二进制文件。
要了解是什么导致了这个目标文件通过解压测试文件被创建，您可以向上查看进程树。
bad-3-corrupt_lzma2.xz 被解压并执行
您可以看到解压 "good-large_compressed.lzma" 文件的过程是由解压并执行 "bad-3-corrupt_lzma2.xz" 文件启动的。如果您还记得之前对 Makefile 的篡改，您会记得看到这些被插入到 Makefile 中的语句。
- 源代码文件的修改和管道传输：一个源代码文件被修改，并与目标文件一起作为输入通过管道传输到编译器。这是不规范的，因为代码文件通常不会通过管道输入发送给编译器。
在"文件写入事件"查看器中，如果您进入 "src/liblzma/.libs" 文件夹，您会注意到一些目标文件已被覆盖。如果您点击 "liblzma_la-crc64_fast.o" 文件和 "/usr/bin/x86_64-linux-gnu-ld.bfd (PID: 14551)" 进程，您可以看到是什么进程第二次写入该文件。
src/liblzma/check/crc64_fast.c 被篡改，恶意目标文件被链接以注入后门
在这里您可以看到 "src/liblzma/check/crc64_fast.c" 文件被进程 ID 14544 读取并在内存中修改。这个修改后的文件不会写入磁盘，但进程 14547 中的 "-x c –" 参数从前一个进程获取修改后的源代码文件作为输入。这是一个巨大的危险信号，因为编译器应该从磁盘读取文件而不是将它们作为输入参数。您还会注意到在进程 14547 中，通过解压测试文件写入的目标文件 "liblzma_la-crc64-fast.o" 在此步骤中被链接，这就是 xz 二进制文件被植入后门的方式。
Try StepSecurity for Free
结论
XZ Utils 事件强调了在构建环境中保护安全的重要性。被篡改的 build-to-host.m4 文件和添加到 tests/files 文件夹的压缩文件导致构建过程中出现了一系列不寻常和可疑的活动。Harden Runner 被证明是检测和分析这些变化的无价工具。
通过将 Harden Runner 集成到您的构建系统中，您可以显著增强安全态势，确保任何篡改或恶意修改都能被及时识别和缓解。
如果您负责管理构建环境，请考虑实施 Harden Runner 来保护您的系统免受类似事件的影响。要开始使用 Harden-Runner，请访问此处。