Cybersecurity researchers have uncovered a critical vulnerability affecting Google Kubernetes Engine (GKE), dubbed Sys:All, which could potentially be exploited by threat actors possessing a Google account to gain control over vulnerable Kubernetes clusters. This loophole, identified by cloud security firm Orca, is believed to impact around 250,000 active GKE clusters in the wild. The flaw arises from a misconception regarding the system:authenticated group in GKE, mistakenly thought to include only verified and deterministic identities. In reality, it encompasses any Google-authenticated account, even those outside the organization, leading to serious consequences if given overly permissive roles.
The security researcher, Ofir Yakobi, highlights that external threat actors, armed with a Google account, could misuse this misconfiguration by employing their Google OAuth 2.0 bearer token. This unauthorized access could result in various malicious activities, including lateral movement, cryptomining, denial-of-service attacks, and theft of sensitive data. Notably, the exploitation doesn’t leave a trace linking back to the actual Gmail or Google Workspace account that obtained the OAuth bearer token. The impact of Sys:All extends to numerous organizations, exposing sensitive data such as JWT tokens, GCP API keys, AWS keys, Google OAuth credentials, private keys, and credentials to container registries.
In response to responsible disclosure, Google has taken measures to mitigate the risk, blocking the binding of the system:authenticated group to the cluster-admin role in GKE versions 1.28 and later. The company emphasizes the importance of not binding the system:authenticated group to any RBAC roles and advises users to review and remove unsafe bindings. Additionally, Google has implemented detection rules and prevention measures within its Security Command Center and Policy Controller to enhance cluster security. Despite these improvements, security researchers caution that organizations must ensure the system:authenticated group is not overprivileged, as potential risks remain beyond the cluster-admin role. Orca underscores the urgency for users to take appropriate steps in securing their cluster access controls, emphasizing the potential for large-scale attacks utilizing this method in the future.
