AWS - IAM Post Exploitation

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

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

IAM

IAM एक्सेस के बारे में अधिक जानकारी के लिए:

pageAWS - IAM, Identity Center & SSO Enum

Confused Deputy Problem

यदि आप एक बाहरी खाते (A) को अपने खाते में एक रोल तक पहुंचने की अनुमति देते हैं, तो आपके पास शायद 0 दृश्यता होगी कि कौन वास्तव में उस बाहरी खाते तक पहुंच सकता है. यह एक समस्या है, क्योंकि यदि कोई अन्य बाहरी खाता (B) बाहरी खाते (A) तक पहुंच सकता है, तो संभव है कि B भी आपके खाते तक पहुंच सकता है.

इसलिए, जब आप एक बाहरी खाते को अपने खाते में एक रोल तक पहुंचने की अनुमति देते हैं, तो आप ExternalId निर्दिष्ट कर सकते हैं. यह एक "गुप्त" स्ट्रिंग है जिसे बाहरी खाता (A) निर्दिष्ट करने की आवश्यकता है ताकि आपके संगठन में रोल को मान लिया जा सके. चूंकि बाहरी खाता B इस स्ट्रिंग को नहीं जानता है, इसलिए यदि उसके पास A पर पहुंच है तो भी वह आपके रोल तक पहुंचने में सक्षम नहीं होगा.

हालांकि, ध्यान दें कि यह ExternalId "गुप्त" एक गुप्त नहीं है, जो कोई भी IAM अस्यूम रोल पॉलिसी को पढ़ सकता है वह इसे देख सकता है. लेकिन जब तक बाहरी खाता A इसे जानता है, लेकिन बाहरी खाता B इसे नहीं जानता है, यह B को A का दुरुपयोग करके आपके रोल तक पहुंचने से रोकता है.

उदाहरण:

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "Example Corp's AWS Account ID"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345"
}
}
}
}

एक हमलावर के लिए एक भ्रमित डेप्युटी का शोषण करने के लिए, उसे यह पता लगाना होगा कि क्या वर्तमान खाते के प्रिंसिपल्स दूसरे खातों में रोल्स का अनुकरण कर सकते हैं।

अनपेक्षित विश्वास

प्रिंसिपल के रूप में वाइल्डकार्ड

{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" },
}

यह नीति सभी AWS को भूमिका ग्रहण करने की अनुमति देती है।

सेवा मुख्य रूप में

{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}

यह नीति किसी भी खाते को अनुमति देती है अपने apigateway को इस Lambda को कॉल करने के लिए कॉन्फ़िगर करने के लिए।

S3 को प्रिंसिपल के रूप में

"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}

यदि एक S3 बकेट को प्रिंसिपल के रूप में दिया गया है, क्योंकि S3 बकेट्स के पास एक Account ID नहीं होती है, अगर आपने अपना बकेट हटा दिया और हमलावर ने इसे अपने खाते में बना लिया, तो वे इसका दुरुपयोग कर सकते हैं।

समर्थित नहीं है

{
"Effect": "Allow",
"Principal": {"Service": "cloudtrail.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}

Confused Deputy समस्याओं से बचने का एक सामान्य तरीका AWS:SourceArn के साथ एक शर्त का उपयोग करना है जो मूल ARN की जांच करता है। हालांकि, कुछ सेवाएं इसका समर्थन नहीं कर सकती हैं (जैसे कि कुछ स्रोतों के अनुसार CloudTrail).

संदर्भ

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

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

Last updated