HackTricks Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - local privilege escalation ssh pivoting

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

Support HackTricks

in this scenario we are going to suppose that you have compromised a non privilege account inside a VM in a Compute Engine project.

Amazingly, GPC permissions of the compute engine you have compromised may help you to escalate privileges locally inside a machine. Even if that won't always be very helpful in a cloud environment, it's good to know it's possible.

Read the scripts

Compute Instances are probably there to execute some scripts to perform actions with their service accounts.

As IAM is go granular, an account may have read/write privileges over a resource but no list privileges.

A great hypothetical example of this is a Compute Instance that has permission to read/write backups to a storage bucket called instance82736-long-term-xyz-archive-0332893.

Running gsutil ls from the command line returns nothing, as the service account is lacking the storage.buckets.list IAM permission. However, if you ran gsutil ls gs://instance82736-long-term-xyz-archive-0332893 you may find a complete filesystem backup, giving you clear-text access to data that your local Linux account lacks.

You may be able to find this bucket name inside a script (in bash, Python, Ruby...).

Custom Metadata

Administrators can add custom metadata at the instance and project level. This is simply a way to pass arbitrary key/value pairs into an instance, and is commonly used for environment variables and startup/shutdown scripts.

Moreover, it's possible to add userdata, which is a script that will be executed everytime the machine is started or restarted and that can be accessed from the metadata endpoint also.

For more info check:

LogoCloud SSRFHackTricks

Abusing IAM permissions

Most of the following proposed permissions are given to the default Compute SA, the only problem is that the default access scope prevents the SA from using them. However, if cloud-platform scope is enabled or just the compute scope is enabled, you will be able to abuse them.

Check the following permissions:

Search for Keys in the filesystem

Check if other users have loggedin in gcloud inside the box and left their credentials in the filesystem:

sudo find / -name "gcloud"

These are the most interesting files:

  • ~/.config/gcloud/credentials.db

  • ~/.config/gcloud/legacy_credentials/[ACCOUNT]/adc.json

  • ~/.config/gcloud/legacy_credentials/[ACCOUNT]/.boto

  • ~/.credentials.json

More API Keys regexes

TARGET_DIR="/path/to/whatever"

# Service account keys
grep -Pzr "(?s){[^{}]*?service_account[^{}]*?private_key.*?}" \
    "$TARGET_DIR"

# Legacy GCP creds
grep -Pzr "(?s){[^{}]*?client_id[^{}]*?client_secret.*?}" \
    "$TARGET_DIR"

# Google API keys
grep -Pr "AIza[a-zA-Z0-9\\-_]{35}" \
    "$TARGET_DIR"

# Google OAuth tokens
grep -Pr "ya29\.[a-zA-Z0-9_-]{100,200}" \
    "$TARGET_DIR"

# Generic SSH keys
grep -Pzr "(?s)-----BEGIN[ A-Z]*?PRIVATE KEY[a-zA-Z0-9/\+=\n-]*?END[ A-Z]*?PRIVATE KEY-----" \
    "$TARGET_DIR"

# Signed storage URLs
grep -Pir "storage.googleapis.com.*?Goog-Signature=[a-f0-9]+" \
    "$TARGET_DIR"

# Signed policy documents in HTML
grep -Pzr '(?s)<form action.*?googleapis.com.*?name="signature" value=".*?">' \
    "$TARGET_DIR"

References

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

Support HackTricks
PreviousGCP - Network Docker EscapeNextGCP - Persistence

Last updated