Comment on page
GCP - Privilege Escalation
GCP, as any other cloud, have some principals: users, groups and service accounts, and some resources like compute engine, cloud functions… Then, via roles, permissions are granted to those principals over the resources. This is the way to specify the permissions a principal has over a resource in GCP. There are certain permissions that will allow a user to get even more permissions on the resource or third party resources, and that’s what is called privilege escalation (also, the exploitation the vulnerabilities to get more permissions).
Therefore, I would like to separate GCP privilege escalation techniques in 2 groups:
- Privesc to a principal: This will allow you to impersonate another principal, and therefore act like it with all his permissions. e.g.: Abuse getAccessToken to impersonate a service account.
- Privesc on the resource: This will allow you to get more permissions over the specific resource. e.g.: you can abuse setIamPolicy permission over cloudfunctions to allow you to trigger the function.
- Note that some resources permissions will also allow you to attach an arbitrary service account to the resource. This means that you will be able to launch a resource with a SA, get into the resource, and steal the SA token. Therefore, this will allow to escalate to a principal via a resource escalation. This has happened in several resources previously, but now it’s less frequent (but can still happen).
Obviously, the most interesting privilege escalation techniques are the ones of the second group because it will allow you to get more privileges outside of the resources you already have some privileges over. However, note that escalating in resources may give you also access to sensitive information or even to other principals (maybe via reading a secret that contains a token of a SA).
It's important to note also that in GCP Service Accounts are both principals and permissions, so escalating privileges in a SA will allow you to impersonate it also.
The permissions between parenthesis indicate the permissions needed to exploit the vulnerability with
gcloud. Those might not be needed if exploiting it through the API.
This is how I test for specific permissions to perform specific actions inside GCP.
The way to escalate your privileges in AWS is to have enough permissions to be able to, somehow, access other service account/users/groups privileges. Chaining escalations until you have admin access over the organization.
GCP has hundreds (if not thousands) of permissions that an entity can be granted. In this book you can find all the permissions that I know that you can abuse to escalate privileges, but if you know some path not mentioned here, please share it.
You can find all the privesc paths divided by services:
If you are inside a machine in GCP you might be able to abuse permissions to escalate privileges even locally: