Headline
Google Kubernetes Misconfig Lets Any Gmail Account Control Your Clusters
Cybersecurity researchers have discovered a loophole impacting Google Kubernetes Engine (GKE) that could be potentially exploited by threat actors with a Google account to take control of a Kubernetes cluster. The critical shortcoming has been codenamed Sys:All by cloud security firm Orca. As many as 250,000 active GKE clusters in the wild are estimated to be susceptible to the attack vector. In
Cloud Security / Kubernetes
Cybersecurity researchers have discovered a loophole impacting Google Kubernetes Engine (GKE) that could be potentially exploited by threat actors with a Google account to take control of a Kubernetes cluster.
The critical shortcoming has been codenamed Sys:All by cloud security firm Orca. As many as 250,000 active GKE clusters in the wild are estimated to be susceptible to the attack vector.
In a report shared with The Hacker News, security researcher Ofir Yakobi said it “stems from a likely widespread misconception that the system:authenticated group in Google Kubernetes Engine includes only verified and deterministic identities, whereas in fact, it includes any Google authenticated account (even outside the organization).”
The system:authenticated group is a special group that includes all authenticated entities, counting human users and service accounts. As a result, this could have serious consequences when administrators inadvertently bestow it with overly permissive roles.
Specifically, an external threat actor in possession of a Google account could misuse this misconfiguration by using their own Google OAuth 2.0 bearer token to seize control of the cluster for follow-on exploitation such as lateral movement, cryptomining, denial-of-service, and sensitive data theft.
To make matters worse, this approach does not leave a trail in a manner that can be linked back to the actual Gmail or Google Workspace account that obtained the OAuth bearer token.
Sys:All has been found to impact numerous organizations, leading to the exposure of various sensitive data, such as JWT tokens, GCP API keys, AWS keys, Google OAuth credentials, private keys, and credentials to container registries, the last of which could then be used to trojanize container images.
Following responsible disclosure to Google, the company has taken steps to block the binding of the system:authenticated group to the cluster-admin role in GKE versions 1.28 and later.
“To help secure your clusters against mass malware attacks that exploit cluster-admin access misconfigurations, GKE clusters running version 1.28 and later won’t allow you to bind the cluster-admin ClusterRole to the system:anonymous user or to the system:unauthenticated or system:authenticated groups,” Google now notes in its documentation.
Google is also recommending users to not bind the system:authenticated group to any RBAC roles, as well as assess whether the clusters have been bound to the group using both ClusterRoleBindings and RoleBindings and remove unsafe bindings.
Orca has also warned that while there is no public record of a large-scale attack utilizing this method, it could be only a matter of time, necessitating that users take appropriate steps to secure their cluster access controls.
“Even though this is an improvement, it is important to note that this still leaves many other roles and permissions that can be assigned to the group,” the company said.
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.