mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat
This commit is contained in:
Translator
@@ -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 <username>
|
||||
```
|
||||
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 <value> --principal-arn <value>
|
||||
```
|
||||
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_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
|
||||
@@ -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)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user