AWS - IAM Post Exploitation

Reading time: 10 minutes

IAM

IAM access के बारे में अधिक जानकारी के लिए:

AWS - IAM, Identity Center & SSO Enum

Confused Deputy Problem

यदि आप एक external account (A) को अपने account के किसी role तक पहुँच की अनुमति देते हैं, तो संभवतः आपके पास यह देखने की कोई visibility नहीं होगी कि वास्तव में कौन उस external account तक पहुँच सकता है। यह एक समस्या है, क्योंकि यदि कोई अन्य external account (B) को external account (A) तक पहुँच है तो संभव है कि B भी आपके account तक पहुँच सके।

इसलिए, जब आप किसी external account को अपने account के role तक पहुँच देते हैं तो आप ExternalId निर्दिष्ट कर सकते हैं। यह एक "secret" string है जिसे external account (A) को आपकी organization में role assume करने के लिए specify करना होगा। चूँकि external account B इस string को नहीं जानता होगा, भले ही उसके पास A तक पहुँच हो, वह आपकी role तक पहुँच नहीं पाएगा।

हालाँकि, ध्यान दें कि यह ExternalId "secret" वास्तव में secret नहीं है; कोई भी जो IAM assume role policy पढ़ सकता है वह इसे देख सकेगा। लेकिन जब तक external account A इसे जानता है और external account B इसे नहीं जानता, यह B द्वारा A का दुरुपयोग करके आपकी role तक पहुँचने को रोकता है।

Example:

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "Example Corp's AWS Account ID"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345"
}
}
}
}

अनपेक्षित Trusts

Wildcard के रूप में principal

{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" }
}

यह नीति सभी AWS को भूमिका ग्रहण करने की अनुमति देती है।

सेवा को principal के रूप में

{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}

यह नीति किसी भी अकाउंट को अपने apigateway को इस Lambda को कॉल करने के लिए कॉन्फ़िगर करने की अनुमति देती है।

S3 को principal के रूप में

"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}

यदि किसी principal के रूप में S3 bucket दिया गया है — क्योंकि S3 buckets का कोई Account ID नहीं होता — और आपने अपने bucket को हटाया और attacker ने इसे अपने अकाउंट में बना लिया, तो वे इसका दुरुपयोग कर सकते हैं।

समर्थित नहीं

{
"Effect": "Allow",
"Principal": { "Service": "cloudtrail.amazonaws.com" },
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}

A common way to avoid Confused Deputy problems is the use of a condition with AWS:SourceArn to check the origin ARN. However, कुछ सेवाएँ इसे सपोर्ट नहीं कर सकतीं (कुछ स्रोतों के अनुसार जैसे CloudTrail)।

Credential Deletion

With any of the following permissions — iam:DeleteAccessKey, iam:DeleteLoginProfile, iam:DeleteSSHPublicKey, iam:DeleteServiceSpecificCredential, iam:DeleteInstanceProfile, iam:DeleteServerCertificate, iam:DeleteCloudFrontPublicKey, iam:RemoveRoleFromInstanceProfile — एक actor access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates या CloudFront public keys हटा सकता है, या roles को instance profiles से disassociate कर सकता है। ऐसे कार्य तुरंत वैध users और applications को ब्लॉक कर सकते हैं और उन systems के लिए denial-of-service या access खोने का कारण बन सकते हैं जो उन credentials पर निर्भर हैं, इसलिए इन IAM permissions को कड़ाई से restricted और monitored रखा जाना चाहिए।

# 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 क्रियाओं को कड़ाई से सीमित रखा जाना चाहिए और उन पर निगरानी रखी जानी चाहिए।

# 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 मॉडल को बदल सकता है, जिससे उन principals के लिए जिनकी निर्भरता उन नीतियों पर थी तात्कालिक पहुँच खोना या denial-of-service हो सकता है, इसलिए इन IAM actions को कड़ाई से सीमित और monitored किया जाना चाहिए।

# 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 identity providers को हटा सकता है या client IDs को निकाल सकता है। इससे फेडरेटेड authentication टूट जाती है, token सत्यापन रुकता है और जिन users और services का भरोसा SSO पर है उनकी पहुँच तुरंत अस्वीकार कर दी जाती है जब तक कि IdP या कॉन्फ़िगरेशन बहाल न किए जाएँ।

# 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 सक्रियकरण

iam:EnableMFADevice के साथ, एक हमलावर किसी उपयोगकर्ता की पहचान पर एक MFA device रजिस्टर कर सकता है, जिससे वैध उपयोगकर्ता का साइन-इन रोका जा सकता है। एक बार जब एक अनधिकृत MFA सक्षम हो जाता है, तो उपयोगकर्ता तब तक लॉक आउट हो सकता है जब तक device हटाया या रीसेट न किया जाए (नोट: यदि कई MFA devices रजिस्टर्ड हैं, तो साइन-इन के लिए केवल एक ही आवश्यक होता है, इसलिए यह हमला एक्सेस रोकने पर कोई प्रभाव नहीं डालेगा)।

aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012

प्रमाणपत्र/कुंजी मेटाडेटा छेड़छाड़

iam:UpdateSSHPublicKey, iam:UpdateCloudFrontPublicKey, iam:UpdateSigningCertificate, iam:UpdateServerCertificate के साथ, एक हमलावर सार्वजनिक कुंजियों और प्रमाणपत्रों की स्थिति या मेटाडेटा बदल सकता है। कुंजियों/प्रमाणपत्रों को निष्क्रिय चिह्नित करके या संदर्भ बदलकर, वे SSH प्रमाणीकरण को तोड़ सकते हैं, X.509/TLS सत्यापन को अमान्य कर सकते हैं, और तुरंत उन सेवाओं को बाधित कर सकते हैं जो उन क्रेडेंशियल्स पर निर्भर हैं, जिससे पहुँच या उपलब्धता का नुकसान हो सकता है।

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/

iam:Delete*

The IAM wildcard iam:Delete* कई प्रकार के IAM resources — users, roles, groups, policies, keys, certificates, MFA devices, policy versions, आदि — को हटाने की क्षमता प्रदान करता है — and therefore has a very high blast radius: जिसे iam:Delete* दिया गया है वह identities, credentials, policies और संबंधित artifacts को स्थायी रूप से नष्ट कर सकता है, audit/evidence को हटा सकता है, और सेवा या संचालन में व्यवधान पैदा कर सकता है। कुछ उदाहरण हैं

# Delete a user
aws iam delete-user --user-name <Username>

# Delete a role
aws iam delete-role --role-name <RoleName>

# Delete a managed policy
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>

iam:EnableMFADevice

जिसे iam:EnableMFADevice action दिया गया हो, वह अकाउंट में किसी identity के लिए एक MFA device register कर सकता है, बशर्ते उस user के पास पहले से कोई enabled न हो। इसे user के access में हस्तक्षेप करने के लिए इस्तेमाल किया जा सकता है: एक बार attacker ने MFA device register कर दिया, तो legitimate user को signing in करने से रोका जा सकता है क्योंकि वे attacker-registered MFA को नियंत्रित नहीं करते।

यह denial-of-access attack केवल तभी काम करता है जब user के पास पहले कोई MFA registered न हो; अगर attacker उस user के लिए MFA device register कर देता है, तो legitimate user उन किसी भी flows से locked out हो जाएगा जिन्हें उस नए MFA की आवश्यकता होती है। यदि user के पास पहले से एक या अधिक MFA devices उनके नियंत्रण में हैं, तो attacker-controlled MFA जोड़ने से legitimate user अवरुद्ध नहीं होगा — वे किसी भी मौजूदा MFA का उपयोग करके authenticate करना जारी रख सकते हैं।

एक user के लिए MFA device enable (register) करने के लिए attacker निम्न चला सकता है:

aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012

संदर्भ

• https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html