|
|
|
|
@@ -1,20 +1,18 @@
|
|
|
|
|
# GCP - Add Custom SSH Metadata
|
|
|
|
|
|
|
|
|
|
## GCP - Add Custom SSH Metadata
|
|
|
|
|
|
|
|
|
|
{{#include ../../../../banners/hacktricks-training.md}}
|
|
|
|
|
|
|
|
|
|
### 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:**
|
|
|
|
|
|
|
|
|
|
@@ -55,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:
|
|
|
|
|
|
|
|
|
|
@@ -77,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:
|
|
|
|
|
|
|
|
|
|
@@ -100,4 +98,3 @@ It's possible to broaden the reach of SSH access to multiple Virtual Machines (V
|
|
|
|
|
{{#include ../../../../banners/hacktricks-training.md}}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|