Privilege Escalation with Google Cloud VM Instances

Introduction

Privilege escalation vectors in Google Cloud Platform have been an interesting topic for many organizations with large deployments. If an existing service in a GCP project is compromised, there is a distinct risk that a malicious user can use the privileges in the compromised service to escalate privileges within that project, access sensitive services in other projects, or achieve permissions over the organization itself.

What we are going to cover?

We will continue from the previous attack scenario where we were able to access the OAuth token which was used to break out to the Google cloud environment. Usually a developer or an admin will provide some additional permissions to the service account of the Google cloud compute instance to manage the environment right from the VM itself. We will see how to check for these permissions in an IAM policy and how we can exploit and escalate our privileges using any overly permissive IAM policies.

Steps to attack

This is a multi step attack and will involve fetching current privilege of the stolen token and using it to add attacker user accounts to the target Google Cloud.

1. Establish current service account IAM privileges

• Check the IAM policy attached to the project we are currently in, using the below cURL command:

curl -X POST -H "Authorization: Bearer $gcp_token" "https://cloudresourcemanager.googleapis.com/v1/projects/$GCLOUD_PROJECT:getIamPolicy"

Note: If you receive an error, then navigate to the URL provided in the response and enable the API

check policy

By default, the default VM instance service account is of the format [e-mail] and has the Editor pre-defined role attached to it. This itself can be considered to be a privileged role as you can see from the full list of permissions this enables here https://console.cloud.google.com/iam-admin/roles/details/roles%3Ceditor

In our example, this service account has IAM privileges as well that allow it to setIAMPolicy as well which is conspicuously missing from the default Editor role.

We can use this privilege to add another member account (Attacker) and gain access to the target Google Cloud platform.

2. Add attacker account to target Google Cloud

• Fetch the current IAM Policy for the account using the service account token and save it to a file called tmp.json

curl -sX POST -H "Authorization: Bearer $gcp_token" https://cloudresourcemanager.googleapis.com/v1/projects/$GCLOUD_PROJECT:getIamPolicy > tmp.json

iam policy

• To update the policy (not overwrite the others, but add a new member), we will update the tmp.json and add our attacker email under the roles/editor role. Save the tmp.json after adding the email. You can use another google email if you have for this exercise or the email of another student next to you.

• We need to fix the JSON so that it is compatible with the REST API by running the following command to create a new policy.json

• echo '{ "policy":' > policy.json;cat tmp.json >> policy.json;echo '}' >> policy.json

update policy json

• Make a new request as shown below to push the edited policy.json.

curl -sX POST -H "Authorization: Bearer $gcp_token" -H "Content-Type: application/json; charset=utf-8" -d @policy.json "https://cloudresourcemanager.googleapis.com/v1/projects/$GCLOUD_PROJECT:setIamPolicy"

attacker added to IAM

• Observe that the user now has access to the project

Additional resources

• Manage access to projects, folders, and organizations