‘Significant security loophole’ found in Google software container system

Google has fixed a loophole affecting an important cloud service after researchers discovered numerous organizations — including a publicly traded company — had systems vulnerable to systemwide security breaches as a result of the issue.

The issue affected Google Kubernetes Engine (GKE), a system used to deploy, scale and manage how applications are “containerized.” GKE — the tech giant’s implementation of the open-source Kubernetes project — is used widely in healthcare, education, retail and financial services for data processing as well as artificial intelligence and machine learning operations.

Researchers from Orca Security explained that they uncovered an issue in GKE that “could allow an attacker with any Google account to take over a misconfigured Kubernetes cluster, potentially leading to serious security incidents such as cryptomining, denial of service, and sensitive data theft.”

The issue revolves around permissions, with GKE allowing users access to the system with any valid Google account. Orca Security said this creates a “significant security loophole when administrators decide to bind this group with overly permissive roles.” The researchers are calling the loophole Sys:All.

Orca Security said it conducted scans and found over 1,300 clusters potentially exposed. More than 100 of them are exposed enough to allow for widespread access.

“Kubernetes connects its hosted containerized apps with various different types of critical data assets such as databases, code repositories and other 3rd-party vendors, which makes it a devastating tool at the hands of a malicious actor,” they noted.

Containerization gives developers flexibility with how they build and deploy software, by bundling an app’s code with everything else it needs — such as files and libraries — to run on any computing infrastructure.

An open door

At least one of the exposed clusters belonged to a Nasdaq-listed company, Orca Security said, and the exposure would have given hackers access to Amazon Web Services credentials enabling even deeper access to the company’s systems and data. A malicious actor “could potentially access these systems, extract or manipulate sensitive data, disrupt services, or even move further into the network.” the researchers said.

Orca Security said it reported the issue to the company and worked with it to resolve the vulnerabilities, which involved tightening the permissions, securing exposed cloud buckets and more.

The researchers reported exposure to several other owners that they found were vulnerable, adding that in general, organizations “should always aim for granularity in the realm of identity and access, so they don’t give permissive access to entities that don't need it.”

They also reported the issue to Google, which told them that it recognizes the severity of the issue and has “been proactive with prevention measures and customer notifications, and continues to take action to ensure customers’ safety.”

A Google spokesperson confirmed to Recorded Future News that it worked with Orca Security. The tech giant also released a security bulletin last week “for the limited number of impacted GKE users detailing the steps they should take to protect themselves from any accidental authorization,” the spokesperson noted.

Google also sent the bulletin in direct messages to some customers.

“We have identified several clusters where users have granted Kubernetes privileges to the system:authenticated group, which includes all users with a Google account. These types of bindings are not recommended, as they violate the principle of least privilege and grant access to very large groups of users,” Google said in the advisory issued on January 19.

Orca Security noted that Google considers this to be “intended behavior” because in the end, this is an assigned permission vulnerability that can be prevented by the user. Customers are responsible for the access controls they configure.

The researchers backed Google’s assessment that organizations should “take responsibility and not deploy their assets and permissions in a way that carries security risks and vulnerabilities.”