Google Cloud Build Flaw Could Enable Supply Chain Attacks
Bad actors could exploit a design flaw called Bad.Build in Google Cloud Build to escalate privileges and gain access to Google Artifact Registry code repositories.
“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,” Roi Nisimi, a researcher at Orca Security, the firm whose researchers discovered the flaw, wrote in a blog post. “As we have seen with the [SUNBURST] and recent 3CX and MOVEit supply chain attacks, this can have far-reaching consequences.”
Through the flaw, attackers could tap a Google Cloud Build account and run API calls against the code repositories. After taking control of application images, they could inject malicious code and then launch attacks against vulnerable apps and supply chains.
“Even worse, if the malformed applications are meant to be deployed on customers’ 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,” Nisimi wrote.
Orca detailed the Bad.Build kill chain:
- Step One: Privilege Escalation using cloudbuild.builds.create: cloudbuild.builds.create is a permission that allows accounts to create new builds using the Google Cloud Build service – a fully-managed CI/CD platform that allows you to build, test and deploy software quickly. All build actions, or steps (GCP terminology), are executed by the default Cloud Build Service Account.
- Step Two: Gaining access to Artifact Registry: Once an attacker can create builds, they can impersonate the Cloud Build Service account and escalate privileges. This service account, by default, can run API calls against the artifact registry.
- Step Three: Image exfiltration: Through artifactregistry permissions, the attacker can download and exfiltrate an image that is being used inside Google Kubernetes Engine (GKE).
- Step Four: Infecting the image and pushing to Artifact Registry: The attacker can then inject malicious code into the image and push it back to the artifact registry, which is deployed once again to the GKE.
- Step Five: Supply chain attack and remote code execution: Once the malicious image is deployed, the attacker can exploit it and run code on the Docker container as root.
“Bad.Build is another example of what seems like a growing number of supply chain attacks,” said Dave Ratner, CEO at HYAS. “These can be incredibly difficult to detect, and equally valuable for attackers to quickly spread across multiple organizations.”
Ratner added, “A protective DNS strategy, deployed across both the corporate and production environments—or wherever the cloud is used—can be the early warning signal that anomalous activity is occurring, and can provide the visibility and observability required to implement a business resiliency strategy not just against Bad.Build but against the inevitable supply chain attacks that will follow.”
