CVE-2024-9486 和 CVE-2024-9594：K8S Image Builder 构建的 VM 镜像使用默认凭证

0x00 概述

文章概述了 Kubernetes 的 Image Builder 项目中的两个安全漏洞 CVE-2024-9486 和 CVE-2024-9594 ，描述了漏洞发现、修复过程及风险评估，提供了检测和缓解措施，并分析了漏洞原因。

其实这两个漏洞非常简单，就是将凭证硬编码在代码文件中了，并且影响的资产范围不大，所以也没有网上说的那么严重。

让我们来看看到底怎么回事～

0x01 时间线

2024 年 10 月 12 日

Rybnikar Enterprises GmbH 的Nicolai Rybnikar^[1] 向 Kubernetes 报送了 CVE-2024-9486 和 CVE-2024-9594 漏洞，并由 Red Hat 的Joel Smith^[2]提交了两个 Issue，分别是：

1. CVE-2024-9486：使用 Image Builder 构建的且镜像提供商是 Proxmox 的 VM 镜像使用了默认的登录凭证^[3]
2. CVE-2024-9594：使用 Image Builder 构建的一些提供商的 VM 镜像使用了默认的登录凭证^[4]（这里的提供商指的是 Nutanix、OVA、QEMU 和原始提供商）

2024 年 10 月 14 日

Image Builder^[5]项目的Marcus Noble^[6]提交了两个 PR 进行修复，分别是：

1. CVE-2024-9486：确保 Proxmox 提供商清理了 builder 用户^[7]
2. CVE-2024-9594：为 builder 用户设置随机的 ssh 密码^[8]

由于 Image Builder 项目是由kubernetes/kubernetes-template-project^[9]模板生成的，且归属于Kubernetes SIGs^[10]（Kubernetes SIG 相关工作的组织），所以 Kubernetes 在当天就发布了一则安全公告：

• CVE-2024-9486 和 CVE-2024-9594：若 VM 节点的 VM 镜像是使用 Kubernetes 的 Image Builder 项目构建的，那么未经授权的用户可以使用 ssh 登录到这个节点中。^[11]

2024 年 10 月 15 日

NVD 发布了 CVE-2024-9486 ^[12] 和CVE-2024-9594^[13]的漏洞信息。

2024 年 10 月 16 日

NVD 对漏洞信息进行了更改，最终的信息为：

表1：漏洞的基本信息

这两个漏洞都使用的是 CVSS 版本 3.1 的评分系统。

从 CVSS 向量来看， CVE-2024-9486 漏洞更容易被远程攻击者利用，因为它不需要高权限和用户交互，而 CVE-2024-9594 漏洞更难以被利用，因为它需要攻击者具有更高的权限和可能的用户交互，并且攻击向量更为受限。

不过，两者在机密性、完整性和可用性的影响上都是高度严重的。

表2：CVSS 评分差异

当天下午 7:01， CVE-2024-9486^[15] 和CVE-2024-9594^[16]的 EPSS 分数皆为 0.05%（百分位数：16.4%）

0x02 风险排查

用户可以按照以下步骤依次检查自己是否受到该漏洞的影响

1. 集群使用的 VM 镜像是 Kubernetes 的 Image Builder ≤ v0.1.37 构建的。
2. 使用 Proxmox 提供商构建的镜像的 VM 已经明确存在 CVE-2024-9486 漏洞。这种情况下，VM 镜像不会禁用默认凭证，并且可以通过默认凭证访问使用生成镜像的节点。这些凭证可用于获取 root 访问权限。
3. 使用 Nutanix、OVA、QEMU 和原始（raw）提供商构建的镜像的 VM 在构建过程中存在 CVE-2024-9594 漏洞。只有在攻击者能够访问到正在构建镜像的 VM，并且在构建过程中利用这个漏洞来篡改镜像时，才会受到这个漏洞的影响。
4. 使用由其他提供商构建的镜像的 VM 不受影响。

若要查看所使用的 Image Builder 的版本，可以使用以下方法：

• 若使用 源码安装的。

cd <local path to image builder repo>
make version

• 若使用 tarball 安装下载的。

cd <local path to install location>
rep -o v0\.[0-9.]* RELEASE.md | head -1

• 若通过容器镜像部署的。

docker run --rm <image pull spec> version

或者

podman run --rm <image pull spec> version

或者是查看镜像的TAG。如果是官方镜像registry.k8s.io/scl-image-builder/cluster-node-image-builder-amd64:v0.1.37，那么Image Builder 的版本就是 v0.1.37

0x03 缓解措施

使用的 ≥ v0.1.38 （已修复）版本的 Image Builder 重构受影响的镜像，再将已修复后的镜像重新部署到所有受影响的 VM 中。

若无法进行升级，可以通过禁用受影响的 VM 上的builder账户来缓解此漏洞。

usermod -L builder

0x04 检测方法

使用 linux 命令last builder来查看受影响的builder账户的登录信息。

0x05 漏洞分析

Image Builder 的 v0.1.37（存在漏洞）版本在使用 Proxmox、Nutanix、OVA、QEMU 和原始（raw）提供商所提供的镜像来构建镜像时，将ssh_username和ssh_password的值（皆为builder）硬编码在代码文件中，因此未经授权的用户可以使用默认用户builder来远程登录到受影响的节点中。

Image Builder 在 v0.1.38（已修复）的版本中，将默认用户builder的密码设置为随机值，即变量{{uuid}}。

此外，在 Proxmox 提供商提供的镜像构建结束过后，还禁用了builder用户。下面的这段 SHELL 脚本的意思是：使用所提供的用户名ssh_username和密码ssh_password锁掉该用户，然后关闭系统断开连接。

0x06 参考链接

https://thehackernews.com/2024/10/critical-kubernetes-image-builder.html