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

· Original article ↗

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

People

Vendors

Products

Tools

Related Articles