AWS - IAM Post Exploitation
IAM
IAM एक्सेस के बारे में अधिक जानकारी के लिए:
AWS - IAM, Identity Center & SSO EnumConfused Deputy Problem
यदि आप किसी बाहरी खाते (A) को अपने खाते में role एक्सेस करने की अनुमति देते हैं, तो आपके पास 0 visibility होगी कि कौन वास्तव में उस बाहरी खाते तक पहुंच सकता है। यह एक समस्या है, क्योंकि यदि कोई अन्य बाहरी खाता (B) बाहरी खाते (A) तक पहुंच सकता है, तो यह संभव है कि B भी आपके खाते तक पहुंच सके।
इसलिए, जब किसी बाहरी खाते को आपके खाते में एक role एक्सेस करने की अनुमति दी जाती है, तो ExternalId
निर्दिष्ट करना संभव है। यह एक "गुप्त" स्ट्रिंग है जिसे बाहरी खाते (A) को आपके संगठन में role को assume करने के लिए निर्दिष्ट करना आवश्यक है। चूंकि बाहरी खाता B इस स्ट्रिंग को नहीं जानता, भले ही उसके पास A पर पहुंच हो, वह आपके role तक पहुंचने में सक्षम नहीं होगा।
हालांकि, ध्यान दें कि यह ExternalId
"गुप्त" गुप्त नहीं है, कोई भी जो IAM assume role policy को पढ़ सकता है, इसे देख सकेगा। लेकिन जब तक बाहरी खाता A इसे जानता है, लेकिन बाहरी खाता B इसे नहीं जानता, यह B को A का दुरुपयोग करके आपके role तक पहुंचने से रोकता है।
उदाहरण:
एक हमलावर को एक confused deputy का शोषण करने के लिए यह पता लगाना होगा कि क्या वर्तमान खाते के प्रिंसिपल अन्य खातों में भूमिकाओं का प्रतिरूपण कर सकते हैं।
अप्रत्याशित ट्रस्ट्स
प्रिंसिपल के रूप में वाइल्डकार्ड
यह नीति सभी AWS को भूमिका ग्रहण करने की अनुमति देती है।
Service as principal
यह नीति किसी भी खाते को अनुमति देती है कि वे अपने apigateway को इस Lambda को कॉल करने के लिए कॉन्फ़िगर कर सकें।
S3 as principal
यदि एक S3 बकेट को एक प्रिंसिपल के रूप में दिया गया है, क्योंकि S3 बकेट्स के पास एक अकाउंट ID नहीं होती है, अगर आपने अपना बकेट डिलीट कर दिया और हमलावर ने इसे अपने अकाउंट में बना लिया, तो वे इसका दुरुपयोग कर सकते हैं।
समर्थित नहीं है
Confused Deputy समस्याओं से बचने का एक सामान्य तरीका AWS:SourceArn
के साथ एक condition का उपयोग करना है ताकि origin ARN की जांच की जा सके। हालांकि, कुछ सेवाएं इसका समर्थन नहीं कर सकती हैं (जैसे कि कुछ स्रोतों के अनुसार CloudTrail)।
References
Last updated