Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.
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...).
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:
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:
Check if other users have loggedin in gcloud inside the box and left their credentials in the filesystem:
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
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
