Kubernetes是什么？不安全的Kubernetes将被利用!

执行摘要

在2020年10月至2021年2月之间，第42单元的研究人员定期扫描和分析Internet上不安全的Kubernetes（也称为k8s）集群。可以并且应该配置Kubernetes群集以提高安全性，但是如果不加保护，则知道其IP，端口和API的任何人都可以匿名访问这些群集。研究人员确定了2,100个不安全的Kubernetes集群，这些集群由5,300个节点，31,340个CPU和75,270个Pod组成。在由电子商务，金融和医疗保健等行业的组织运营的这些不安全集群中，看到了各种各样的应用程序运行。应用程序中大量的计算资源和大量敏感数据，例如API令牌，数据库凭据，源代码和个人身份信息（PII）–使这些不安全的集群成为攻击者的诱人目标。研究人员遇到的最大集群具有500多个节点和2,000个活动吊舱。

第42单元在其中一些不安全的Kubernetes集群中发现了恶意软件和恶意活动。尽管我们观察到的大多数恶意代码都以容器的形式在Pod中运行，但有些却直接部署在主机上。每个容器化的应用程序都在一个隔离的工作空间（名称空间）中运行，该工作空间具有与所有其他应用程序不同的进程ID，网络和文件系统。如果恶意软件绕过隔离并访问底层主机的资源，则也对托管群集的云环境构成风险。通过这种访问级别，研究人员证明了更多的横向或纵向移动是可能的，包括提取凭据，破坏注册表以及访问主机的数据和网络。

不安全的Kubernetes API服务器和不安全的Docker守护程序有很多共同点。如果配置错误，攻击者可以利用在此处运行的公开API来控制整个容器平台。我们之前的研究确定了不安全的Docker守护程序中的许多恶意活动（例如Graboid，Cetus和Pro-Ocean）。有趣的是，尽管我们进行了类似的研究，但在Kubernetes中，我们没有看到像Docker那样多的恶意活动。

尽管在不安全的Kubernetes集群中恶意活动的程度似乎较低，但是在那里运行的攻击者仍可以访问更有价值的目标。由于受到威胁的Kubernetes集群可以拥有更多的资源（CPU，内存和网络）和应用程序数据，因此有能力的攻击者可以轻松地托管命令和控制（C2）服务器，构建僵尸网络或窃取敏感数据。我们相信很快就会有更多的攻击者瞄准或利用不安全的Kubernetes。

运行Prisma Cloud或CN系列的Palo Alto Networks客户可以免受这种威胁。Prisma Cloud的Kubernetes Benchmark和Runtime Defense可以针对不安全的配置发出警报，并检测诸如加密劫持之类的恶意活动。CN系列提供了完整的L7可见性，可以有效地检测和隔离带有恶意流量的容器。
图1.在公开的Kubernetes集群中标识的容器，映像，机密和部署的数量。

错误配置的Kubernetes组件

Kubernetes是一个高度复杂的平台，由多个层和组件组成。模块化设计使Kubernetes灵活且可扩展，因为大多数组件都可以单独配置或交换以满足特定目标。但是，复杂性也使正确保护平台具有挑战性。一个错误的配置可能导致容器受损，甚至群集受损，如下一节所示。

这篇文章研究了两个Kubernetes组件，kube-apiserver（API服务器）和kubelet。两者都作为RESTful API服务器运行，并接受管理基础容器的请求。我们专注于这两个组件，因为它们存在于所有Kubernetes平台中，如果配置不当，可能会导致主机受损。我们分析了无需身份验证即可访问的Internet上的kube-apiserver和kubelet。

Kube-apiserver是Kubernetes集群的前端，该集群接收来自客户端的RESTful请求并将请求转换为对容器，pod或节点的操作。Kubernetes允许客户端使用客户端证书，承载令牌等进行身份验证。匿名客户端可能无法访问API服务器，具体取决于配置。有时，管理员可能会向匿名用户公开API的子集，以便所有应用程序都可以从中读取特定数据。当前的Kubernetes实现默认情况下允许未经身份验证的用户访问受限的API信息。

所有kube-apiserver的API在其API参考中都有详细说明。图2显示了使用curl将请求发送到API服务器的示例，图3使用Kubernetes社区维护的命令行工具kubectl发出了相同的请求。请注意，默认情况下，示例中显示的API不会对匿名用户开放。为了进行演示，我们将更多权限绑定到匿名用户。
图2.使用curl匿名访问kube-apiserver。
图3.使用kubectl匿名访问kube-apiserver。请注意，kubectl需要一个虚拟的用户名和密码来发送匿名请求。

Kubelet是在Kubernetes集群中每个节点上运行的代理。它接收来自各种组件（主要是kube-apiserver）的RESTful请求，并执行Pod级操作。客户端可以使用客户端证书或不记名令牌向Kubelet进行身份验证。与API服务器类似，Kubelet可以接受也可以不接受未经身份验证的请求，具体取决于配置。当前的Kubernetes实现默认情况下允许匿名访问Kubelet。

尽管Kubelet没有正式的API参考页，但可以在源代码中找到其API 。开源项目kubeletctl还详细介绍了所有Kubelet的API。在图4中，我们使用curl将两个请求发送到Kubelet服务器，在图5中，我们使用kubeletctl发出相同的请求。

图4.使用curl匿名访问kubelet服务器。
图5.使用kubeletctl匿名访问kubelet服务器。

误配置的Kubernetes集群一览

在2020年10月至2021年2月之间，我们确定了Internet上公开的6,400个API服务器和1,030个Kubelet。在这些服务器中，我们发现了47,030个容器，47,115个图像和83,902个密钥，如图1所示。

图6-9概述了这些Kubernetes集群中标识的位置，服务提供商，泄漏的API和版本。图6显示50％的公开服务器在中国，而18.2％在美国。

图6.全球范围内暴露的Kubernetes集群。

图7显示了大约65％的不安全服务器托管在公共云中。39％的服务器托管在中国的云服务提供商（CSP）中，其次是25.9％的美国云服务提供商。这些结果与国家/地区分布一致，在该国家/地区中，有68％的公开服务器托管在中国或美国。

图7.公共云服务提供商中暴露的Kubernetes集群。

图8显示了可以匿名访问的API。我们观察到不同的服务器公开了不同的API集。例如，有18.3％的公开API服务器允许匿名访问/ api / v1 / node，但是只有13.6％的公开API服务器允许匿名访问/ api / apps / v1 / deployments。无论如何，获得对这些API的任何访问都可能泄漏敏感的应用程序或平台信息。

图8.允许匿名/未经身份验证的访问的API。

图9显示了所识别的Kubernetes集群的版本-v1.12，v1.13和v1.16是最常见的版本，占部署的50％。该数字表示50％的群集两年以上没有更新。在撰写本文时，v1.9是可用的最新版本，仅占部署的2.2％。

图9.公开的Kubernetes集群的版本。

不安全的Kubernetes集群中的恶意活动

不安全的Kubernetes集群容易受到各种攻击。其中，加密劫持仍然是最常见的攻击，其中攻击者在受感染的容器中部署恶意加密矿工。我们观察到的加密劫持恶意软件要么作为新容器部署，要么在被劫持的容器中启动。一旦访问了容器，一些恶意软件还会尝试横向或垂直移动。横向移动使攻击者可以控制更多的容器或应用程序，而横向移动使攻击者可以控制主机或什至部署了群集的云环境。

部署恶意容器

部署包含恶意软件的容器映像是在容器平台上发起攻击的一种常见方法。由于容器通常与操作系统（OS）无关，因此容器化的恶意软件可以在任何环境中轻松运行。Docker Hub和Quay等公共容器注册中心还简化了恶意容器的托管和交付。先前的研究发现了Docker Hub中的大量恶意映像（请参阅先前的研究，以在Docker Hub中找到恶意的密码劫持映像；攻击者在不安全的Docker Daemon中使用的策略，技术和过程；以及使用Docker映像来挖掘Monero）。

但是，良性容器映像也可能出于恶意目的而被滥用。合法的容器映像（例如Ubuntu或Centos）可以部署在未经授权的环境中，该环境专门用于运行恶意软件。默认情况下，大多数容器平台都信任这些官方映像。表1显示了三种利用官方Docker Hub映像构建和部署恶意软件的攻击。在数百个不安全的Kubernetes集群中观察到了每种攻击。
图10.不安全的Kubernetes中的Cryptojacking容器。

Docker Hub中发布了许多合法的加密货币挖掘工具。加密爱好者经常运行这些容器来参与采矿网络。但是，相同的图像也可能被滥用。表2显示了攻击者如何使用Monero挖掘工具XMRig执行加密劫持操作。该映像已部署为DaemonSet，这样，每个工作节点都将至少运行一个容器实例，并且如果节点加入或离开集群，则会自动重新安排Pod的时间。为了掩饰恶意进程，攻击者将DaemonSet命名为“ Kube-controller”，并将其部署在kube-system名称空间中。kube-system名称空间通常仅用于Kubernetes系统创建的对象。管理员检查正在运行的Pod和守护程序时，由于名称混淆，可以轻易忽略此恶意容器。

图11.密码劫持容器的配置。

在被劫持的容器中启动恶意进程

可以通过不安全的API服务器或Kubelet在正在运行的容器中执行远程代码执行（RCE）。API服务器的exec API和Kubelet的run API允许对手在容器中运行任意命令。在被劫持的容器中启动恶意进程更加隐蔽，因为它不需要提取新映像或运行新容器。容器漏洞扫描程序或静态分析工具无法检测到此类攻击。

在最近的研究中，Unit 42研究人员发现了一种名为Hildegard的加密劫持恶意软件，该恶意软件针对的是错误配置的Kubernetes集群。攻击者通过面向互联网且不安全的Kubelet破坏了第一个容器。然后，它横向移动到集群内的其他节点，并劫持了多个容器。在每个受感染的容器中，恶意软件都试图建立一个返回C2服务器的IRC通道，并启动了一个恶意的cryptominer。但是，注入到运行中的容器中的恶意矿工的寿命很短，因为容器可以频繁地重新启动或重新安排。主机容器重新启动后，恶意矿工将无法生存。

针对不安全的Kubernetes的潜在攻击

在前面的部分中，我们展示了在不安全的Kubernetes集群中的发现。本节将介绍在这种不安全的环境中也可能发生的一些潜在攻击。我们首先为每种可能的攻击定义初始访问权限，并说明攻击者如何利用初始访问权限。

过于宽容的能力。根据应用程序的要求，每个容器都被授予功能的子集。例如，如果应用程序需要绑定到特权端口（端口号低于1024），则需要为其授予cap_net_bind_service功能，并且如果应用程序需要发送ICMP数据包，则需要cap_net_raw功能。诸如cap_sys_module或cap_sys_admin之类的功能可授予高度特权，并允许容器访问主机的内核模块。如果具有这些功能的容器遭到破坏，攻击者可以轻松获得对主机的访问权限。
共享名称空间。容器化的应用程序可以在沙盒环境中运行，因为容器的每个资源（例如进程，网络和文件系统）都放置在隔离的名称空间中。在某些情况下，容器可能需要与其他容器或主机共享其名称空间。例如，如果容器需要捕获主机的网络流量，则它需要在主机的网络名称空间中运行。这个共享的名称空间为攻击者提供了一个通道，使攻击者可以从容器移动到主机。
未修补的漏洞。未打补丁的容器运行时或节点OS会引起容器崩溃的风险。容器化的应用程序是由容器运行时调度和管理的。容器运行时中的漏洞，例如CVE-2019-5736，可能允许应用程序破坏容器。由于容器共享主机的OS内核，因此大多数内核利用可能导致特权升级并允许容器突破。
服务帐户令牌被盗。服务帐户令牌驻留在容器中，应用程序使用它们来向API服务器进行身份验证。如果被盗，攻击者可以假冒应用程序并利用API服务器横向或纵向移动。
云帐户凭据被盗。攻击者可能会通过受到破坏的应用程序或容器来访问云凭据，如Hildegard的研究所述。有了云凭据，攻击者就可以访问托管Kubernetes集群的云环境，从而导致更严重的破坏。

保护与缓解

可以使用严格的安全策略来防止上述所有问题，包括：

经常打补丁
可以利用已知漏洞进行初始访问或特权升级。应定期扫描应用程序和容器平台并经常打补丁。
保护网络。
切勿将任何Kubernetes组件（例如API服务器，Kubelet或etcd）暴露给互联网。防火墙规则应仅允许一小部分IP与这些组件进行通信。
在每个支持mTLS的Kubernetes组件上实施相互TLS（mTLS）。
实施网络安全策略以限制Pod，Pod可以与之通信的IP块。
保护身份
实施基于角色的访问控制（RBAC）并实践最低特权原则。向每个角色授予绝对需要的权限。
任何组件都不应接受或响应匿名/未经身份验证的请求。
定期轮换凭证和证书，以减轻潜在的凭证泄漏。

结论

在2020年10月至2021年2月之间，第42单元的研究人员发现了从Internet上不安全的Kubernetes集群泄漏的大量敏感数据。泄漏的数据包括API令牌，数据库凭据，源代码和PII。尽管我们没有看到任何大规模或复杂的攻击，但是在过去的五个月中，我们发现了机会攻击的趋势在增加。随着这些Kubernetes集群中容器技术的迅速采用和丰富的计算资源，我们相信更多的对手很快就会将他们的注意力转向这个未开发的空间。无论如何，简单的最佳实践和连续监视可以有效地预防和检测大多数这些机会主义攻击。凭借Kubernetes技术的复杂性和动态性，

运行时保护和Cryptominer检测功能以及Prisma Cloud Compute Kubernetes Compliance Protection可以保护运行Prisma Cloud的Palo Alto Networks客户免受此威胁，后者会在Kubernetes配置不足时发出警报，并提供安全的替代方案。Prisma Cloud Compute的漏洞扫描程序可以警告容器内的应用程序漏洞和主机上的平台/操作系统漏洞。