AWS - STS Privesc

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

STS

sts:AssumeRole

Każda rola jest tworzona z polityką zaufania roli, ta polityka wskazuje kto może przejąć utworzoną rolę. Jeśli rola z tego samego konta mówi, że konto może jej użyć, oznacza to, że 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ą przejąć, dlatego każdy użytkownik będzie mógł privesc do uprawnień powiązanych z tą rolą.

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

Możesz podszyć się pod rolę, uruchamiając:

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

Potencjalny wpływ: Privesc na rolę.

Caution

Należy pamiętać, że w tym przypadku uprawnienie sts:AssumeRole musi być wskazane w roli, którą chcemy wykorzystać i nie w polityce należącej do attacker.
Z jednym wyjątkiem: aby przejmować rolę z innego konta konto attacker również musi mieć sts:AssumeRole nad tą rolą.

sts:AssumeRoleWithSAML

Polityka zaufania z tą rolą przyznaje użytkownikom uwierzytelnionym przez SAML możliwość podszywania się pod rolę.

Przykład polityki zaufania zawierającej to uprawnienie wygląda następująco:

{
"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 umożliwiające podszycie się pod daną rolę, można użyć czegoś takiego:

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

Jednak dostawcy mogą mieć własne narzędzia, które to ułatwiają, takie jak onelogin-aws-assume-role:

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

Potential Impact: Privesc do roli.

sts:AssumeRoleWithWebIdentity

To uprawnienie pozwala na uzyskanie zestawu tymczasowych poświadczeń bezpieczeństwa dla użytkowników, którzy zostali uwierzytelnieni w aplikacji mobilnej, aplikacji webowej, EKS… przy użyciu dostawcy tożsamości sieciowej. Learn more here.

Na przykład, jeśli konto serwisowe EKS powinno mieć możliwość podszywania się pod rolę IAM, będzie miało token w /var/run/secrets/eks.amazonaws.com/serviceaccount/token i może przejąć 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życia federacji

AWS - Federation Abuse

IAM Roles Anywhere Privesc

AWS IAM RolesAnywhere pozwala workloadom działającym poza AWS przejmować IAM roles przy użyciu certyfikatów X.509. Jednak gdy trust policies nie są odpowiednio ograniczone, mogą zostać wykorzystane do eskalacji uprawnień.

Aby zrozumieć ten atak, warto wyjaśnić, czym jest trust anchor. Trust anchor w AWS IAM Roles Anywhere jest podmiotem będącym korzeniem zaufania; zawiera publiczny certyfikat Certificate Authority (CA) zarejestrowanej w koncie, co pozwala AWS na weryfikację przedstawionych certyfikatów X.509. W ten sposób, jeśli certyfikat klienta został wydany przez tę CA i trust anchor jest aktywny, AWS uznaje go za ważny.

Ponadto profile to konfiguracja definiująca, które atrybuty certyfikatu X.509 (takie jak CN, OU czy SAN) zostaną przekształcone w tagi sesji, a te tagi będą później porównywane z warunkami trust policy.

Ta polityka nie zawiera ograniczeń określających, które trust anchor lub atrybuty certyfikatu są dozwolone. W rezultacie każdy certyfikat powiązany z dowolnym trust anchor w koncie może zostać użyty do przejęcia tej roli.

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

Aby privesc, aws_signing_helper jest wymagany z https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html

Następnie, używając ważnego certyfikatu, attacker może pivot into the higher privilege role

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

Punkt zaufania weryfikuje, że certyfikat klienta readonly.pem pochodzi od autoryzowanego CA, a w tym certyfikacie readonly.pem znajduje się klucz publiczny, którego AWS używa do weryfikacji, że podpis został wykonany odpowiadającym mu kluczem prywatnym readonly.key.

Certyfikat dostarcza również atrybuty (takie jak CN lub OU), które profil default przekształca w tagi, których polityka zaufania roli może użyć do zdecydowania, czy autoryzować dostęp. Jeśli w polityce zaufania nie ma warunków, te tagi nie mają zastosowania i dostęp jest przyznawany każdemu, kto posiada ważny certyfikat.

Aby ten attack był możliwy, zarówno punkt zaufania, jak i profil default muszą być aktywne.

Referencje

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks