gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-05 20:40:18 -08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
SirBroccoli
2025-08-01 11:52:52 +02:00
committed by GitHub
parent 3157069bde
commit 5fd9ed5048
1 changed files with 5 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -2,21 +2,17 @@
{{#include ../../../../banners/hacktricks-training.md}}
## GCP - Add Custom SSH Metadata
### Modifying the metadata <a href="#modifying-the-metadata" id="modifying-the-metadata"></a>
## 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**
### **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**
### **Add SSH key to existing privileged user**
1. **Examine Existing SSH Keys on the Instance:**
@@ -57,7 +53,7 @@ Therefore, if an attacker can modify custom metadata, he could make the the daem
sudo id
```
#### **Create a new privileged user and add a SSH key**
### **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:
@@ -79,7 +75,7 @@ gcloud compute instances add-metadata [INSTANCE_NAME] --metadata-from-file ssh-k
ssh -i ./key "$NEWUSER"@localhost
```
#### SSH keys at project level <a href="#sshing-around" id="sshing-around"></a>
### 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: