AWS - STS Privesc

Reading time: 7 minutes

STS

sts:AssumeRole

प्रत्येक role को एक role trust policy के साथ बनाया जाता है, यह policy यह बताती है कि who can assume the created role। यदि किसी same account का role कहता है कि किसी account द्वारा उसे assume किया जा सकता है, तो इसका मतलब है कि वह account उस role तक access प्राप्त कर सकेगा (और संभावित रूप से privesc)।

उदाहरण के लिए, निम्नलिखित role trust policy संकेत करती है कि कोई भी इसे assume कर सकता है, इसलिए any user will be able to privesc उन permissions तक जो उस role से जुड़ी हैं।

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole"
}
]
}

आप निम्नलिखित चलाकर किसी role को impersonate कर सकते हैं:

aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname

संभावित प्रभाव: Privesc to the role.

sts:AssumeRoleWithSAML

एक trust policy इस role के साथ SAML के माध्यम से authenticated users को role का impersonate करने की access देती है।

इस permission के साथ एक trust policy का एक उदाहरण है:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "OneLogin",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}

role को impersonate करने के लिए credentials जनरेट करने हेतु सामान्यतः आप कुछ ऐसा उपयोग कर सकते हैं:

aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>

लेकिन providers के पास इसे आसान बनाने के लिए अपने own tools हो सकते हैं, जैसे onelogin-aws-assume-role:

onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600

संभावित प्रभाव: Privesc to the role.

sts:AssumeRoleWithWebIdentity

यह अनुमति एक वेब identity provider के साथ उपयोगकर्ता जो mobile, web application, EKS... में प्रमाणीकृत हैं के लिए अस्थायी सुरक्षा क्रेडेंशियल्स का एक सेट प्राप्त करने की अनुमति देती है। यहाँ और पढ़ें.

उदाहरण के लिए, यदि एक EKS service account को एक IAM role का impersonate करने में सक्षम होना चाहिए, तो उसके पास /var/run/secrets/eks.amazonaws.com/serviceaccount/token में एक token होगा और वह कुछ इस तरह कर के assume the role and get credentials कर सकता है:

aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
# The role name can be found in the metadata of the configuration of the pod

Federation Abuse

AWS - Federation Abuse

IAM Roles Anywhere Privesc

AWS IAM RolesAnywhere बाहरी workloads को X.509 प्रमाणपत्रों का उपयोग करके IAM roles assume करने की अनुमति देता है। लेकिन जब trust policies को ठीक से scope नहीं किया गया होता है, तो इन्हें privilege escalation के लिए abused किया जा सकता है।

इस attack को समझने के लिए यह आवश्यक है कि trust anchor क्या है यह समझाया जाए। AWS IAM RolesAnywhere में एक trust anchor root of trust entity होता है; इसमें उस Certificate Authority (CA) का public certificate शामिल होता है जो account में registered होता है ताकि AWS प्रस्तुत किए गए X.509 प्रमाणपत्रों को validate कर सके। इस तरह, यदि client certificate उसी CA द्वारा जारी किया गया है और trust anchor सक्रिय है, तो AWS उसे वैध के रूप में पहचानता है।

इसके अलावा, एक profile वह configuration है जो परिभाषित करता है कि X.509 प्रमाणपत्र के कौन से attributes (जैसे CN, OU, या SAN) session tags में बदले जाएंगे, और बाद में ये tags trust policy की conditions के खिलाफ तुलना किए जाएंगे।

इस policy में यह प्रतिबंध नहीं है कि किन trust anchor या certificate attributes को अनुमति है। परिणामस्वरूप, account में किसी भी trust anchor से जुड़ा कोई भी certificate इस role को assume करने के लिए इस्तेमाल किया जा सकता है।

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
]
}
]
}

privesc के लिए aws_signing_helper आवश्यक है: https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html

फिर मान्य प्रमाणपत्र का उपयोग करके attacker higher privilege role में pivot कर सकता है

aws_signing_helper credential-process \
--certificate readonly.pem \
--private-key readonly.key \
--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin

ट्रस्ट एंकर यह प्रमाणित करता है कि क्लाइंट का readonly.pem certificate उसके authorized CA से आया है, और इसी readonly.pem certificate के अंदर वह public key होता है जिसका उपयोग AWS यह सत्यापित करने के लिए करता है कि signature उसके संबंधित private key readonly.key से बनाया गया था।

यह certificate अन्य attributes (जैसे CN या OU) भी प्रदान करता है जिन्हें default profile tags में बदल देता है, जिन्हें role’s trust policy यह तय करने के लिए उपयोग कर सकती है कि access authorize करना है या नहीं। अगर trust policy में कोई conditions नहीं हैं, तो उन tags का कोई उपयोग नहीं होता, और वैध certificate रखने वाले किसी भी व्यक्ति को access दे दिया जाता है।

इस attack के सम्भव होने के लिए दोनों, trust anchor और default profile को active होना चाहिए।

संदर्भ

• https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation