Researchers warn that a permission associated with the Google Cloud Build service in Google Cloud can be easily abused by attackers with access to a regular account to elevate their privileges and potentially poison container images used in production environments. Google Cloud Build is a CI/CD platform that allows organizations and developers to execute code building tasks on Google Cloud in a variety of programming languages. The service supports importing source code from repositories and cloud storage locations, builds the code based on a configured specification, and produces artifacts such as container images that can be deployed directly into production environments.
Cloud Build integrates with other Google Cloud services such as Artifact Registry, Google Kubernetes Engine, and App Engine. As such, it has powerful capabilities and access. Some predefined user roles in Google Cloud already include some of the permissions needed to invoke Cloud Build service features, but some of these permissions can also be individually assigned to users, groups, and service accounts.
One of these permissions that researchers from Orca Security found can be abused for privilege escalation is called cloudbuild.builds.create. As the name implies, it can be used to create new builds using the Cloud Build Service. An organization having users with this permission would be very reasonable in an environment that uses Cloud Build as the main CI/CD platform, the Orca researchers said. In fact several default roles have it, including admin-level roles but also developer-related roles such as dataflow.developer.
Privilege escalation leading to a supply chain compromise
In a supply chain attack scenario, an attacker with access to a lower privileged account would attempt to find a path that grants them access to either source code or resources, such as binary artifacts, that an organization uses to develop and build their apps before they’re deployed. According to Orca Security, the cloudbuild.builds.create permission does just that.
“By abusing this flaw that enables the impersonation of the default Cloud Build service account, an attacker can manipulate images in Google’s Artifact Registry and inject malicious code,” the Orca researchers said. “Any applications built from the manipulated images are then affected, with potential outcomes including denial-of-service (DoS) attacks, data theft, and the spread of malware. Even worse, if the malformed applications are meant to be deployed on customer’s environments (either on-premises or semi-SaaS), the risk crosses from the supplying organization’s environment to their customers’ environments, constituting a supply chain attack, similar to what happened in the SolarWinds and MOVEit incidents.”
The Orca researchers named their proof-of-concept attack vector Bad.Builds, but they actually came across it while investigating another issue. They observed that whenever the setIamPolicy API method was used to update access to a Google Cloud Platform (GCP) resource, all the project’s permissions were included in the message body and were saved in the audit log.
