在我们发现了谷歌Kubernetes引擎（GKE）中的一个严重漏洞Sys：All后，我们决定对这个漏洞在现实世界中的影响进行研究。我们最初的探测就已经发现了超过一千个易受攻击的GKE集群，原因是管理员在配置RBAC绑定时，使得system:authenticated组特权过大，这可能允许任何谷歌账户持有者访问和控制这些集群。

与其他云服务提供商（CSP）如AWS和Azure提供的主要Kubernetes服务不同，GKE默认使用标准IAM进行集群身份验证和授权。这种方法允许使用任何谷歌凭据对Kubernetes API服务器进行一定程度的访问，因此将所有谷歌用户（包括组织之外的用户）纳入GKE的system:authenticated组。由于这个组的范围很容易被误解，管理员可能会无意中分配过多的权限，从而使GKE集群暴露在外。

在本文中，我们将深入探讨这个漏洞实际上影响有多大。通过对公开可用的GKE集群进行一系列扫描，我们发现了一系列的数据泄露，这对许多组织产生了现实实际的影响。我们将讨论这些泄露的性质，以及可能被泄露的敏感信息范围。我们将展示实际的利用路径，并为保护GKE集群免受这些威胁提供实用建议。

执行摘要:

• 我们发现了众多组织在他们的system:authenticated组配置中存在显著的错误，这使得他们容易受到Orca发现的Sys:All漏洞的影响。
• 这些错误配置导致了各种敏感数据类型的泄露，包括JWT令牌、GCP API密钥、AWS密钥、谷歌OAuth凭据和私钥。
• 一个值得注意的例子是一家上市公司，因为这种错误配置导致大规模的未经授权的访问，可能导致全系统安全漏洞。
• 这项研究强调了在云环境中迫切需要严格的安全协议，以防止类似事件的发生。
• 关于攻击者如何滥用这个GKE安全漏洞的威胁简报，以及如何保护你的集群的建议，将在1月26日上午11点太平洋时间举行。

我们从检查在已知CIDR范围的集群，评估有多少GKE集群暴露在Sys:All漏洞中开始研究。特别是分配给system:authenticated组的自定义角色的集群。我们的扫描识别出由于这些自定义角色分配而存在不同程度暴露的一千多个集群。

为了探测这些集群，我们开发了一个Python脚本，该脚本利用通用的谷歌认证令牌（通过OAuth 2.0 Playground获得），该令牌对任何谷歌用户都是可访问的。该脚本通过Kubernetes API与这些集群进行交互，用来提取大量可能敏感的信息。我们目标数据包括配置映射（configmaps）、Kubernetes secrets、服务账户详情以及其他关键操作数据。此外，我们尝试将这些集群与它们各自的组织关联起来，从而揭示这些错误配置及其所有者的更广影响。

然后，我们对检索到的数据进行secret检测，以识别和匹配已知的秘密模式和正则表达式，这可能允许之后在组织环境中进行横向移动。

这部分对于理解这些安全配置错误的实际影响至关重要，特别是在潜在的未经授权实体利用的背景下。通过这次全面的技术检查，我们对这些GKE集群中安全短板的普遍性和严重性有了更深入的了解。

我们的调查发现了一个令人震惊的情况，一家纳斯达克上市公司的GKE集群可以被利用。在system:authenticated组中的一个看似无害的错误配置，有着深远的影响，如允许列出和从公司的容器注册表中拉取镜像，并提供对存储在集群的configmap中的AWS凭据的公开访问（以及其他发现的敏感数据）。有了这些凭据，我们获得了对包含多个敏感信息和日志的S3存储桶的访问，在进一步分析后，发现了系统管理员凭据和多个有价值的端点，包括RabbitMQ、Elastic、认证服务器和内部系统——所有这些都具有管理员访问权限。

以下是这一错误配置使我们能够在公司的数字基础设施内横向移动的逐步说明：
 

错误配置的GKE集群允许将集群管理员权限授予system:authenticated组，允许我们（使用任何谷歌用户账户）使用Kubernetes API查询多个有价值的资源，包括ConfigMap资源，并对其进行挖掘。

值得注意的是，谷歌在较新的GKE版本（1.28及以上）中阻止了将system:authenticated组绑定到cluster-admin角色。我们想强调的是，尽管这是一个改进，但它仍然留下许多其他角色和权限（除了cluster-admin之外）可以分配给system:authenticated组。

在我们发现的一个bash脚本中嵌入了一个具有高S3权限的AWS访问密钥和Secret。这严重违法了安全实践，会导致了多个凭据和敏感数据的泄露。

使用泄露的AWS凭据，我们可以列出并下载多个S3存储桶的内容。其中包括包含详细操作数据的日志文件。

在负责任地向受影响的公司披露了这些发现后，我们与他们合作解决了这些漏洞。包括加强IAM角色和权限，保护S3存储桶，并围绕ConfigMaps实施更好的实践。由于这些Secret是作为Kubernetes configmaps的一部分嵌入在bash脚本中的，我们建议并协助建立更好的实践。包括从脚本中移除敏感数据，使用更安全的方法来管理Secret，并确保configmaps对未经授权的用户不可见。

通过解决这些领域，该公司能够显著降低未来类似漏洞的风险，增强其云基础设施的整体安全性。

在我们对GKE集群进行的更大范围的通用评估后，我们发现多个组织存在各种敏感数据泄露，凸显了这些问题的广泛性：

• GCP API密钥和服务账户JSON的泄露：我们经常发现GCP API密钥和服务账户认证JSON文件被暴露。这些对于访问GCP资源至关重要，它们的泄露代表了重大的安全威胁。
• 私钥的发现：我们的扫描还发现了这些集群中的私钥。这些密钥对于确保通信和数据访问的安全至关重要，它们的泄露是一个重大的安全风险
• 访问容器注册表：我们发现了许多情况下，各种容器注册表的凭据都是可访问的。这使我们能够本地拉取和运行容器镜像，这种能力可能被滥用，将恶意内容引入容器化应用程序。

在可能的情况下，我们通知了易受攻击的GKE集群的所有者，但并不总是能够识别集群的所有者。因此，我们敦促组织遵循下面提到的建议。

我们研究的累积发现描绘了一个令人担忧的画面，即云环境中安全漏洞的普遍性。从重要访问密钥到运维数据和基础设施疏忽，暴露的数据的多样性和深度强调了在云环境中迫切需要强有力的安全措施和持续监控。

这是现实世界中严格安全配置重要性的证明。对于GKE用户来说，至关重要的是审查集群权限，特别是如system:authenticated这样的默认组。组织必须确保只授予必要的权限，并遵循最小权限原则（PolP），并进行定期审计，以防止此类疏忽。

谷歌已经在较新的GKE版本（版本1.28及以上）中阻止了将system:authenticated组绑定到cluster-admin角色。然而，重要的是要注意，这仍然留下了许多其他可以分配给该组的角色和权限。这意味着除了升级到GKE版本1.28或更高之外，阻止这一攻击向量的主要方法是严格遵循最小权限原则。