AWS - IAM & STS Unauthenticated Enum
PreviousAWS - Elasticsearch Unauthenticated EnumNextAWS - Identity Center & SSO Unauthenticated Enum
Last updated
Last updated
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
यह तकनीक अब काम नहीं करती क्योंकि यदि भूमिका मौजूद है या नहीं, तो आपको हमेशा यह त्रुटि मिलती है:
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 यह वापस कर सकता है:
यह संदेश भूमिका के अस्तित्व की पुष्टि करता है लेकिन यह संकेत करता है कि इसकी असुमे भूमिका नीति आपकी असुमेशन की अनुमति नहीं देती। इसके विपरीत, एक गैर-मौजूद भूमिका को असुम करने की कोशिश करने से एक अलग त्रुटि होती है:
दिलचस्प बात यह है कि मौजूदा और गैर-मौजूदा भूमिकाओं के बीच अंतर करने की यह विधि विभिन्न AWS खातों में भी लागू होती है। एक मान्य AWS खाता आईडी और एक लक्षित शब्द सूची के साथ, कोई भी खाते में मौजूद भूमिकाओं को बिना किसी अंतर्निहित सीमाओं का सामना किए सूचीबद्ध कर सकता है।
आप इस स्क्रिप्ट का उपयोग करके संभावित प्रिंसिपल्स को सूचीबद्ध कर सकते हैं इस समस्या का दुरुपयोग करते हुए।
एक IAM भूमिका की ट्रस्ट नीति को कॉन्फ़िगर या अपडेट करना उस AWS संसाधन या सेवा को परिभाषित करने में शामिल होता है जिसे उस भूमिका को ग्रहण करने की अनुमति है और अस्थायी क्रेडेंशियल प्राप्त करना। यदि नीति में निर्दिष्ट संसाधन मौजूद है, तो ट्रस्ट नीति सफलता से सहेजी जाती है। हालाँकि, यदि संसाधन मौजूद नहीं है, तो एक त्रुटि उत्पन्न होती है, जो बताती है कि एक अमान्य प्रिंसिपल प्रदान किया गया था।
ध्यान दें कि उस संसाधन में आप एक क्रॉस अकाउंट भूमिका या उपयोगकर्ता निर्दिष्ट कर सकते हैं:
arn:aws:iam::acc_id:role/role_name
arn:aws:iam::acc_id:user/user_name
यह एक नीति का उदाहरण है:
यदि आप ऐसी भूमिका का उपयोग करते हैं जो मौजूद नहीं है, तो यह त्रुटि आपको मिलेगी। यदि भूमिका मौजूद है, तो नीति बिना किसी त्रुटि के सहेजी जाएगी। (त्रुटि अपडेट के लिए है, लेकिन यह बनाने के समय भी काम करती है)
आप इस प्रक्रिया को स्वचालित कर सकते हैं 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 के लिए आवश्यक नीतियों को बना सके
यदि भूमिका गलत तरीके से कॉन्फ़िगर की गई है और किसी को भी इसे मानने की अनुमति देती है:
The attacker could just assume it.
कल्पना करें कि आप एक Github Actions workflow पढ़ने में सफल होते हैं जो AWS के अंदर एक role तक पहुँच रहा है। यह विश्वास एक भूमिका तक पहुँच प्रदान कर सकता है जिसमें निम्नलिखित trust policy है:
यह ट्रस्ट नीति सही हो सकती है, लेकिन अधिक शर्तों की कमी आपको इसे अविश्वास करने के लिए मजबूर करनी चाहिए। यह इसलिए है क्योंकि पिछले भूमिका को Github Actions से कोई भी मान लिया जा सकता है! आपको शर्तों में अन्य चीजें भी निर्दिष्ट करनी चाहिए जैसे कि संगठन का नाम, रिपॉजिटरी का नाम, वातावरण, शाखा...
एक और संभावित गलत कॉन्फ़िगरेशन है एक शर्त जोड़ना जैसे कि निम्नलिखित:
ध्यान दें कि वाइल्डकार्ड (*) कोलन (:) से पहले है। आप org_name1 जैसे एक संगठन बना सकते हैं और एक Github Action से भूमिका ग्रहण कर सकते हैं।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
