AWS - STS Privesc

Support HackTricks

STS

sts:AssumeRole

Każda rola jest tworzona z polityką zaufania roli, ta polityka wskazuje kto może przyjąć utworzoną rolę. Jeśli rola z tego samego konta mówi, że inne konto może ją przyjąć, oznacza to, że to konto będzie mogło uzyskać dostęp do roli (i potencjalnie privesc).

Na przykład, poniższa polityka zaufania roli wskazuje, że każdy może ją przyjąć, dlatego każdy użytkownik będzie mógł privesc do uprawnień związanych z tą rolą.

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

Możesz udawać rolę działającą:

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

Potencjalny wpływ: Privesc do roli.

Zauważ, że w tym przypadku uprawnienie sts:AssumeRole musi być określone w roli do nadużycia a nie w polityce należącej do atakującego. Z jednym wyjątkiem, aby przyjąć rolę z innego konta konto atakującego również musi mieć sts:AssumeRole nad rolą.

sts:GetFederationToken

Dzięki temu uprawnieniu możliwe jest wygenerowanie poświadczeń do podszywania się pod dowolnego użytkownika:

aws sts get-federation-token --name <username>

To jest sposób, w jaki to uprawnienie można przyznać bezpiecznie, nie dając dostępu do podszywania się pod innych użytkowników:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "arn:aws:sts::947247140022:federated-user/${aws:username}"
}
]
}

sts:AssumeRoleWithSAML

Polityka zaufania z tą rolą przyznaje użytkownikom uwierzytelnionym za pomocą SAML dostęp do podszywania się pod rolę.

Przykład polityki zaufania z tym uprawnieniem to:

{
"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"
}
}
}
]
}

Aby wygenerować poświadczenia do podszywania się pod rolę, ogólnie możesz użyć czegoś takiego:

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

Ale dostawcy mogą mieć własne narzędzia, aby to ułatwić, takie jak onelogin-aws-assume-role:

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

Potencjalny wpływ: Privesc do roli.

sts:AssumeRoleWithWebIdentity

To uprawnienie przyznaje pozwolenie na uzyskanie zestawu tymczasowych poświadczeń bezpieczeństwa dla użytkowników, którzy zostali uwierzytelnieni w aplikacji mobilnej, aplikacji webowej, EKS... z dostawcą tożsamości webowej. Dowiedz się więcej tutaj.

Na przykład, jeśli konto usługi EKS powinno być w stanie udawać rolę IAM, będzie miało token w /var/run/secrets/eks.amazonaws.com/serviceaccount/token i może przyjąć rolę i uzyskać poświadczenia wykonując coś takiego:

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

Nadużycie Federacji

AWS - Federation Abuse
Wsparcie HackTricks

Last updated