A newly discovered vulnerability in Google Cloud Build enables attackers to tamper with and inject malware into images stored in Artifact Registry, Google’s repository for hosting software artifacts such as packages and container images.
Any applications then making use of those compromised container images risk malware infections, denial-of-service attacks, data theft, and other negative impacts.
The Bad.Build Issue
Researchers at Orca Security recently discovered the flaw, which they dubbed Bad.Build, when analyzing an application programming interface (API) call request associated with a Google cloud platform resource. They reported the issue to Google, which investigated the problem and issued a fix for it in June.
However, Orca, in a report this week, described the fix as insufficient and only partially addressing the vulnerability.
“The flaw presents a significant supply chain risk since it allows attackers to maliciously tamper with application images, which can then infect users and customers when they install the application,” Orca cloud threat researcher Roi Nisimi said. “As we have seen with the SolarWinds and recent 3CX and MOVEit supply chain attacks, this can have far reaching consequences.”
According to Orca, the Bad.Build flaw really is a design issue and has to do with the default permissions associated with the Google Cloud Build service. The excessive permissions associated with the service give adversaries a relatively easy way to access audit logs that contain a complete list of permissions associated with all GCP accounts in a Google Cloud Build “Project.”
“What makes this information so lucrative is that it greatly facilitates lateral movement and privilege escalation in the environment,” Nisimi said. “Knowing which GCP account can perform which action is equal to solving a great piece of the puzzle on how to launch an attack.”
Orca’s researchers discovered that by using a GCP account with the permission to create a new build (cloudbuild.builds.create), they could relatively easily impersonate the Cloud Build Service account and view all Project permissions. “An attacker would need to have access to the cloudbuild.builds.create permission, which could either be obtained through insider access or by an outsider that has gained unauthorized access to a user with this permission,” says Nisimi, in comments to Dark Reading.
Simple to Exploit
“They would need to execute just three lines of code to build a public Gcloud image on the Cloud Build servers and run the commands as shown in our proof of concept to escalate the user’s privileges and execute any action that the Cloud Build Service Account is allowed to perform,” he says.
Google’s fix for Bad.Build removes the logging permission from the default Google Cloud Build service role, which means that particular service no longer has access to the audit logs which list the entire Project’s permissions each time there’s a change, Nisimi notes.
However, there is a whole list of other roles with the cloudbuild.builds.create permission that can do the same thing. Any user with the cloudbuild.builds.create permission can escalate privileges and execute a wide range of actions — including manipulating images and injecting malicious code into them — unless organizations specifically revoke the default permissions of the Google Cloud Build service, he says.
A Google spokeswoman had little to say about the flaw or the claims of a partial fix. “We appreciate the work of the researchers and have incorporated a fix based on their report as outlined in a security bulletin issued in early June,” she said.
Limiting Privileges
When users enable the Cloud Build API in a project, Cloud Build automatically creates a default service account to execute builds on the user’s behalf, according to Google’s advisory on the vulnerability. This Cloud Build service account previously allowed the build to have access to private logs by default, but as the June 8 security bulletin noted, “This permission has now been revoked from the Cloud Build service account to adhere to the security principle of least privilege.”
According to Nisimi, Google’s stance appears to be that the issue is the default permissions that organizations choose to enable for Cloud Build. He says, “Google recognizes that there is a supply-chain attack risk as described, but that it revolves around the choice of default permissions supporting the most common development workflows.”
Google’s stance is that customers are responsible for further locking down access for more advanced scenarios. “Therefore the supply chain risk is persistent, and organizations must limit the cloudbuild.builds.create permission as much as possible to reduce the risk of a supply chain attack,” Nisimi says.
