GCP - Privilege Escalation
Introduction to 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.
Permissions for Privilege Escalation Methodology
This is how I test for specific permissions to perform specific actions inside GCP.
Download the github repo https://github.com/carlospolop/gcp_privesc_scripts
Add in tests/ the new script
Bypassing access scopes
Tokens of SA leakded from GCP metadata service have access scopes. These are restrictions on the permissions that the token has. For example, if the token has the https://www.googleapis.com/auth/cloud-platform scope, it will have full access to all GCP services. However, if the token has the https://www.googleapis.com/auth/cloud-platform.read-only scope, it will only have read-only access to all GCP services even if the SA has more permissions in IAM.
There is no direct way to bypass these permissions, but you could always try searching for new credentials in the compromised host, find the service key to generate an OAuth token without restriction or jump to a different VM less restricted.
When access scopes are used, the OAuth token that is generated for the computing instance (VM) will have a scope limitation included. However, you might be able to bypass this limitation and exploit the permissions the compromised account has.
The best way to bypass this restriction is either to find new credentials in the compromised host, to find the service key to generate an OAuth token without restriction or to compromise a different VM with a SA less restricted.
Check SA with keys generated with:
Privilege Escalation Techniques
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.
The subpages of this section are ordered by services. You can find on each service different ways to escalate privileges on the services.
Abusing GCP to escalate privileges locally
If you are inside a machine in GCP you might be able to abuse permissions to escalate privileges even locally:
pageGCP - local privilege escalation ssh pivotingReferences
Last updated