Cybersecurity researchers have discovered a vulnerability affecting Google Kubernetes Engine (GKE) that could be exploited by a threat actor with a Google account to take control of a Kubernetes cluster.
The code name for this serious flaw is System: All Provided by cloud security company Orca. It is estimated that as many as 250,000 active GKE clusters are vulnerable to attack.
In a report shared with The Hacker News, security researcher Ofir Yakobi said that this “stems from a probably common misconception about systems in Google Kubernetes Engine: verified groups only contain verified and deterministic Identity, and in fact, that includes any Google authenticated account (even outside your organization).”
system:authentiated group is a special group that includes all authenticated entities, including human users and service accounts. Therefore, when an administrator inadvertently grants it a role that is too permissive, it can have serious consequences.
Specifically, an external threat actor with a Google account could abuse this misconfiguration by using their own Google OAuth 2.0 bearer token to seize control of the cluster for subsequent exploitation, such as lateral movement, cryptomining Mining, denial of service and attacks. Sensitive information was stolen.
Worse, this method leaves no trace that can be linked back to the actual Gmail or Google Workspace account from which the OAuth bearer token was obtained.
Sys:All has been found to affect numerous organizations, resulting in the exposure of various sensitive materials such as JWT tokens, GCP API keys, AWS keys, Google OAuth credentials, private keys, and container registry credentials, the last of which may then be used Trojanize the container image.
Following responsible disclosure to Google, the company has taken steps to prevent the system:authentiated group from being bound to the cluster-admin role in GKE 1.28 and later.
“To help protect your cluster from large-scale malware attacks that exploit misconfigured cluster administrator access, GKE clusters running version 1.28 and later do not allow you to bind the cluster administrator ClusterRole to the system:anonymous user or system:unauthenticated or system:authenticatedgroups,” Google now states in its documentation.
Google also recommends that users not bind the system:authentiated group to any RBAC role and use ClusterRoleBindings and RoleBindings to evaluate whether the cluster is bound to the group and remove unsafe bindings.
Orca also warns that while there are no public records of large-scale attacks utilizing this method, it may only be a matter of time, so users need to take appropriate steps to protect their cluster access controls.
“While this is an improvement, it’s worth noting that this still leaves a number of additional roles and permissions that can be assigned to this group,” the company said.
