gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-28 13:43:24 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2025-09-30 19:16:49 +00:00
parent 873b0649c2
commit dfef045788
1 changed files with 23 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
View File

@@ -6,9 +6,9 @@
### `sts:AssumeRole`
Ogni ruolo viene creato con una **role trust policy**, questa policy indica **chi può assumere il ruolo creato**. Se un ruolo dello **stesso account** dichiara che un account può assumerlo, significa che l'account sarà in grado di accedere al ruolo (e potenzialmente **privesc**).
Ogni ruolo viene creato con una **role trust policy**, questa policy indica **chi può assumere il ruolo creato**. Se un ruolo dello **stesso account** dichiara che un account può assumerlo, significa che l'account sarà in grado di accedere al ruolo (e potenzialmente ottenere **privesc**).
Per esempio, la seguente role trust policy indica che chiunque può assumerla, quindi **qualsiasi utente sarà in grado di privesc** alle autorizzazioni associate a quel ruolo.
Ad esempio, la seguente role trust policy indica che chiunque può assumerlo, quindi **qualsiasi utente sarà in grado di privesc** alle autorizzazioni associate a quel ruolo.
```json
{
"Version": "2012-10-17",
@@ -23,20 +23,20 @@ Per esempio, la seguente role trust policy indica che chiunque può assumerla, q
]
}
```
Puoi impersonare un ruolo eseguendo:
Puoi impersonare un ruolo in esecuzione:
```bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
```
**Impatto potenziale:** Privesc al ruolo.
**Impatto potenziale:** Privesc al role.
> [!CAUTION]
> Nota che in questo caso il permesso `sts:AssumeRole` deve essere **indicato nel ruolo da abusare** e non in una policy appartenente all'attaccante.\
> Con un'eccezione, per **assumere un ruolo da un account diverso** l'account dell'attaccante **deve anche** avere la **`sts:AssumeRole`** sul ruolo.
> Nota che in questo caso il permesso `sts:AssumeRole` deve essere **indicato nel role da abusare** e non in una policy appartenente all'attacker.\
> Con un'eccezione, per **assumere un role da un account diverso** l'account attacker **deve anche** avere il **`sts:AssumeRole`** sul role.
### `sts:AssumeRoleWithSAML`
Una trust policy con questo ruolo concede **agli utenti autenticati via SAML l'accesso per impersonare il ruolo.**
Una trust policy con questo role concede **agli utenti autenticati tramite SAML l'accesso per impersonare il role.**
Un esempio di trust policy con questo permesso è:
```json
@@ -63,22 +63,22 @@ Per generare credenziali per impersonare il ruolo, in generale potresti usare qu
```bash
aws sts assume-role-with-saml --role-arn <value> --principal-arn <value>
```
Ma **i fornitori** potrebbero avere i **propri strumenti** per rendere questo più semplice, come [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
Ma i **provider** potrebbero avere i loro **strumenti** per semplificare questo, come [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
```
**Impatto potenziale:** Privesc to the role.
**Impatto potenziale:** Privesc al ruolo.
### `sts:AssumeRoleWithWebIdentity`
Questa autorizzazione permette di ottenere un set di credenziali di sicurezza temporanee per **utenti che sono stati autenticati in un'app mobile, un'applicazione web, EKS...** tramite un provider di identità web. [Ulteriori informazioni qui.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
Questa autorizzazione permette di ottenere un set di credenziali di sicurezza temporanee per **utenti autenticati in mobile, applicazioni web, EKS...** con un provider di identità web. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
Ad esempio, se un **account di servizio EKS** dovrebbe essere in grado di **impersonare un ruolo IAM**, avrà un token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** e può **assumere il ruolo e ottenere credenziali** facendo qualcosa del genere:
Ad esempio, se un **EKS service account** dovrebbe essere in grado di **impersonare un ruolo IAM**, avrà un token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** e può **assumere il ruolo e ottenere credenziali** facendo qualcosa del genere:
```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
```
### Federation Abuse
### Abuso della federazione
{{#ref}}
../aws-basic-information/aws-federation-abuse.md
@@ -86,9 +86,13 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
### IAM Roles Anywhere Privesc
AWS IAM RolesAnywhere permette a workload esterni ad AWS di assumere IAM roles tramite certificati X.509. Tuttavia, quando le trust policies non sono correttamente limitate, possono essere abusate per privilege escalation.
AWS IAM RolesAnywhere permette a workload esterni ad AWS di assumere ruoli IAM usando certificati X.509. Ma quando le trust policies non sono adeguatamente limitate, possono essere abusate per privilege escalation.
Questa policy non contiene restrizioni su quale trust anchor o quali attributi del certificato sono consentiti. Di conseguenza, qualsiasi certificato legato a qualsiasi trust anchor nell'account può essere utilizzato per assumere questo ruolo.
Per capire questo attacco, è necessario spiegare cos'è un trust anchor. Un trust anchor in AWS IAM Roles Anywhere è l'entità radice di fiducia: contiene il certificato pubblico di una Certificate Authority (CA) registrata nell'account, in modo che AWS possa validare i certificati X.509 presentati. In questo modo, se il client certificate è stato emesso da quella CA e il trust anchor è attivo, AWS lo riconosce come valido.
Inoltre, un profile è la configurazione che definisce quali attributi del certificato X.509 (come CN, OU o SAN) saranno trasformati in session tags, e questi tags saranno poi confrontati con le condizioni della trust policy.
Questa policy manca di restrizioni su quali trust anchor o attributi del certificato siano consentiti. Di conseguenza, qualsiasi certificato legato a qualsiasi trust anchor nell'account può essere usato per assumere questo ruolo.
```json
{
"Version": "2012-10-17",
@@ -108,9 +112,9 @@ Questa policy non contiene restrizioni su quale trust anchor o quali attributi d
}
```
Per privesc è richiesto `aws_signing_helper` da https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
Per privesc, è richiesto il `aws_signing_helper` da https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
Quindi, usando un certificato valido, l'attaccante può pivotare in un ruolo con privilegi più elevati
Poi, usando un certificato valido, l'attaccante può, facendo pivot, accedere al ruolo con privilegi più elevati
```bash
aws_signing_helper credential-process \
--certificate readonly.pem \
@@ -119,13 +123,11 @@ aws_signing_helper credential-process \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin
```
La trust anchor valida che il certificato client `readonly.pem` provenga dalla sua CA autorizzata; quando la trust anchor è stata creata è stato incluso il certificato pubblico della CA (ora usato per validare `readonly.pem`).
Il trust anchor valida che il certificato `readonly.pem` del client provenga dalla sua CA autorizzata, e all'interno di questo certificato `readonly.pem` c'è la chiave pubblica che AWS usa per verificare che la firma sia stata fatta con la corrispondente chiave privata `readonly.key`.
All'interno di `readonly.pem` c'è la chiave pubblica, che AWS usa per verificare che la firma sia stata generata con la corrispondente chiave privata `readonly.key`.
Il certificato fornisce anche attributi (come CN o OU) che il profilo `default` trasforma in tag, i quali la trust policy del ruolo può usare per decidere se autorizzare l'accesso. Se non ci sono condizioni nella trust policy, quegli tag non hanno utilità e l'accesso viene concesso a chiunque possieda un certificato valido.
Il certificato dimostra anche l'identità e fornisce attributi (come CN o OU) che il profilo `default` trasforma in tag; la trust policy del ruolo può usare questi tag per decidere se autorizzare l'accesso. Se non ci sono condizioni nella trust policy, quei tag vengono ignorati e chiunque possieda un certificato valido è autorizzato.
Perché questo attacco sia possibile, sia la trust anchor sia il profilo `default` devono essere attivi.
Perché questo attacco sia possibile, sia il trust anchor che il profilo `default` devono essere attivi.
### Riferimenti