diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md index b9dd5de74..d37ccd9b7 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md @@ -10,17 +10,17 @@ ../../aws-services/aws-kms-enum.md {{#endref}} -### एन्क्रिप्ट/डिक्रिप्ट जानकारी +### Encrypt/Decrypt information -`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files: +`fileb://` और `file://` वे URI schemes हैं जो AWS CLI commands में स्थानीय फाइलों का path निर्दिष्ट करने के लिए उपयोग किए जाते हैं: -- `fileb://:` फ़ाइल को बाइनरी मोड में पढ़ता है, सामान्यतः नॉन-टेक्स्ट फाइल्स के लिए उपयोग होता है। -- `file://:` फ़ाइल को टेक्स्ट मोड में पढ़ता है, आमतौर पर प्लेन टेक्स्ट फाइल्स, स्क्रिप्ट्स, या ऐसे JSON के लिए उपयोग होता है जिनमें विशेष एन्कोडिंग आवश्यकताएँ नहीं होतीं। +- `fileb://:` फाइल को बाइनरी मोड में पढ़ता है, आमतौर पर गैर-टेक्स्ट फ़ाइलों के लिए उपयोग होता है। +- `file://:` फाइल को टेक्स्ट मोड में पढ़ता है, सामान्यतः plain text files, scripts, या JSON के लिए उपयोग होता है जो विशेष encoding आवश्यकताओं के बिना हों। > [!TIP] -> नोट: यदि आप किसी फाइल के अंदर कुछ डेटा डिक्रिप्ट करना चाहते हैं, तो फाइल में बाइनरी डेटा होना चाहिए, base64 एन्कोडेड डेटा नहीं। (fileb://) +> ध्यान दें कि यदि आप किसी फ़ाइल के भीतर कुछ डेटा को decrypt करना चाहते हैं, तो फ़ाइल में binary data होना चाहिए, base64 encoded data नहीं। (fileb://) -- Using a **symmetric** key +- एक **symmetric** key का उपयोग ```bash # Encrypt data aws kms encrypt \ @@ -38,7 +38,7 @@ aws kms decrypt \ --query Plaintext | base64 \ --decode ``` -- **asymmetric** key का उपयोग: +- **asymmetric** key का उपयोग करना: ```bash # Encrypt data aws kms encrypt \ @@ -60,14 +60,14 @@ aws kms decrypt \ ``` ### KMS Ransomware -KMS पर विशेषाधिकारिक पहुंच रखने वाला attacker कुंजियों की KMS policy को संशोधित कर सकता है और **अपने खाते को उन पर पहुँच दे सकता है**, वैध खाते को दी गई पहुँच हटा सकता है। +KMS पर privileged access रखने वाला attacker KMS की keys की KMS policy को संशोधित कर सकता है और **अपने खाते को उन पर access दे सकता है**, जिससे legit account को दिया गया access हटा दिया जाता है। -इसके बाद, वैध खाते के उपयोगकर्ता उन कुंजियों से एन्क्रिप्ट की गई किसी भी सेवा की जानकारी तक पहुँच नहीं पाएंगे, जिससे खाते पर एक आसान लेकिन प्रभावी ransomware बन जाएगा। +इसके बाद, legit account users उन किसी भी सेवा की कोई भी जानकारी access नहीं कर पाएँगे जो इन keys से encrypted है, जिससे account पर एक आसान परंतु प्रभावी ransomware बन जाता है। > [!WARNING] -> ध्यान दें कि **AWS managed keys aren't affected** — प्रभावित केवल **Customer managed keys** हैं। - -> साथ ही यह ध्यान दें कि पैरामीटर **`--bypass-policy-lockout-safety-check`** का उपयोग आवश्यक है (web console में इस विकल्प की कमी इस हमले को केवल CLI से संभव बनाती है)। +> ध्यान दें कि **AWS managed keys aren't affected** इस हमले से प्रभावित नहीं होते, केवल **Customer managed keys** प्रभावित होते हैं। +> +> साथ ही ध्यान दें कि पैरामीटर **`--bypass-policy-lockout-safety-check`** का उपयोग आवश्यक है (web console में यह विकल्प न होने के कारण यह हमला केवल CLI से ही संभव है)। ```bash # Force policy change aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \ @@ -92,28 +92,28 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \ } ``` > [!CAUTION] -> ध्यान दें कि यदि आप उस नीति को बदलते हैं और केवल किसी बाहरी खाते (external account) को ही पहुंच देते हैं, और फिर उसी बाहरी खाते से आप एक नई नीति सेट करके मूल खाते (original account) को पहुंच वापस देने की कोशिश करते हैं, तो आप सक्षम नहीं होंगे क्योंकि Put Polocy क्रिया cross account से निष्पादित नहीं की जा सकती। +> ध्यान दें कि यदि आप उस policy को बदलते हैं और केवल access को एक external account को देते हैं, और फिर इस external account से आप एक नया policy सेट करने की कोशिश करते हैं ताकि **give the access back to original account, you won't be able cause the Put Polocy action cannot be performed from a cross account**।
### Generic KMS Ransomware -There is another way to perform a global KMS Ransomware, which would involve the following steps: +global KMS Ransomware को अंजाम देने का एक और तरीका है, जिसमें निम्नलिखित चरण शामिल होंगे: -- हमलावर द्वारा import किए गए **key with a key material** के साथ एक नया key बनाना -- victim के पुराने डेटा को, जो previous version से encrypt था, नई key से **Re-encrypt older data** करना। +- Create a new **key with a key material** जिसे attacker ने import किया हो +- **Re-encrypt older data** जिसे victim के previous version से encrypt किया गया था, उसे नए version से re-encrypt करें। - **Delete the KMS key** -- अब केवल हमलावर, जिसके पास मूल key material है, encrypted डेटा को decrypt करने में सक्षम होगा। +- अब केवल attacker ही, जिसके पास original key material है, encrypted data को decrypt कर पाएगा ### Delete Keys via kms:DeleteImportedKeyMaterial -With the `kms:DeleteImportedKeyMaterial` permission, an actor can delete the imported key material from CMKs with `Origin=EXTERNAL` (CMKs that have imperted their key material), making them unable to decrypt data. This action is destructive and irreversible unless compatible material is re-imported, allowing an attacker to effectively cause ransomware-like data loss by rendering encrypted information permanently inaccessible. +With the `kms:DeleteImportedKeyMaterial` permission, an actor can delete the imported key material from CMKs with `Origin=EXTERNAL` (CMKs that have imported their key material), making them unable to decrypt data. This action is destructive and irreversible unless compatible material is re-imported, allowing an attacker to effectively cause ransomware-like data loss by rendering encrypted information permanently inaccessible. ```bash aws kms delete-imported-key-material --key-id ``` -### keys को नष्ट करना +### कुंजियाँ नष्ट करना -keys को नष्ट करने से DoS किया जा सकता है। +कुंजियाँ नष्ट करने से DoS किया जा सकता है। ```bash # Schedule the destoy of a key (min wait time is 7 days) aws kms schedule-key-deletion \ @@ -121,10 +121,10 @@ aws kms schedule-key-deletion \ --pending-window-in-days 7 ``` > [!CAUTION] -> ध्यान दें कि AWS अब **पिछली क्रियाओं को cross account से निष्पादित होने से रोकता है:** +> ध्यान दें कि AWS अब **पहले की क्रियाओं को cross account से निष्पादित किए जाने से रोकता है:** -### Alias बदलना या हटाना -यह attack AWS KMS aliases को delete या redirect कर देता है, जिससे key resolution टूट जाती है और उन सेवाओं में तुरंत विफलताएँ होती हैं जो उन aliases पर निर्भर करती हैं, और इसका परिणाम denial-of-service होता है। `kms:DeleteAlias` या `kms:UpdateAlias` जैसे permissions के साथ एक attacker aliases को हटाकर या पुनर्निर्देशित करके cryptographic operations (e.g., encrypt, describe) में बाधा डाल सकता है। कोई भी service जो key ID के बजाय alias को reference करती है वह alias को restore या सही तरीके से remap किए जाने तक fail हो सकती है। +### Alias बदलें या हटाएँ +यह हमला AWS KMS aliases को delete या redirect कर देता है, जिससे key resolution टूट जाती है और उन services में तत्काल विफलताएँ होती हैं जो उन aliases पर निर्भर करती हैं, परिणामस्वरूप denial-of-service हो जाता है। `kms:DeleteAlias` या `kms:UpdateAlias` जैसे permissions होने पर एक attacker aliases को remove या repoint कर सकता है और cryptographic operations (e.g., encrypt, describe) को बाधित कर सकता है। कोई भी service जो key ID के बजाय alias को reference करती है, तब तक fail हो सकती है जब तक alias को restore या सही तरीके से remap नहीं किया जाता। ```bash # Delete Alias aws kms delete-alias --alias-name alias/ @@ -134,8 +134,8 @@ aws kms update-alias \ --alias-name alias/ \ --target-key-id ``` -### Cancel Key Deletion -यदि किसी खाते के पास `kms:CancelKeyDeletion` और `kms:EnableKey` जैसी permissions हों, तो एक हमलावर AWS KMS customer master key की अनुसूचित deletion को रद्द कर सकता है और बाद में उसे पुनः सक्षम कर सकता है। ऐसा करने पर कुंजी पुनर्प्राप्त हो जाती है (प्रारंभ में Disabled state में) और पहले से संरक्षित डेटा को decrypt करने की इसकी क्षमता बहाल हो जाती है, जिससे exfiltration संभव हो जाता है। +### कुंजी हटाने को रद्द करना +`kms:CancelKeyDeletion` और `kms:EnableKey` जैसी अनुमतियों के साथ, कोई actor किसी AWS KMS customer master key की निर्धारित deletion को रद्द कर सकता है और बाद में उसे फिर से सक्षम कर सकता है। ऐसा करने से कुंजी पुनः प्राप्त हो जाती है (initially in Disabled state) और यह पहले से सुरक्षित डेटा को decrypt करने की क्षमता बहाल कर देती है, जिससे exfiltration संभव हो जाता है। ```bash # Firts cancel de deletion aws kms cancel-key-deletion \ @@ -145,14 +145,14 @@ aws kms cancel-key-deletion \ aws kms enable-key \ --key-id ``` -### कुंजी अक्षम करें -`kms:DisableKey` अनुमति के साथ, कोई actor एक AWS KMS ग्राहक मास्टर कुंजी को अक्षम कर सकता है, जिससे वह कुंजी एन्क्रिप्शन या डिक्रिप्शन के लिए उपयोग नहीं हो पाएगी। यह उस CMK पर निर्भर किसी भी सेवा के लिए एक्सेस तोड़ देता है और कुंजी के पुनः सक्षम होने तक तात्कालिक व्यवधान या denial-of-service पैदा कर सकता है। +### Disable Key +`kms:DisableKey` अनुमति के साथ, एक अभिकर्ता AWS KMS customer master key को निष्क्रिय कर सकता है, जिससे उसे encryption या decryption के लिए उपयोग नहीं किया जा सकेगा। यह उस CMK पर निर्भर किसी भी सेवा की पहुंच को बाधित कर देता है और जब तक key को पुनः सक्षम नहीं किया जाता, तब तक तत्काल व्यवधान या denial-of-service हो सकता है। ```bash aws kms disable-key \ --key-id ``` -### साझा रहस्य व्युत्पन्न करें -यदि किसी के पास `kms:DeriveSharedSecret` permission है, तो एक actor KMS-held निजी कुंजी और उपयोगकर्ता-प्रदान की गई सार्वजनिक कुंजी का उपयोग करके ECDH साझा रहस्य की गणना कर सकता है। +### Derive Shared Secret +With the `kms:DeriveSharedSecret` permission, एक actor KMS-में रखी निजी कुंजी और उपयोगकर्ता-प्रदान सार्वजनिक कुंजी का उपयोग करके एक ECDH साझा रहस्य गणना कर सकता है। ```bash aws kms derive-shared-secret \ --key-id \ @@ -160,7 +160,7 @@ aws kms derive-shared-secret \ --key-agreement-algorithm ``` ### Impersonation via kms:Sign -`kms:Sign` अनुमति के साथ, कोई actor KMS-में संग्रहीत CMK का उपयोग करके private key को उजागर किए बिना डेटा पर क्रिप्टोग्राफिक रूप से साइन कर सकता है, जिससे वैध signatures बनते हैं जो impersonation को सक्षम कर सकते हैं या दुर्भावनापूर्ण कार्यों को अधिकृत कर सकते हैं। +`kms:Sign` permission के साथ, एक actor KMS-stored CMK का उपयोग करके private key को उजागर किए बिना डेटा को cryptographically साइन कर सकता है, जिससे ऐसे वैध सिग्नेचर बनते हैं जो impersonation को सक्षम कर सकते हैं या दुर्भावनापूर्ण कार्रवाइयों को अधिकृत कर सकते हैं। ```bash aws kms sign \ --key-id \ @@ -168,8 +168,8 @@ aws kms sign \ --signing-algorithm \ --message-type RAW ``` -### DoS के साथ Custom Key Stores -`kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore`, या `kms:UpdateCustomKeyStore` जैसी अनुमतियों के साथ, एक actor एक AWS KMS Custom Key Store (CKS) को संशोधित, disconnect, या delete कर सकता है, जिससे उसके master keys inoperable हो जाते हैं। यह उन keys पर निर्भर किसी भी सेवाओं के लिए encryption, decryption, और signing ऑपरेशनों को बाधित कर देता है और तुरंत denial-of-service का कारण बन सकता है। इसलिए उन अनुमतियों को सीमित करना और मॉनिटर करना अत्यंत महत्वपूर्ण है। +### DoS with Custom Key Stores +यदि किसी को `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore`, या `kms:UpdateCustomKeyStore` जैसी permissions मिलती हैं, तो एक actor किसी AWS KMS Custom Key Store (CKS) को संशोधित, डिस्कनेक्ट, या डिलीट कर सकता है, जिससे उसके master keys निष्क्रिय हो जाते हैं। इससे उन सेवाओं के लिए एन्क्रिप्शन, डिक्रिप्शन, और साइनिंग ऑपरेशन प्रभावित होते हैं जो उन keys पर निर्भर हैं और यह तुरंत denial-of-service का कारण बन सकता है। इसलिए इन permissions को सीमित और मॉनिटर करना अत्यंत आवश्यक है। ```bash aws kms delete-custom-key-store --custom-key-store-id 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 3b84e31cc..db6ebc837 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,26 +12,26 @@ IAM के बारे में अधिक जानकारी के ल ### **`iam:CreatePolicyVersion`** -एक नया IAM policy version बनाने की क्षमता देता है, bypassing the need for `iam:SetDefaultPolicyVersion` permission by using the `--set-as-default` flag. यह कस्टम permissions परिभाषित करने में सक्षम बनाता है। +नया IAM पॉलिसी संस्करण बनाने की क्षमता प्रदान करता है, `iam:SetDefaultPolicyVersion` permission की आवश्यकता को `--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 ``` -**प्रभाव:** किसी भी संसाधन पर किसी भी क्रिया की अनुमति देकर प्रत्यक्ष रूप से privileges बढ़ाता है। +**प्रभाव:** किसी भी resource पर किसी भी action की अनुमति देकर सीधे privileges escalate करता है। ### **`iam:SetDefaultPolicyVersion`** -IAM policy के डिफ़ॉल्ट वर्शन को किसी अन्य मौजूदा वर्शन में बदलने की अनुमति देता है, जो कि नए वर्शन में अधिक permissions होने पर संभावित रूप से privileges बढ़ा सकता है। +यह IAM policy के default संस्करण को किसी अन्य मौजूद संस्करण में बदलने की अनुमति देता है, जो संभावित रूप से privileges escalate कर सकता है अगर नए संस्करण में अधिक permissions हों। -**Bash कमांड:** +**Bash Command:** ```bash aws iam set-default-policy-version --policy-arn --version-id v2 ``` -**प्रभाव:** अधिक permissions सक्षम करने से अप्रत्यक्ष privilege escalation होता है। +**प्रभाव:** अप्रत्यक्ष privilege escalation — अधिक permissions सक्षम करने से। -### **`iam:CreateAccessKey`** +### **`iam:CreateAccessKey`, (`iam:DeleteAccessKey`)** किसी अन्य उपयोगकर्ता के लिए access key ID और secret access key बनाने की अनुमति देता है, जिससे संभावित privilege escalation हो सकता है। @@ -39,67 +39,86 @@ aws iam set-default-policy-version --policy-arn --version-id ```bash aws iam create-access-key --user-name ``` -**Impact:** किसी अन्य उपयोगकर्ता के विस्तारित permissions को अपनाकर सीधे privilege escalation। +**Impact:** किसी अन्य उपयोगकर्ता की विस्तारित permissions को assume करके direct privilege escalation। + +ध्यान दें कि किसी उपयोगकर्ता के केवल 2 access keys ही बनाए जा सकते हैं, इसलिए यदि किसी उपयोगकर्ता के पहले से ही 2 access keys हैं तो नया access key बनाने के लिए आपको उनमें से एक को हटाने हेतु permission `iam:DeleteAccessKey` की आवश्यकता होगी: +```bash +aws iam delete-access-key --uaccess-key-id +``` +### **`iam:CreateVirtualMFADevice` + `iam:EnableMFADevice`** + +यदि आप एक नया virtual MFA device बना सकते हैं और उसे किसी अन्य user पर enable कर सकते हैं, तो आप प्रभावी रूप से उस user के लिए अपना MFA रजिस्टर कर सकते हैं और फिर उनके credentials के लिए एक MFA-backed session अनुरोध कर सकते हैं। + +**Exploit:** +```bash +# Create a virtual MFA device (this returns the serial and the base32 seed) +aws iam create-virtual-mfa-device --virtual-mfa-device-name + +# Generate 2 consecutive TOTP codes from the seed, then enable it for the user +aws iam enable-mfa-device --user-name --serial-number \ +--authentication-code1 --authentication-code2 +``` +**प्रभाव:** किसी उपयोगकर्ता के MFA नामांकन पर कब्ज़ा करके (और फिर उनकी अनुमतियों का उपयोग करके) सीधे privilege escalation हासिल किया जा सकता है। ### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`** -login profile बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS console login के लिए पासवर्ड सेट करना शामिल है, जो सीधे privilege escalation की ओर ले जाता है। +लॉगिन प्रोफ़ाइल बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS console लॉगिन के लिए पासवर्ड सेट करना भी शामिल है, जिससे सीधे privilege escalation हो सकता है। -**Exploit for Creation:** +**बनाने के लिए Exploit:** ```bash aws iam create-login-profile --user-name target_user --no-password-reset-required \ --password '' ``` -**Exploit अपडेट के लिए:** +**अपडेट के लिए Exploit:** ```bash aws iam update-login-profile --user-name target_user --no-password-reset-required \ --password '' ``` -**Impact:** किसी भी user के रूप में लॉगिन करके सीधे privilege escalation। +**प्रभाव:** सीधे privilege escalation किसी भी उपयोगकर्ता के रूप में लॉगिन करके। ### **`iam:UpdateAccessKey`** -निष्क्रिय access key को सक्रिय करने की अनुमति देता है, जिससे संभवतः अनधिकृत पहुँच हो सकती है यदि attacker के पास वह निष्क्रिय access key मौजूद हो। +निष्क्रिय access key को सक्षम करने की अनुमति देता है, जो संभावित रूप से unauthorized access का कारण बन सकता है यदि attacker के पास वह disabled key हो। **Exploit:** ```bash aws iam update-access-key --access-key-id --status Active --user-name ``` -**प्रभाव:** एक्सेस कुंजियाँ पुनः सक्रिय करके सीधे privilege escalation संभव। +**प्रभाव:** सीधा privilege escalation access keys को पुनः सक्रिय करके। ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`** -विशिष्ट AWS सेवाओं (उदा., CodeCommit, Amazon Keyspaces) के लिए क्रेडेंशियल्स उत्पन्न करने या रीसेट करने की अनुमति देता है, जो संबद्ध उपयोगकर्ता की अनुमतियाँ प्राप्त करते हैं। +विशिष्ट AWS सेवाओं (उदा., CodeCommit, Amazon Keyspaces) के लिए credentials बनाने या रीसेट करने की अनुमति देता है, और संबंधित user के permissions को inherit करता है। **Exploit for Creation:** ```bash aws iam create-service-specific-credential --user-name --service-name ``` -**Reset के लिए Exploit:** +**Exploit रीसेट के लिए:** ```bash aws iam reset-service-specific-credential --service-specific-credential-id ``` -**Impact:** उपयोगकर्ता की सेवा अनुमतियों के भीतर सीधे privilege escalation। +**प्रभाव:** उपयोगकर्ता की सेवा अनुमतियों के भीतर प्रत्यक्ष विशेषाधिकार वृद्धि। ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`** -यह उपयोगकर्ताओं या समूहों पर नीतियाँ संलग्न करने की अनुमति देता है, और संलग्न नीति की अनुमतियाँ प्राप्त करके सीधे अधिकार बढ़ा देता है। +उपयोगकर्ता या समूहों पर नीतियाँ संलग्न करने की अनुमति देता है, जिससे संलग्न नीति के अनुमतियों को अपनाकर सीधे विशेषाधिकार बढ़ जाते हैं। -**Exploit for User:** +**उपयोगकर्ता के लिए Exploit:** ```bash aws iam attach-user-policy --user-name --policy-arn "" ``` -**समूह के लिए 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`** -यह roles, users, या groups पर नीतियाँ attach/put करने की अनुमति देता है, जिससे अतिरिक्त अनुमतियाँ देकर सीधे privilege escalation संभव हो जाता है। +roles, users, या groups में policies attach या put करने की अनुमति देता है, जिससे additional permissions देकर direct privilege escalation संभव होता है। -Role के लिए Exploit: +**Role के लिए Exploit:** ```bash aws iam attach-role-policy --role-name --policy-arn "" ``` @@ -114,7 +133,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 +146,28 @@ aws iam put-role-policy --role-name --policy-name "" \ ] } ``` -**प्रभाव:** नीतियों के माध्यम से permissions जोड़कर सीधे privilege escalation होता है। +**प्रभाव:** नीतियों के माध्यम से अनुमतियाँ जोड़कर सीधे privilege escalation। ### **`iam:AddUserToGroup`** -खुद को एक IAM group में जोड़ने की अनुमति देता है, समूह की permissions को inherit करके privileges escalate हो जाते हैं। +यह स्वयं को एक IAM समूह में जोड़ने की अनुमति देता है, और समूह की अनुमतियाँ विरासत में लेकर privileges escalate कर देता है। **Exploit:** ```bash aws iam add-user-to-group --group-name --user-name ``` -**प्रभाव:** सीधे समूह की permissions के स्तर तक privilege escalation। +**प्रभाव:** सीधा privilege escalation समूह की permissions के स्तर तक। ### **`iam:UpdateAssumeRolePolicy`** -एक role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role को assume करने और उससे जुड़ी permissions का उपयोग करने में सक्षम होता है। +यह किसी role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role की assumption और उसके associated 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,38 +182,38 @@ aws iam update-assume-role-policy --role-name \ ] } ``` -**Impact:** किसी भी role की permissions को assume करके Direct privilege escalation संभव। +**प्रभाव:** किसी भी role की permissions को assume करके प्रत्यक्ष privilege escalation। ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`** -CodeCommit के लिए authenticating हेतु SSH public key अपलोड करने और MFA devices को deactivate करने की अनुमति देता है, जिससे संभावित indirect privilege escalation हो सकता है। +CodeCommit के लिए प्रमाणीकरण हेतु 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 के लिए MFA निष्क्रियकरण:** +**MFA निष्क्रियकरण के लिए Exploit:** ```bash aws iam deactivate-mfa-device --user-name --serial-number ``` -**प्रभाव:** CodeCommit एक्सेस सक्षम करके या MFA सुरक्षा अक्षम करके अप्रत्यक्ष privilege escalation। +**प्रभाव:** CodeCommit access सक्षम करके या MFA protection को अक्षम करके अप्रत्यक्ष privilege escalation। ### **`iam:ResyncMFADevice`** -MFA डिवाइस का पुनः-सिंक करने की अनुमति देता है, जो MFA सुरक्षा में छेड़छाड़ करके संभावित रूप से अप्रत्यक्ष privilege escalation का कारण बन सकता है। +यह एक MFA device को resynchronize करने की अनुमति देता है, जो MFA protection को हेरफेर करके संभावित रूप से अप्रत्यक्ष privilege escalation का कारण बन सकता है। **Bash Command:** ```bash aws iam resync-mfa-device --user-name --serial-number \ --authentication-code1 --authentication-code2 ``` -**प्रभाव:** MFA devices को जोड़ने या हेरफेर करने से अप्रत्यक्ष privilege escalation। +**Impact:** Indirect privilege escalation — MFA devices जोड़ने या बदलने से। ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`) -इन अनुमतियों के साथ आप **SAML connection के XML metadata को बदल** सकते हैं। फिर, आप **SAML federation** का दुरुपयोग करके किसी भी **role जो उसे ट्रस्ट कर रहा हो** के साथ **login** कर सकते हैं। +इन permissions के साथ आप **change the XML metadata of the SAML connection** कर सकते हैं। फिर, आप **SAML federation** का दुरुपयोग करके किसी भी **role that is trusting** it के साथ **login** कर सकते हैं। -ध्यान दें कि ऐसा करने पर **legit users won't be able to login**। हालांकि, आप XML प्राप्त कर सकते हैं, अपना XML डालकर **login** कर सकते हैं और फिर पहले वाले को वापस कॉन्फ़िगर कर सकते हैं। +ध्यान दें कि ऐसा करने पर **legit users won't be able to login**। हालाँकि, आप XML प्राप्त कर सकते हैं, इसलिए आप अपनी XML डालकर **login** कर सकते हैं और पहले वाली स्थिति को वापस configure कर सकते हैं। ```bash # List SAMLs aws iam list-saml-providers @@ -211,11 +230,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: एक Tool जो SAML metadata जनरेट करने और एक निर्दिष्ट role के साथ login करने में सक्षम हो +> TODO: एक टूल जो SAML metadata जनरेट कर सके और एक निर्दिष्ट role के साथ लॉगिन कर सके ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**) -(इस बारे में सुनिश्चित नहीं) यदि किसी attacker के पास ये **permissions** हों तो वह provider पर trust करने वाले सभी **roles** में login करने के लिए नया **Thumbprint** जोड़ सकता है। +(इस बारे में सुनिश्चित नहीं) अगर attacker के पास ये **permissions** हों तो वह एक नया **Thumbprint** जोड़ सकता है जिससे वह उन सभी roles में लॉगिन कर सके जो provider पर भरोसा करते हैं। ```bash # List providers aws iam list-open-id-connect-providers @@ -226,7 +245,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar ``` ### `iam:PutUserPermissionsBoundary` -यह permission एक attacker को किसी user की permissions boundary को अपडेट करने की अनुमति देता है, जिससे संभावित रूप से उनके privileges escalate हो सकते हैं और वे उन actions को कर पाएंगे जो सामान्यतः उनके existing permissions द्वारा प्रतिबंधित होते हैं। +यह permission हमलावर को किसी user की permissions boundary अपडेट करने की अनुमति देता है, जिससे वे उन actions को कर सकते हैं जो सामान्यतः उनके existing permissions द्वारा प्रतिबंधित होते हैं। ```bash aws iam put-user-permissions-boundary \ --user-name \ @@ -249,7 +268,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 की क्षमताओं का विस्तार कर सकते हैं और escalate privileges कर सकते हैं। +iam:PutRolePermissionsBoundary वाले actor किसी मौजूदा role पर permissions boundary सेट कर सकता है। जोखिम तब उत्पन्न होता है जब इस permission वाला कोई व्यक्ति role की boundary बदलता है: वह गलत तरीके से operations को प्रतिबंधित कर सकता है (जिससे service disruption हो सकती है), या अगर वह permissive boundary संलग्न करता है तो प्रभावी रूप से role की क्षमताओं का विस्तार कर सकता है और escalate privileges कर सकता है। ```bash aws iam put-role-permissions-boundary \ --role-name \