AWS - IAM & STS Unauthenticated Enum

Reading time: 6 minutes

खाते में Roles और Usernames को सूचीबद्ध करना

Assume Role Brute-Force

यदि आप assume a role without the necessary permissions करने का प्रयास करते हैं तो यह एक AWS त्रुटि संदेश उत्पन्न करता है। उदाहरण के लिए, यदि unauthorized है, AWS यह लौटा सकता है:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS

यह संदेश role के अस्तित्व की पुष्टि करता है लेकिन यह बताता है कि उसकी assume role policy आपको assume करने की अनुमति नहीं देती। इसके विपरीत, non-existent role को assume करने का प्रयास एक अलग त्रुटि उत्पन्न करता है:

An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole

दिलचस्प बात यह है कि यह तरीका existing और non-existing roles के बीच अंतर पहचानने के लिए अलग-अलग AWS accounts में भी लागू होता है। एक वैध AWS account ID और लक्षित wordlist के साथ, कोई बिना किसी अंतर्निहित प्रतिबंध के account में मौजूद roles को enumerate कर सकता है।

आप इस script to enumerate potential principals का उपयोग इस issue का दुरुपयोग करने के लिए कर सकते हैं।

Trust Policies: Brute-Force Cross Account roles and users

एक IAM role की trust policy को कॉन्फ़िगर या अपडेट करने में यह परिभाषित किया जाता है कि कौन से AWS resources या services उस role को assume करने और temporary credentials प्राप्त करने की अनुमति रखते हैं। यदि policy में निर्दिष्ट resource exists, तो trust policy successfully सहेज ली जाती है। हालांकि, यदि resource does not exist, तो एक error is generated होती है, जो इंगित करती है कि एक अवैध principal प्रदान किया गया था।

यह एक policy उदाहरण है:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::216825089941:role/Test"
},
"Action": "sts:AssumeRole"
}
]
}

GUI

यह वही त्रुटि है जिसे आप तब पाएँगे यदि आप किसी ऐसे role का उपयोग करते हैं जो मौजूद नहीं है। यदि role मौजूद है, तो policy बिना किसी त्रुटि के सहेज दी जाएगी। (यह त्रुटि अपडेट के लिए है, लेकिन यह बनाने के समय भी काम करती है)

CLI

### You could also use: aws iam update-assume-role-policy
# When it works
aws iam create-role --role-name Test-Role --assume-role-policy-document file://a.json
{
"Role": {
"Path": "/",
"RoleName": "Test-Role",
"RoleId": "AROA5ZDCUJS3DVEIYOB73",
"Arn": "arn:aws:iam::947247140022:role/Test-Role",
"CreateDate": "2022-05-03T20:50:04Z",
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::316584767888:role/account-balance"
},
"Action": [
"sts:AssumeRole"
]
}
]
}
}
}

# When it doesn't work
aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json
An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2"

आप इस प्रक्रिया को https://github.com/carlospolop/aws_tools के साथ स्वचालित कर सकते हैं

• bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt

या Pacu का उपयोग करके:

• run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
• run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
• उदाहरण के लिए उपयोग किया गया admin role आपके खाते का वह role है जिसे pacu द्वारा impersonate किया जाता है ताकि यह enumeration के लिए आवश्यक policies बना सके

Privesc

यदि role गलत तरीके से कॉन्फ़िगर किया गया है और किसी को भी इसे assume करने की अनुमति देता है:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole"
}
]
}

हमलावर बस इसे ग्रहण कर सकता है।

तृतीय-पक्ष OIDC Federation

कल्पना कीजिए कि आप किसी Github Actions workflow को पढ़ने में सक्षम हो जाते हैं जो AWS के अंदर एक role तक पहुँच रहा है.\ यह ट्रस्ट निम्नलिखित trust policy के साथ एक role तक पहुँच दे सकता है:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<acc_id>:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}

यह trust policy सही हो सकती है, लेकिन अधिक शर्तों की कमी आपको इसे अविश्वसनीय समझने के लिए प्रेरित करनी चाहिए.
यह इसलिए है कि पिछला role Github Actions से कोई भी assume कर सकता है! आपको conditions में org name, repo name, env, brach... जैसी अन्य चीज़ें भी specify करनी चाहिए...

एक और संभावित misconfiguration यह है कि आप निम्नलिखित जैसी एक शर्त जोड़ दें:

"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
}

ध्यान दें कि wildcard (*) कोलन (:) से पहले है। आप org_name1 जैसे एक org बना सकते हैं और Github Action से assume the role कर सकते हैं।

संदर्भ

• https://www.youtube.com/watch?v=8ZXRw4Ry3mQ
• https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/