Kubernetes Image Builder 中披露了一个严重的安全漏洞，如果成功利用，可能会在某些情况下被滥用来获取 root 访问权限。

该漏洞编号为CVE-2024-9486（CVSS 评分：9.8），已在 0.1.38 版本中得到解决。项目维护人员感谢 Nicolai Rybnikar 发现并报告了该漏洞。

Red Hat 的 Joel Smith在警报中表示： “在 Kubernetes Image Builder 中发现了一个安全问题，在映像构建过程中启用了默认凭据。”

“此外，使用 Proxmox 提供程序构建的虚拟机映像不会禁用这些默认凭据，并且使用生成的映像的节点可以通过这些默认凭据访问。这些凭据可用于获取 root 访问权限。”

话虽如此，只有当 Kubernetes 集群的节点使用通过 Image Builder 项目与 Proxmox 提供程序创建的虚拟机 (VM) 映像时，集群才会受到该漏洞的影响。

作为临时缓解措施，建议禁用受影响虚拟机上的构建器帐户。还建议用户使用固定版本的 Image Builder 重建受影响的映像并将其重新部署到虚拟机上。

Kubernetes 团队实施的修复措施是，在镜像构建期间，随机生成密码，不再使用默认凭据。此外，在镜像构建过程结束时，构建者帐户将被禁用。

Kubernetes Image Builder 版本 0.1.38 还解决了使用 Nutanix、OVA、QEMU 或原始提供程序创建映像构建时默认凭据的相关问题（CVE-2024-9594，CVSS 分数：6.3）。

CVE-2024-9594 的严重性较低，这是因为使用这些提供程序构建的映像的虚拟机仅会受到影响，“如果攻击者能够到达正在构建映像的虚拟机，并利用漏洞在构建映像时修改映像”。

微软发布了针对 Dataverse、Imagine Cup 和 Power Platform 三个严重漏洞的服务器端补丁，这些漏洞可能导致权限提升和信息泄露 -

CVE-2024-38139（CVSS 评分：8.7）——Microsoft Dataverse 中的不正确身份验证允许授权攻击者通过网络提升权限
CVE-2024-38204（CVSS 评分：7.5）——Imagine Cup 中的不当访问控制允许授权攻击者通过网络提升权限
CVE-2024-38190（CVSS 评分：8.6）- Power Platform 中缺少授权，允许未经身份验证的攻击者通过网络攻击媒介查看敏感信息
此前，Apache Solr 开源企业搜索引擎 (CVE-2024-45216，CVSS 评分：9.8) 中也披露了一个严重漏洞，该漏洞可能为易受攻击实例上的身份验证绕过铺平道路。

GitHub 针对该漏洞的公告指出： “任何 Solr API URL 路径末尾的伪造结尾将允许请求跳过身份验证，同时保持与原始 URL 路径的 API 契约。这个伪造结尾看起来像一个不受保护的 API 路径，但它在身份验证之后但在 API 路由之前在内部被剥离。”

该问题影响 Solr 8.11.4 之前的 5.3.0 版本以及 9.7.0 之前的 9.0.0 版本，已分别在 8.11.4 和 9.7.0 版本中得到修复。

网络安全研究人员披露了一个影响 Microsoft Azure Kubernetes 服务的安全漏洞，如果成功利用该漏洞，攻击者可以提升其权限并访问集群使用的服务的凭据。

谷歌旗下的 Mandiant 表示：“在受影响的 Azure Kubernetes 服务集群内运行的 Pod 中执行命令的攻击者可以下载用于配置集群节点的配置，提取传输层安全性 (TLS) 引导令牌，并执行 TLS 引导攻击来读取集群内的所有机密。 ”

已发现使用“Azure CNI”作为“网络配置”和“Azure”作为“网络策略”的集群受到权限提升错误的影响。微软在负责任的披露后已解决了该问题。

该威胁情报公司设计的攻击技术关键在于访问一个鲜为人知的组件 Azure WireServer，以请求用于加密受保护设置值的密钥（“wireserver.key”），并使用它来解码包含以下几个秘密的配置脚本 -

KUBELET_CLIENT_CONTENT（通用节点 TLS 密钥）
KUBELET_CLIENT_CERT_CONTENT（通用节点 TLS 证书）
KUBELET_CA_CRT（Kubernetes CA 证书）
TLS_BOOTSTRAP_TOKEN（TLS 引导身份验证令牌）
研究人员 Nick McClendon、Daniel McNamara 和 Jacob Paullus 表示：“KUBELET_CLIENT_CONTENT、KUBELET_CLIENT_CERT_CONTENT 和 KUBELET_CA_CRT 可以通过 Base64 解码并写入磁盘，以便与 Kubernetes 命令行工具 kubectl 一起使用来对集群进行身份验证。”

“此帐户在最近部署的 Azure Kubernetes 服务 (AKS) 群集中具有最小的 Kubernetes 权限，但它可以列出群集中的节点。”

另一方面，TLS_BOOTSTRAP_TOKEN 可用于启用TLS 引导攻击，并最终获取正在运行的工作负载所使用的所有机密的访问权限。此攻击不需要 pod 以 root 身份运行。

Mandiant 表示：“采用一种流程来创建限制性网络策略，仅允许访问所需服务，可以阻止整个攻击类别。当服务根本无法访问时，通过未记录的服务进行权限提升就会被阻止。”

在此次披露之际，Kubernetes 安全平台 ARMO 强调了一个新的高严重性 Kubernetes 漏洞（CVE-2024-7646，CVSS 评分：8.8），该漏洞影响 ingress-nginx 控制器，并可能允许恶意行为者未经授权访问敏感集群资源。

安全研究员 Amit Schendel表示：“该漏洞源于 ingress-nginx 验证 Ingress 对象注释方式的一个缺陷。”

“该漏洞允许攻击者将恶意内容注入某些注释，从而绕过预期的验证检查。这可能导致任意命令注入并可能访问 ingress-nginx 控制器的凭据，在默认配置下，该凭据可以访问集群中的所有机密。”

此前，还发现 Kubernetes git-sync 项目存在设计缺陷，该缺陷可能允许在 Amazon Elastic Kubernetes 服务 (EKS)、Azure Kubernetes 服务 (AKS)、Google Kubernetes Engine (GKE) 和 Linode 之间进行命令注入。

Akamai 研究员 Tomer Peled表示： “此设计缺陷可能导致 pod 中任何文件（包括服务帐户令牌）的数据泄露或以 git_sync 用户权限执行命令。要利用此缺陷，攻击者只需在集群上应用 YAML 文件，这是一个低权限操作。”

目前还没有针对该漏洞的补丁，因此各组织必须审核其 git-sync pod 以确定正在运行的命令。

Peled 表示：“这两种攻击方式都是由于缺乏输入清理而导致的，这凸显了对用户输入清理的强大防御需求。蓝队成员应密切关注其组织中 gitsync 用户的异常行为。”