Talos Shows How Cloud Build Jobs Could Be Abused to Destroy Google Cloud Storage Data

Summary
Talos research demonstrates how an attacker able to trigger Cloud Build jobs could use the build service account’s permissions to delete or encrypt Cloud Storage data, and identifies audit events and safeguards for defenders.
Key points
- A person able to trigger a Cloud Build job may be able to run actions permitted to the build service account.
- Talos used a GitHub repository trigger to demonstrate the attack path without access to a GCP identity account.
- The research showed how Cloud Build permissions could be abused to delete a storage bucket or encrypt stored objects.
- Google Operations Logs record relevant build and storage events, including bucket deletion and creation; Talos describes their potential value for investigation and hunting.
- Talos recommends least-privilege service accounts, monitoring unusual Cloud Build activity, and requiring approval for builds triggered by pull requests.
- Soft Delete and Object Versioning can help protect against data loss and recovery complications.
Article Details
- Attack Vectors
- A user with the cloudbuild.builds.create permission can submit and run a Cloud Build job, which can execute gcloud commands allowed by the Cloud Build Service Account.
- A commit or pull request to a repository configured to trigger Cloud Build can cause a build to run; the research used commits to a GitHub repository to trigger the job.
- The Cloud Build execution path can be used to delete a Cloud Storage bucket and recreate a bucket with the same name, preventing restoration of the deleted bucket.
- The Cloud Build execution path can be used to overwrite stored objects with copies encrypted using an attacker-controlled customer-provided key, if Object Versioning is not configured.
- Defensive Notes
- Use a lower-privileged Service Account for Cloud Build with only the permissions required for the environment.
- Monitor for anomalous actions performed by Cloud Build Service Accounts and review relevant Google Operations Logs events, including storage.buckets.delete and storage.buckets.create.
- Require manual approval for builds triggered by pull requests or commits to pull requests where possible; require an owner or collaborator comment containing /gcbrun if that trigger feature is used.
- Require pull-request reviews before merging and do not allow direct commits to GitHub repositories without a pull request.
- Enable Soft Delete and Object Versioning for Cloud Storage buckets where possible.
MITRE ATT&CK
T1078.004 · Cloud AccountsThe article says an actor could obtain credentials for a GCP user or Service Account to use the Cloud Build execution vector.T1195.002 · Compromise Software Supply ChainThe article describes pushing or merging code into a repository configured with a Cloud Build pipeline to trigger malicious actions.T1485 · Data DestructionThe research demonstrates deleting a Cloud Storage bucket and recreating it with the same name to prevent restoration.T1486 · Data Encrypted for ImpactThe article describes overwriting Cloud Storage objects with copies encrypted using a customer-provided key controlled by an adversary.
People
Vendors
Products
Artifact Registryvector to perform a supply chain attack by adding malicious code to a victim application in GCP Artifact Registry. Talos did not extensively examine this technique since Orca’s research was quite comprehensive, butCloud BuildGoogle Cloud Platform Data Destruction via Cloud BuildCloud StorageCloud Platform lab environment utilized for offensive security research. Within that environment, a Cloud Storage bucket was created and the Cloud Build Application Programming Interface (API) were enabled.GitHub(CLI) tool to trigger the malicious build jobs they performed. Talos meanwhile utilized commits to a GitHub repository configured to trigger a Cloud Build job, since this is a form of Initial Access vector thatGoogle Cloud PlatformGoogle Cloud Platform Data Destruction via Cloud BuildGoogle Operations LogsAll of the events discussed above are logged by Google Operations Logs. The following Operations Logs events were identified during the research:Secrets Managerbut an actual adversary would likely take advantage of a public repository in most cases. The Secrets Manager API is also needed for Cloud Build to integrate with GitHub, so that was also enabled. These actions
Tools
gcloudrun a Cloud Build job (in other words, who has the cloudbuild.builds.create permission) can execute any gcloud GCP command line interface (CLI) command that the Cloud Build SA has the permissions to perform. A threatGitHub gh CLIintegrate with GitHub, so that was also enabled. These actions can be performed using the gcloud and GitHub gh CLI tools using the following commands:gsutilgsutil cp "$FILE" "gs://$BUCKET_NAME/"