AWS - IAM & STS Unauthenticated Enum

HackTricks को समर्थन दें

किसी खाते में Roles और Usernames को Enumerate करें

Assume Role Brute-Force

यह तकनीक अब काम नहीं करती क्योंकि यदि role मौजूद है या नहीं, तो आपको हमेशा यह त्रुटि मिलती है:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas

आप इसे परीक्षण कर सकते हैं:

aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example

आवश्यक अनुमतियों के बिना role को assume करने का प्रयास करने पर 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

यह संदेश भूमिका के अस्तित्व की पुष्टि करता है लेकिन यह संकेत देता है कि इसकी assume role नीति आपकी धारणा की अनुमति नहीं देती है। इसके विपरीत, एक गैर-मौजूद भूमिका को assume करने का प्रयास एक अलग त्रुटि की ओर ले जाता है:

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

दिलचस्प बात यह है कि मौजूद और गैर-मौजूद भूमिकाओं के बीच अंतर करने की यह विधि विभिन्न AWS खातों में भी लागू होती है। एक वैध AWS खाता आईडी और लक्षित शब्दसूची के साथ, कोई भी खाते में मौजूद भूमिकाओं को बिना किसी अंतर्निहित सीमाओं का सामना किए सूचीबद्ध कर सकता है।

आप इस script का उपयोग संभावित प्रिंसिपल्स को सूचीबद्ध करने के लिए कर सकते हैं इस समस्या का दुरुपयोग करते हुए।

Trust Policies: क्रॉस अकाउंट भूमिकाओं और उपयोगकर्ताओं को ब्रूट-फोर्स करना

एक IAM भूमिका की ट्रस्ट पॉलिसी को कॉन्फ़िगर या अपडेट करना इसमें परिभाषित करना शामिल है कि कौन से AWS संसाधन या सेवाएं उस भूमिका को ग्रहण करने और अस्थायी क्रेडेंशियल प्राप्त करने की अनुमति दी गई हैं। यदि नीति में निर्दिष्ट संसाधन मौजूद है, तो ट्रस्ट पॉलिसी सफलतापूर्वक सहेज ली जाती है। हालांकि, यदि संसाधन मौजूद नहीं है, तो एक त्रुटि उत्पन्न होती है, जो इंगित करती है कि एक अमान्य प्रिंसिपल प्रदान किया गया था।

ध्यान दें कि उस संसाधन में आप एक क्रॉस अकाउंट भूमिका या उपयोगकर्ता निर्दिष्ट कर सकते हैं:

  • arn:aws:iam::acc_id:role/role_name

  • arn:aws:iam::acc_id:user/user_name

यह एक नीति का उदाहरण है:

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

GUI

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

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"

You can automate this process with 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 के लिए बनाने की आवश्यकता है

Privesc

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

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

अटैकर इसे मान सकता है।

Third Party 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"
}
}
}
]
}

यह ट्रस्ट पॉलिसी सही हो सकती है, लेकिन अधिक शर्तों की कमी आपको इसे अविश्वास करने के लिए मजबूर कर देनी चाहिए। यह इसलिए है क्योंकि पिछली भूमिका को Github Actions से कोई भी ग्रहण कर सकता है! आपको शर्तों में अन्य चीजें भी निर्दिष्ट करनी चाहिए जैसे कि org name, repo name, env, brach...

एक और संभावित गलत कॉन्फ़िगरेशन है एक शर्त जोड़ना जैसे निम्नलिखित:

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

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

संदर्भ

HackTricks को समर्थन दें

Last updated