文章总结： XZUtils后门事件后一年多，研究发现超过35个Docker镜像仍包含该后门，包括12个Debian基础镜像和23个基于这些基础镜像构建的二级镜像。这些受感染的镜像在DockerHub上公开发布，可能被用于企业环境。尽管已向Debian维护人员报告，但受影响镜像仍存在。这一发现凸显了容器生态系统中持续二进制级别监控的必要性，因为即使是短暂的恶意代码也可能长期潜伏并传播。
综合评分： 86
文章分类： 漏洞分析,供应链安全,云安全,威胁情报,漏洞预警
XZ Utils 后门仍潜伏在 Docker 镜像中
独眼情报
2025年8月13日 14:16
湖北
去年三月底，臭名昭著的 XZ Utils 后门被发现，震惊了整个网络安全社区。一位名叫“Jia Tan”的开发者，花了两年时间通过大量的贡献，为该项目赢得了良好的声誉，却在 xz-utils 软件包中植入了一个复杂的后门。这一发现促使包括 Binarly REsearch 团队在内的网络安全专家们争先恐后地对该后门进行逆向工程，以了解其范围和潜在影响。
简而言之，该后门嵌入在 OpenSSH 服务器使用的 liblzma.so 库中，当客户端与受感染的 SSH 服务器交互时会被触发。恶意代码的最终目标是在 sshd 进程中安装三个钩子，分别针对 RSA_public_decrypt 、 RSA_get0_key 和 EVP_PKEY_set1_RSA 函数，从而启用后门功能。这是通过一系列复杂的钩子实现的，这些钩子由 liblzma.so 库中修改后的 lzma_crc32 和 lzma_crc64 的 IFUNC 解析器启动。去年，我们发布了一份全面的分析报告， 详细介绍了钩子链和后门的功能。
这篇报道真正引人注目的是，该后门的影响远不止理论上，因为包含该后门的恶意 xz-utils 软件包已被多个主流 Linux 发行版（包括 Debian、Fedora 和 OpenSUSE）传播。这对软件供应链造成了严重影响，因为快速识别所有包含该后门库的位置变得非常困难。在 24 小时内，Binarly 发布了 XZ.fail ，这是一款免费的基于静态分析的工具，旨在以接近于零的误报率检测可疑的 IFUNC 解析器。
在这篇博客中，我们分享了 XZ Utils 事件中的一个新发现：在入侵事件发生时构建的几个 Docker 镜像都包含后门。
乍一看，这似乎并不令人担忧：如果发行版软件包被植入后门，那么任何基于它们的 Docker 镜像也会被感染。然而，我们发现，其中一些被感染的镜像仍然在 Docker Hub 上公开发布 。更令人不安的是， 其他镜像是在这些受感染的基础镜像之上构建的，这使得它们具有传递性感染。
总共，我们识别出超过 35 个带有该后门的镜像。虽然这个数字看起来似乎很小，但我们只扫描了 DockerHub 上发布的一小部分镜像，并且只扫描了二级镜像 。此外，我们只关注 Debian 镜像，因为它们在 Docker Hub 上保留了历史数据。
目前，受 XZ Utils 后门影响的 Fedora、OpenSUSE 和其他发行版的 Docker 镜像所受的影响尚不清楚。
Docker Hub 镜像中残留的后门
在 Binarly，我们始终致力于为客户提供有意义的成果，提升他们对真实安全风险的可视性，并减少误报。为了实现这一目标，我们不断改进工具，以领先于不断变化的威胁，并提供精准、可操作的洞察。最近，我们收集了一个包含近 15TB Docker 镜像的海量数据集，并成功利用这些数据集增强了我们的秘密发现能力。
考虑到构建数据集所需的工作量，我们决定强化 Binarly 透明平台的其他功能，特别是与恶意代码检测相关的分析。这套自动化分析套件专注于常见的修改类型，例如 ELF 文件中的异常以及各种挂钩技术，包括“Jia Tan”用于实现后门的 IFUNC 挂钩方法。
在此过程中，我们发现 Docker Hub 上提供的 12 个 Debian Docker 镜像仍然包含一个 xz-utils 后门，而该后门已被公开发现已有一年多了。
| Tag | Manifest Digest | Blob Hash |
| — | — | — |
| rc-buggy-20240311 | a702c7f4bb57a17762e258871f45f8273ae49bec5515452d5133e66450c95ba5 | 3a737ad8ab65fe5ad068d6094fbf99ce9ed2b5beff9c86daceee8c2c50182bde |
| experimental-20240311 | 81992d9d8eb99b5cde98ba557a38a171e047b222a767dc7ec0ffe0a194b1c469 | cd5a0401cc26824227d6ffe1f921e91657dc46666e0f20f408d8d154ca49f5c0 |
| unstable-20240311-slim | 7a3332fbf100a0ef9762ead20a4224665768b237c5bfedfe0f86bf88e0c13b7a | 40f436db82f2316ccced5a0deef57fac6eb766b073d7e64d5dfe93e6782482b1 |
| unstable-20240311 | 8690225da3ca369e9be720446f73e0aa06f290776fdf2605b6ec80c2b229b9f6 | cd5a0401cc26824227d6ffe1f921e91657dc46666e0f20f408d8d154ca49f5c0 |
| trixie-20240311-slim | d4e306f14b8b7389b36be8fb0eadab638cb7744546a33a74f0fc27bb9037dc14 | b94224647092fbfb1fa9ceb18cf55a60f5a00183971516dd46f1f72f5f7b26df |
| trixie-20240311 | 85068c773f7fcc9c9acd8f244759cb2131e7a1775c5bf8d6710f76e7467fa3f1 | 93e647bfd891e82156d7a13e0f0b194003855008967ec51e962ea0d70fc59ff6 |
| testing-20240311-slim | c2e15dd5788b20f360ab3f2d8b60111b6e8b011c5c4960e0129551c743f5cd30 | 243521c5a6cd930662c078eec5f83156663f3197cf12158ce60e0a0f9d0a3eb6 |
| testing-20240311 | 0746d89c588160d0470beaae7a55e38305ede06cb5717d132bd6a795610234d8 | 522a6d12a8a3032c984d93fd141274f1cb7cc1e9a6942e3b36cbf803bbe36a12 |
| sid-20240311-slim | 94596b0770714bac6e8adef7e1d3dbc16245ad2978f94006587e44850343cb88 | 554b70c8b9ed0854851a55e915cefa47cdc18fed201b4aba87193d575410b53d |
| sid-20240311 | 0aff2113f50451631f0f8c22d85c97aad855d73545b6018fcbe9f0a78ae26583 | 3a737ad8ab65fe5ad068d6094fbf99ce9ed2b5beff9c86daceee8c2c50182bde |
| untagged | fa2016c58b4df666286dfa14b2402c05d60c556ecfd4c60635b64ad21380edba | 93e647bfd891e82156d7a13e0f0b194003855008967ec51e962ea0d70fc59ff6 |
| untagged | e24f4205978e6c0f98697e2075439825f86df56457d2d1ea9e0f8593cf5b5236 | 522a6d12a8a3032c984d93fd141274f1cb7cc1e9a6942e3b36cbf803bbe36a12 |
表 1. 包含 XZ Utils 后门的 Debian Docker 镜像。所有受影响的镜像均基于 amd64 架构构建。
在初步发现这个问题后，我们开始思考：那些可能基于这些被攻陷的 Debian 镜像构建的其他镜像又该怎么办？遗憾的是，Docker API 并没有提供反向索引，将一个镜像映射到所有使用该镜像的基础镜像。因此，我们决定编写一个脚本，用于获取 Docker Hub 仓库中现有的所有镜像，并检查其中是否有基于被攻陷的 Debian 镜像构建的镜像。
由于 Docker Hub 包含近 1200 万个仓库（每个仓库可能包含数百甚至数千个镜像），因此扫描所有仓库几乎是不可能的。因此，我们手动创建了一个可能使用 Debian 镜像的仓库列表。这个列表远非完美，因为它仅包含我们手动找到的仓库，或使用基础镜像 blob 哈希值通过 Google 搜索返回的仓库。
| 存储库 | 标签 | 最新标签？ | 清单摘要 |
| — | — | — | — |
| buildpack-deps | 未标记 | – | 5e4438a4660fff39ff4671bc5ecfaea3e639dafe61d5c19c735335c96d61c1e4 |
| buildpack-deps | 未标记 | – | 443be2e684c2974f94329fe904ab025826cd45f4a1dc52a922e5b01e66e75ee0 |
| buildpack-deps | 未标记 | – | 8f95f8a59ac3227cb7483799a6836e9c79d5cef491ba672c1958abdf36bf7648 |
| buildpack-deps | 未标记 | – | bf7c5e7df1344c29825cecf0b13a48e3542d9076344bb488f886f9dfce534e05 |
| buildpack-deps | 未标记 | – | 8d5e5912bc9fdc287f89b87e7b97a615110842f6c6f3ed380dccef85a75ef6cc |
| buildpack-deps | 未标记 | – | d650be418934c90f6e9e3efcb52bef7ad660324074002efb8541e7baf9aab6d8 |
| neurodebian | 未标记 | – | 388d46f65da097cd9371385d9c2f3f3fe04d4bc88b529b52125b9f94d74edaff |
| neurodebian | 未标记 | – | 7ffa336b9a0f2e594d1df70ce66a259db156902baa371337a6bfaae2eefa4de3 |
| r-base | 未标记 | – | 3b5c502ccd9d4a6c0937a6bfc51e02741bdc7c520fe458ce4d9c136553df42b0 |
| georchestra/jenkins-builder | sid-jdk-8 | YES | d7ad7c3386a874e81006bc6fab0ce7eb5cf227f4a1c2d3dff7850e17ff7a5f48 |
| myoung34/github-runner | 2.315.0-debian-sid | NO | 8c0c44b7404fdcdc52f4c04d41b2a674510ac98f21fb81cd68575be30eeb51a7 |
| slash5toaster/calibre | 7.7.0 | NO | fa5dcddaa909b76a8b6c5fb44a8eb833ab2f407f81cc7185a9c299e02cc1c2ef |
| flowgunso/seafile-client | 9.0.4 | NO | b6d1c3b9232874356dee489685528f94c048e6683573cdb5b0a0b106e3d85708 |
| makepad/opencv | trixie-4.8.1 | NO | 153319e41415b5a789704e31017aff2e2c8223c2e155875947639935fa4f72ca |
| makepad/opencv | trixie-4.8.0 | NO | 1b5b2b14dc1262074e0b933ae8a483a5f21c5fc2e9dd42f0b7e8f2fa2ebc12a0 |
| makepad/opencv | trixie-4.7.0 | NO | 060fddaf2879513e900d0e93097c3096f541ca871c390639bb6cb67c6fd1bc84 |
| makepad/opencv | trixie-4.9.0 | YES | 2fdc5fa0c19fe4e04d3117477f49b8b7e0e4124290d9f4270f215f8e7c5b9078 |
| makepad/opencv | trixie-slim-4.8.0 | NO | f5e90754a89e6837c7b5165b57ffd4d5d66990d798bfce1018048b7ac21f0e6a |
| makepad/opencv | trixie-slim-4.9.0 | YES | 7a4e5b592b318a38542dd21f87a810263d39a3b4caf9d85bb973594264a38fca |
| makepad/opencv | trixie-slim-4.8.1 | NO | cdb95cc294d7ea4f1703e817674c477e99a80be16a6c980f88365f77c195f0f0 |
| makepad/opencv | trixie-slim-4.7.0 | NO | 94a10719a142f3b11c6d8cd4bc88b415a163f7052061c22222df7c4c96a95aa2 |
| optionfactory/debian13 | 80 | NO | 1dedf1ad124f7eff12011122565bed92c207d3cd1c9b650a40fb680d846bd515 |
| optionfactory/debian13 | 81 | NO | 1dedf1ad124f7eff12011122565bed92c207d3cd1c9b650a40fb680d846bd515 |
| controlplane/sectools | latest | YES | 86090b316ad096e53c81f91e94ac2ae95c2f28feee10ce8ec32aa573d8263021 |
表 2. 包含 XZ Utils 后门的二级 Docker 镜像（基于已感染的 Docker 镜像）。“最新标签？”列报告受影响的标签是否为最新可用标签。
上表列出了包含 XZ Utils 后门的二级镜像 。虽然其中一些镜像看起来像是个人项目，但其他镜像可能用于企业环境。以递归方式，这些镜像本身可以作为基础镜像，从而导致创建受影响的三级镜像 ，依此类推。进行这样的递归探索是深入了解该后门在 Docker 生态系统中传播范围的唯一方法。
披露我们的调查结果
发现此问题后，Binarly 立即通知 Debian 维护人员并要求删除，但受影响的图像仍然存在。
Debian 维护者对我们的披露的回应
我们仅部分同意此回应：虽然用户确实应该依赖最新的镜像，但保留包含潜在网络可达后门的公开 Docker 镜像会构成重大安全风险。即使此问题的实际影响有限，因为利用此漏洞需要后门密钥所有者能够访问正在运行 SSH 服务的受感染设备或容器的网络。
尽管如此，我们的发现强调了即使是短暂的后门构建也可以不被注意并在容器注册表中持续很长时间。
结论
xz-utils 后门事件表明，即使是短暂的恶意代码，也可能在官方容器镜像中长期潜伏而不被察觉，并可能在 Docker 生态系统中传播。此次延迟凸显了这些恶意代码如何悄无声息地在持续集成 (CI) 管道和容器生态系统中持续存在并传播，这进一步凸显了除了简单的版本跟踪之外，持续二进制级别监控的必要性。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：独眼情报 《XZ Utils 后门仍潜伏在 Docker 镜像中》