# AWS - Secrets Manager Post Exploitation {{#include ../../../banners/hacktricks-training.md}} ## Secrets Manager For more information check: {{#ref}} ../aws-services/aws-secrets-manager-enum.md {{#endref}} ### Read Secrets The **secrets themselves संवेदनशील जानकारी हैं**, इन्हें कैसे पढ़ना है यह जानने के लिए [check the privesc page](../aws-privilege-escalation/aws-secrets-manager-privesc.md)। ### DoS Change Secret Value Secret के value को बदलकर आप उस value पर निर्भर सभी सिस्टम्स को **DoS** कर सकते हैं। > [!WARNING] > ध्यान दें कि पिछली values भी संग्रहीत रहती हैं, इसलिए पहले की value पर आसानी से वापस जाना संभव है। ```bash # Requires permission secretsmanager:PutSecretValue aws secretsmanager put-secret-value \ --secret-id MyTestSecret \ --secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}" ``` ### DoS: KMS key बदलना यदि attacker के पास secretsmanager:UpdateSecret permission है, तो वे secret को attacker के-owned KMS key का उपयोग करने के लिए configure कर सकते हैं। वह key प्रारम्भ में इस तरह set up की जाती है कि कोई भी उसे access और use कर सके, इसलिए secret को नए key के साथ update करना possible होता है। यदि वह key accessible नहीं होती, तो secret को update नहीं किया जा सकता था। secret के लिए key बदलने के बाद, attacker अपनी key की configuration इस तरह modify कर देता है कि केवल वही उसे access कर सके। इस तरह, secret के subsequent versions नई key से encrypted होंगे, और चूंकि उस key तक कोई access नहीं होगा, secret को retrieve करने की ability खो जाएगी। यह ध्यान देने योग्य है कि यह पहुँच बंद होना केवल बाद के versions में ही होगा, जब secret की content बदल जाएगी, क्योंकि current version अभी भी original KMS key से encrypted है। ```bash aws secretsmanager update-secret \ --secret-id MyTestSecret \ --kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE ``` ### DoS Secret को डिलीट करना किसी Secret को डिलीट करने के लिए न्यूनतम अवधि 7 दिन है ```bash aws secretsmanager delete-secret \ --secret-id MyTestSecret \ --recovery-window-in-days 7 ``` ## secretsmanager:RestoreSecret एक secret को पुनर्स्थापित करना संभव है, जो उन secrets की बहाली की अनुमति देता है जो deletion के लिए शेड्यूल किए गए हैं, क्योंकि secrets के लिए न्यूनतम deletion अवधि 7 days है और अधिकतम 30 days है। secretsmanager:GetSecretValue permission के साथ मिलकर, इससे उनके contents को प्राप्त करना संभव हो जाता है। जिस secret को हटाए जाने की प्रक्रिया में है उसे recover करने के लिए, आप निम्नलिखित command का उपयोग कर सकते हैं: ```bash aws secretsmanager restore-secret \ --secret-id ``` ## secretsmanager:DeleteResourcePolicy यह क्रिया उस resource policy को हटाने की अनुमति देती है जो नियंत्रित करती है कि कौन किसी secret तक पहुँच सकता है। यदि resource policy को किसी विशिष्ट उपयोगकर्ताओं के समूह को पहुँच देने के लिए कॉन्फ़िगर किया गया था तो इससे DoS हो सकता है। resource policy को हटाने के लिए: ```bash aws secretsmanager delete-resource-policy \ --secret-id ``` ## secretsmanager:UpdateSecretVersionStage एक secret की states का उपयोग secret के versions का प्रबंधन करने के लिए किया जाता है। AWSCURRENT उस सक्रिय संस्करण को चिह्नित करता है जिसे एप्लिकेशन उपयोग करते हैं, AWSPREVIOUS पिछला संस्करण रखता है ताकि आवश्यक होने पर आप रोलबैक कर सकें, और AWSPENDING rotation प्रक्रिया में एक नए संस्करण को वर्तमान बनाने से पहले उसे तैयार और मान्य करने के लिए उपयोग होता है। एप्लिकेशन हमेशा AWSCURRENT वाले संस्करण को पढ़ते हैं। यदि कोई उस लेबल को गलत संस्करण पर स्थानांतरित कर देता है, तो ऐप्स अमान्य क्रेडेंशियल्स का उपयोग करेंगे और विफल हो सकते हैं। AWSPREVIOUS स्वतः उपयोग में नहीं आता। हालांकि, यदि AWSCURRENT हटा दिया जाता है या गलत तरीके से पुनः असाइन किया जाता है, तो ऐसा लग सकता है कि सब कुछ अभी भी पिछले संस्करण के साथ चल रहा है। ```bash aws secretsmanager update-secret-version-stage \ --secret-id \ --version-stage AWSCURRENT \ --move-to-version-id \ --remove-from-version-id ``` {{#include ../../../banners/hacktricks-training.md}} ### Mass Secret Exfiltration via BatchGetSecretValue (up to 20 per call) Secrets Manager के BatchGetSecretValue API का दुरुपयोग करके एक ही अनुरोध में 20 तक secrets पुनःप्राप्त करें। यह प्रति-secret GetSecretValue को बार-बार चलाने की तुलना में API-कॉल की मात्रा को काफी कम कर सकता है। यदि --filters (tags/name) का उपयोग किया जाता है तो ListSecrets permission भी आवश्यक है। CloudTrail फिर भी बैच से पुनःप्राप्त प्रत्येक secret के लिए एक GetSecretValue इवेंट रिकॉर्ड करता है। Required permissions - secretsmanager:BatchGetSecretValue - secretsmanager:GetSecretValue प्रत्येक लक्षित secret के लिए - secretsmanager:ListSecrets अगर --filters का उपयोग कर रहे हों - kms:Decrypt उन CMKs पर जो secrets के लिए उपयोग किए गए हैं (यदि aws/secretsmanager का उपयोग नहीं कर रहे हैं) > [!WARNING] > ध्यान दें कि permission `secretsmanager:BatchGetSecretValue` अकेला secrets पुनःप्राप्त करने के लिए पर्याप्त नहीं है; आपको उन प्रत्येक secret को पुनःप्राप्त करने के लिए `secretsmanager:GetSecretValue` भी चाहिए। Exfiltrate by explicit list ```bash aws secretsmanager batch-get-secret-value \ --secret-id-list \ --query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}' ``` Exfiltrate फ़िल्टर के द्वारा (tag key/value या name prefix) ```bash # By tag key aws secretsmanager batch-get-secret-value \ --filters Key=tag-key,Values=env \ --max-results 20 \ --query 'SecretValues[].{Name:Name,Val:SecretString}' # By tag value aws secretsmanager batch-get-secret-value \ --filters Key=tag-value,Values=prod \ --max-results 20 # By name prefix aws secretsmanager batch-get-secret-value \ --filters Key=name,Values=MyApp ``` आंशिक विफलताओं का प्रबंधन ```bash # Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters aws secretsmanager batch-get-secret-value --secret-id-list ``` प्रभाव - कम API कॉल्स के साथ कई secrets का तेज़ “smash-and-grab”, जो संभावित रूप से GetSecretValue में स्पाइक्स के लिए ट्यून किए गए अलर्टिंग को बायपास कर सकता है। - CloudTrail लॉग्स अभी भी बैच द्वारा प्राप्त प्रत्येक secret के लिए एक GetSecretValue इवेंट शामिल करते हैं।