AWS - IAM & STS Unauthenticated Enum
किसी खाते में 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 यह संदेश वापस कर सकता है:
यह संदेश भूमिका के अस्तित्व की पुष्टि करता है लेकिन यह संकेत देता है कि इसकी assume role नीति आपकी धारणा की अनुमति नहीं देती है। इसके विपरीत, एक गैर-मौजूद भूमिका को assume करने का प्रयास एक अलग त्रुटि की ओर ले जाता है:
दिलचस्प बात यह है कि मौजूद और गैर-मौजूद भूमिकाओं के बीच अंतर करने की यह विधि विभिन्न AWS खातों में भी लागू होती है। एक वैध AWS खाता आईडी और लक्षित शब्दसूची के साथ, कोई भी खाते में मौजूद भूमिकाओं को बिना किसी अंतर्निहित सीमाओं का सामना किए सूचीबद्ध कर सकता है।
आप इस script का उपयोग संभावित प्रिंसिपल्स को सूचीबद्ध करने के लिए कर सकते हैं इस समस्या का दुरुपयोग करते हुए।
Trust Policies: क्रॉस अकाउंट भूमिकाओं और उपयोगकर्ताओं को ब्रूट-फोर्स करना
एक IAM भूमिका की ट्रस्ट पॉलिसी को कॉन्फ़िगर या अपडेट करना इसमें परिभाषित करना शामिल है कि कौन से AWS संसाधन या सेवाएं उस भूमिका को ग्रहण करने और अस्थायी क्रेडेंशियल प्राप्त करने की अनुमति दी गई हैं। यदि नीति में निर्दिष्ट संसाधन मौजूद है, तो ट्रस्ट पॉलिसी सफलतापूर्वक सहेज ली जाती है। हालांकि, यदि संसाधन मौजूद नहीं है, तो एक त्रुटि उत्पन्न होती है, जो इंगित करती है कि एक अमान्य प्रिंसिपल प्रदान किया गया था।
ध्यान दें कि उस संसाधन में आप एक क्रॉस अकाउंट भूमिका या उपयोगकर्ता निर्दिष्ट कर सकते हैं:
arn:aws:iam::acc_id:role/role_name
arn:aws:iam::acc_id:user/user_name
यह एक नीति का उदाहरण है:
GUI
यह त्रुटि है जो आपको मिलेगी यदि आप ऐसी भूमिका का उपयोग करते हैं जो मौजूद नहीं है। यदि भूमिका मौजूद है, तो नीति बिना किसी त्रुटि के सहेजी जाएगी। (यह त्रुटि अद्यतन के लिए है, लेकिन यह निर्माण के समय भी काम करती है)
CLI
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 करने की अनुमति देता है:
अटैकर इसे मान सकता है।
Third Party OIDC Federation
कल्पना करें कि आप एक Github Actions workflow पढ़ने में सफल हो जाते हैं जो AWS के अंदर एक role को एक्सेस कर रहा है। यह ट्रस्ट निम्नलिखित trust policy के साथ एक role को एक्सेस दे सकता है:
यह ट्रस्ट पॉलिसी सही हो सकती है, लेकिन अधिक शर्तों की कमी आपको इसे अविश्वास करने के लिए मजबूर कर देनी चाहिए। यह इसलिए है क्योंकि पिछली भूमिका को Github Actions से कोई भी ग्रहण कर सकता है! आपको शर्तों में अन्य चीजें भी निर्दिष्ट करनी चाहिए जैसे कि org name, repo name, env, brach...
एक और संभावित गलत कॉन्फ़िगरेशन है एक शर्त जोड़ना जैसे निम्नलिखित:
ध्यान दें कि wildcard (*) colon (:) से पहले है। आप org_name1 जैसी एक org बना सकते हैं और Github Action से role assume कर सकते हैं।
संदर्भ
Last updated