Compromising a vulnerable GCP, INE-Labs GCPGoat walkthrough. Part-2

Hello Everyone, welcome back and if you haven’t checked out previous post have a quick look at here.

Since we have access info to all instances currently operating in the project through developer-vm, we must now determine how to gain access to admin-vm. We should obtain all metadata information for the VMs from the dev VM. Let’s use the command below to view the metadata for both instances.
“gcloud compute instances descript developer-vm”

The reason we were able to run gcloud compute commands on developer-vm is now clear after taking a quick look at the details above. The VM has compute api access added to the scopes, and because the default service account to which it is bound has editor permissions by default on the project.
Looking at the account connected to admin-vm, it appears to be the project’s admin account.

Let’s try leveraging the dev-compute VM’s compute API access to gain access to the admin VM. As a result, in order to access a virtual machine, we must add our public ssh key to the VM’s metadata. let’s do try adding keys to the compute metadata for grant access to all of the project’s virtual machines.

Create new file and add public key in format “username:ssh_key_goes_here”
Run below commands to add sshkeys to compute metadata on project level

gcloud compute project-info add-metadata-from-file=ssh-keys=filename
gcloud compute project-info describe --format="value(commonInstanceMetadata[items][ssh-keys])"

Once we added our ssh key to the compute metadata we are able to ssh into the admin-vm now.

So we have access to the VM and got the project name and list of IAM bindings on the project as below and looks to be the service account binded to the VM has owner permissions on the project.

So with above permissions we should be able to add our account to the project for console access and it did worked.

So we have compromised the Project and gained previleged access.

What we should learn from this?

Let’s quickly examine what factors contributed to the attack and what best practise implementation would have prevented it.
-) Bucket permissions with setIAMPolicy set to allusers
Always check that no bucket is exposed to allUsers/allAuthenticated at the IAM level. If a bucket must be exposed to the public, check that only the storage.objects.get object viewer permission is set, and nothing else.
-) Storing sensitive files like private keys in bucket accessible to users internally.
Use secrets manager and restrict access to it to only certain svc accounts instead of keeping sensitive keys on cloud storage.
-) Default compute engine account used for instance.
Enforce org policy(“Automatic IAM Grants for Default Service Accounts”) to avoid provision of default svc account which comes with editor role by default. Instead create new service account and have only limited permissions needed and limited scopes on the VM.(Ref)
-) Avoid Service Account with owner previlges permissions
Setting svc acc with owner permissions on a project is not a good idea. Because having access to an svc account with high privileges would always result in problems and abuse.
-) Enforce org policy for “Domain restricted sharing”
By default all workspace domain accounts are allowed to be added in IAM polocies. It’s good to limit only certain domain accounts are only to be allowed on same. Ref

Hope this was helpful for learning on setting up some standards on GCP and thanks to INE-Labs for GCPGoat. See you soon again.