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 a report shared with The Hacker News, security researcher Roi Nisimi 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.

In a separate security bulletin, Google Cloud said granting Kubernetes privileges to the system:authenticated group violate the principle of least privilege and grant access to very large groups of users.

The company also said it has “built detection rules into Event Threat Detection (GKE_CONTROL_PLANE_CREATE_SENSITIVE_BINDING) as part of Security Command Center” and that it has “built configurable prevention rules into Policy Controller with K8sRestrictRoleBindings.”

Last but not least, email notifications have been sent to all GKE users with bindings to these users/groups, asking them to review their configuration.

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 any 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 [Google’s changes] are improvements, it still leaves many other roles and permissions (other than cluster-admin) that can be assigned to the system:authenticated group, so organizations must make sure that the system:authenticated group is not overprivileged,” Nisimi emphasized.

NOTE:: This article is copyright by thehackernews.com and we are using it for educational or Information purpose only

 Best Cyber Security Products & Solutions