您现在的位置是：首页 >技术交流 >有史以来第一次利用 Kubernetes RBAC 攻击后门集群网站首页技术交流

我们最近发现了有史以来第一个证据，表明攻击者正在野外利用 Kubernetes (K8s) 基于角色的访问控制 (RBAC) 创建后门。

攻击者还部署了 DaemonSets 来接管和劫持他们攻击的 K8s 集群的资源。我们的研究表明，该活动正在积极针对至少 60 个野外集群。  

这篇博文是我们对野外错误配置的 K8s 集群进行的全面研究的一部分。我们的研究结果意义重大，因为它们揭示了错误配置的风险，以及即使是大型组织也可能忽视保护其集群的重要性，从而使他们容易因一个错误而遭受潜在的灾难。 

攻击

我们记录并分析了对我们的一个 K8s 蜜罐的攻击，该蜜罐利用 RBAC 系统获得持久性。攻击者使用 DaemonSets 部署容器来运行门罗币挖矿程序。 

初始访问是通过错误配置的 API 服务器获得的，该服务器允许来自具有特权的匿名用户的未经身份验证的请求。攻击者发送了几个 HTTP 请求来列出秘密，然后发出两个 API 请求以通过列出“ kube-system”命名空间中的实体来获取有关集群的信息。接下来，攻击者通过查找名为“kube-controller”的部署来检查攻击是否已经部署在这个特定的集群上。 

攻击者还试图删除各种命名空间中的一些现有部署，包括“kube-secure-fhgxtsjh”、“kube-secure-fhgxt”、“api-proxy”和“worker-deployment”。我们假设攻击者正在禁用遗留活动或竞争对手的活动以增加可用的 CPU 并减少在服务器耗尽时被发现的机会。 

这次攻击最有趣的部分是攻击者使用 RBAC 获得持久性。攻击者创建了一个具有接近管理员级别权限的新 ClusterRole。因为它是一个集群角色，所以它没有绑定到特定的命名空间。

接下来，攻击者在“kube-system”命名空间中创建了“ServiceAccount ”、“kube-controller ” 。最后，攻击者创建了一个“ClusterRoleBinding”，将 ClusterRole 与 ServiceAccount 绑定以创建强大且不显眼的持久性。  

图 1：攻击者创建的具有类似管理员权限的 ClusterRole  

此时，即使匿名用户访问被禁用，攻击者也会创建允许进一步利用集群的持久性。此外，虽然将“cluster-admin”角色绑定到新用户或可疑用户可能会触发警报，但攻击者创造了一种巧妙的方式来很好地融入 API 审计日志。最终，通过设置这个看起来合法的 ClusterRoleBinding 'system:controller:kube-controller'，攻击者可以在不引起任何警报的情况下潜伏在雷达之下。 

作为我们环境的一部分，我们在集群的不同位置公开了 AWS 访问密钥。当天晚些时候，我们收到了一个信标，表明攻击者使用访问密钥来尝试进一步访问目标的云服务提供商帐户，并利用攻击窃取更多资源、数据并脱离特定范围k8s集群。 

然后，攻击者创建了一个 DaemonSet，通过单个 API 请求在所有节点上部署容器。DaemonSet 创建请求对象包含容器镜像'kuberntesio/kube-controller:1.0.1'，托管在公共注册表 Docker Hub 上。对集群的影响是资源劫持。 

在 Docker Hub 上查看容器镜像“kuberntesio/kube-controller:1.0.1”时，我们发现该容器自五个月前上传以来被拉取了 14,399 次，表明该活动范围广泛。我们发现了另外 60 个暴露的 K8s 集群，这些集群具有该攻击者主动攻击的证据——这证明了该活动的规模。 

容器“kuberntesio/kube-controller”有 3 个标签，我们分析了所有标签。在每个容器镜像中，我们发现了二进制 kube-controller (MD5= 2833c82055bf2d29c65cd9cf6684449a)，在 VirusTotal 中被检测为加密矿工。

我们还在每个容器镜像上找到了配置文件。钱包地址表明攻击者已经开采了 5 个 XMR，按照这种开采速度，他们每年可以从一个工人那里再获得 5 个（200 美元）。 

名为“kuberntesio/kube-controller”的容器镜像是一个冒充合法“kubernetesio”帐户的域名仿冒案例。尽管只有几十个容器镜像，但它已经积累了数百万次拉取。该图像还模仿了流行的“kube-controller-manager”容器镜像，它是控制平面的关键组件，运行在每个主节点上的 Pod 中，负责检测和响应节点故障。

从本质上讲，它是一个广泛使用的 K8s 组件，应该存在于集群上，并且可能会欺骗从业者认为它是一个合法的部署而不是一个 cryptominer。由于它被设计为连续运行，因此没有人会质疑它的存在。 

将攻击映射到 Kubernetes 的 Microsoft 威胁矩阵

作为最佳实践，我们的团队通常将攻击的组件映射到 MITRE ATT&CK 框架的相应技术。然而，在这种情况下，MITRE 尚未发布针对 Kubernetes 集群的攻击框架。我们利用了微软创建的威胁矩阵，并添加了一些新的建议： 

我们将这种攻击命名为 RBAC Buster 一种新的 K8s 攻击，旨在利用 K8s API 服务器创建 ClusterRoleBinding 并在错误配置修复后获得对集群的持久性完全访问权限。  

使用更新的 Kubernetes 威胁矩阵保护容器化环境

https://www.microsoft.com/en-us/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/

MITRE ATT&CK ®是一个全球可访问的基于真实世界观察的对手战术和技术的知识库。

ATT&CK 知识库被用作私营部门、政府以及网络安全产品和服务社区开发特定威胁模型和方法的基础。

随着 ATT&CK 的创建，MITRE 正在履行其使命，即通过将社区聚集在一起以开发更有效的网络安全来解决问题，创造一个更安全的世界。ATT&CK 是开放的，任何人或组织都可以免费使用。

https://attack.mitre.org/