diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md index b50391ebd..dc8b80cff 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md @@ -6,9 +6,9 @@ ### `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**). +Każda rola jest tworzona z **polityką zaufania roli (role trust policy)**, ta polityka wskazuje **kto może przyjąć utworzoną rolę**. Jeśli rola z **tego samego konta** stwierdza, że jakieś konto może ją przyjąć, oznacza to, że konto to będzie mogło uzyskać dostęp do roli (i potencjalnie dokonać **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ł uzyskać privesc** do uprawnień związanych z tą rolą. +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ą. ```json { "Version": "2012-10-17", @@ -23,39 +23,20 @@ Na przykład, poniższa polityka zaufania roli wskazuje, że każdy może ją pr ] } ``` -Możesz udawać rolę działającą: +Możesz podszyć się pod rolę, uruchamiając: ```bash aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname ``` **Potencjalny wpływ:** Privesc do roli. -> [!OSTRZEŻENIE] -> Zauważ, że w tym przypadku uprawnienie `sts:AssumeRole` musi być **wskazane 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ą. +> [!CAUTION] +> Zwróć uwagę, że w tym przypadku uprawnienie `sts:AssumeRole` musi być **wskazane w roli, którą chcesz nadużyć** i nie w polityce należącej do atakującego.\ +> Z jednym wyjątkiem — aby **przyjąć rolę z innego konta** konto atakującego **również musi** posiadać **`sts:AssumeRole`** dla tej roli. -### **`sts:GetFederationToken`** -Dzięki temu uprawnieniu możliwe jest wygenerowanie poświadczeń do podszywania się pod dowolnego użytkownika: -```bash -aws sts get-federation-token --name -``` -W ten sposób można bezpiecznie przyznać to uprawnienie, nie dając dostępu do podszywania się pod innych użytkowników: -```json -{ -"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ę.** +Polityka zaufania dla tej roli daje **użytkownikom uwierzytelnionym przez SAML możliwość podszywania się pod rolę.** Przykład polityki zaufania z tym uprawnieniem to: ```json @@ -78,11 +59,11 @@ Przykład polityki zaufania z tym uprawnieniem to: ] } ``` -Aby wygenerować poświadczenia do podszywania się pod rolę, ogólnie możesz użyć czegoś takiego: +Aby wygenerować poświadczenia umożliwiające podszycie się pod rolę, można użyć czegoś takiego: ```bash aws sts assume-role-with-saml --role-arn --principal-arn ``` -Ale **dostawcy** mogą mieć **własne narzędzia**, aby to ułatwić, takie jak [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role): +Ale **dostawcy** mogą mieć swoje **własne narzędzia**, aby to ułatwić, takie jak [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role): ```bash onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600 ``` @@ -90,9 +71,9 @@ onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 -- ### `sts:AssumeRoleWithWebIdentity` -To uprawnienie przyznaje możliwość uzyskania 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.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) +To uprawnienie pozwala uzyskać zestaw tymczasowych poświadczeń bezpieczeństwa dla **użytkowników, którzy zostali uwierzytelnieni w aplikacji mobilnej, aplikacji webowej, EKS...** przy użyciu web identity provider. [Dowiedz się więcej tutaj.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) -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: +Na przykład, jeśli **EKS service account** powinien móc **impersonate an IAM role**, będzie miał token w **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** i może **assume the role and get credentials** wykonując coś takiego: ```bash aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/ --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 @@ -105,9 +86,13 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/ ### IAM Roles Anywhere Privesc -AWS IAM RolesAnywhere pozwala na przyjmowanie ról IAM przez obciążenia poza AWS za pomocą certyfikatów X.509. Jednak gdy polityki zaufania nie są odpowiednio ograniczone, mogą być wykorzystywane do eskalacji uprawnień. +AWS IAM RolesAnywhere umożliwia środowiskom spoza AWS assume IAM roles przy użyciu certyfikatów X.509. Jednak gdy trust policies nie są odpowiednio ograniczone, mogą one zostać nadużyte do eskalacji uprawnień. -Ta polityka nie ma ograniczeń dotyczących tego, które atrybuty zaufania lub certyfikatu są dozwolone. W rezultacie każdy certyfikat powiązany z dowolnym punktem zaufania w koncie może być użyty do przyjęcia tej roli. +Aby zrozumieć ten atak, trzeba wyjaśnić, czym jest trust anchor. Trust anchor w AWS IAM Roles Anywhere to podmiot będący źródłem zaufania — zawiera publiczny certyfikat Certificate Authority (CA) zarejestrowanego w koncie, dzięki czemu AWS może zweryfikować przedstawione certyfikaty X.509. W ten sposób, jeśli certyfikat klienta został wydany przez tę CA i trust anchor jest aktywny, AWS rozpoznaje go jako ważny. + +Dodatkowo, profile to konfiguracja określająca, które atrybuty certyfikatu X.509 (takie jak CN, OU lub SAN) zostaną przekształcone w session tags, a te tagi później będą porównywane z warunkami trust policy. + +Ta polityka nie zawiera ograniczeń co do tego, które trust anchor lub atrybuty certyfikatu są dozwolone. W efekcie każdy certyfikat powiązany z dowolnym trust anchor w koncie może zostać użyty do przyjęcia tej roli. ```json { "Version": "2012-10-17", @@ -127,9 +112,9 @@ Ta polityka nie ma ograniczeń dotyczących tego, które atrybuty zaufania lub c } ``` -Aby uzyskać privesc, wymagany jest `aws_signing_helper` z https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html +Aby przeprowadzić privesc, wymagany jest `aws_signing_helper` z https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html -Następnie, używając ważnego certyfikatu, atakujący może przejść do roli o wyższych uprawnieniach. +Następnie, używając ważnego certyfikatu, atakujący może pivot do roli o wyższych uprawnieniach. ```bash aws_signing_helper credential-process \ --certificate readonly.pem \ @@ -138,7 +123,13 @@ aws_signing_helper credential-process \ --profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \ --role-arn arn:aws:iam::123456789012:role/Admin ``` -### Odniesienia +Punkt zaufania weryfikuje, że certyfikat klienta `readonly.pem` pochodzi z jego autoryzowanej 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 żadnych warunków, te tagi są bezużyteczne, a dostęp jest przyznawany każdemu z ważnym certyfikatem. + +Aby ten atak był możliwy, zarówno punkt zaufania, jak i profil `default` muszą być aktywne. + +### Referencje - [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)