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