Google Partially Patches Cloud Build’s Critical Design Flaw: Bad.Build

Researchers discovered a critical security design flaw in Google Cloud Build, which they dubbed as “Bad.Build”. The design flaw could enable attackers to tamper with organizations’ code repositories and application images.

The security researchers disclosed information about the vulnerability and issued a warning, emphasizing its potential for facilitating a supply-chain attack similar to SolarWinds or MOVEit, with widespread and severe impact.

Following the report of the vulnerability, Google promptly implemented a fix. However, according to Orca researcher Roi Nisimi, the fix is only partial and does not fully resolve the issue.

What Causes the Issue in Google Cloud Build?

Google Cloud Build is a managed continuous integration and delivery (CI/CD) service. It enables users to automate the software building, testing, and deployment processes across various programming languages. Google Cloud Build can integrate with services like Artifact Registry, Google Kubernetes Engine, and App Engine.

Cloud Build relies on service accounts to authenticate requests made during the build process, and the problem, as identified by Google, is primarily due to improperly defined permissions.

Who Is Affected by the Google Cloud Build Design Flaw?

The potential impact can be diverse, and applies to all organizations that are using the Artifact Registry as their main or secondary image repository. The first and immediate impact is disrupting the applications relying on these images. This can lead to Denial-of-Service (DoS) attacks, data theft and the dissemination of malware to users.

Furthermore, if the malicious applications are intended to be deployed in customers’ environments, the risk extends beyond the supplying organization’s infrastructure, resulting in a supply chain attack.

How Does the Google Cloud Build Flaw Work?

Orca researchers found that enabling the Cloud Build API in a project automatically creates a default service account for executing builds. Until June, this had a flaw allowing builds access to private audit logs with a complete list of project permissions. 

The researchers uncovered that the design flaw within Google Cloud Build service allows attackers to escalate privilege, thereby gaining unauthorized access to code repositories in Google’s Artifact Registry. An attacker who exploits this flaw and impersonates the default Cloud Build service account can manipulate images stored in Google’s Artifact Registry and inject malicious code.

When asked about Orca’s claim of a partial fix, a Google spokesperson only mentioned their vulnerability rewards program and thanked the researchers for their help.

Google stated that they incorporated a fix based on the researchers’ report in a security bulletin issued in early June, implying they will not deploy another fix. The fix involves the removal of a single permission from the default Cloud Build Service Account. However, the revoked permission was unrelated to Artifact Registry, transforming the supply chain risk into a persistent one.

Organizations should closely monitor the behavior of the default Google Cloud Build service account, and also follow Identity and Access Management (IAM)controls to effectively manage accounts. Nisimi emphasized the importance of applying the principle of least privilege to reduce an organization’s risk.

Proof-of-Concept Exploit for a Supply Chain Attack

The supply chain attack Proof of Concept (PoC) involves the following steps:

1. Privilege Escalation: The attacker gains higher privileges using cloudbuild.builds.create, allowing them to create builds using the Google Cloud Build service, executed by the default Cloud Build Service Account.
2. Gaining Access to Artifact Registry: The attacker impersonates the Cloud Build Service Account, gaining privileges to run API calls against the Artifact Registry.
3. Image Exfiltration: Using artifact registry permissions, the attacker downloads and exfiltrates an image used in Google Kubernetes Engine (GKE).
4. Infecting and Pushing the Image: The attacker injects malicious code into the image and pushes it back to the artifact registry. The compromised image is redeployed to GKE.
5. Supply Chain Attack and Remote Code Execution: After deploying the malicious image, the attacker exploits it, gaining root access and enabling remote code execution on the docker container.

How can SOCRadar Help? 

SOCRadar’s Cloud Security module helps organizations monitor and secure their cloud storage assets. It can detect new cloud storage belonging to users, monitor bucket status, and send alerts when there are any changes. 

On the other hand, SOCRadar’s Supply Chain Intelligence module helps you keep an eye on the third-party components your organization uses. With up-to-date news, it warns your security team about possible dangers.