gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-19 10:42:44 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation

Browse Source
This commit is contained in:
Translator
2025-09-29 22:39:48 +00:00
parent 9b3fa55f84
commit a59d1c16a1
2 changed files with 44 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
View File

@@ -4,20 +4,20 @@
## STS
Per ulteriori informazioni:
Per maggiori informazioni:
{{#ref}}
../aws-services/aws-iam-enum.md
{{#endref}}
### Da credenziali IAM alla Console
### From IAM Creds to Console
Se sei riuscito a ottenere alcune credenziali IAM, potresti essere interessato a **accedere alla console web** utilizzando i seguenti strumenti.\
Nota che l'utente/ruolo deve avere il permesso **`sts:GetFederationToken`**.
Se sei riuscito a ottenere alcune IAM credentials potresti essere interessato a **accedere alla web console** usando i seguenti strumenti.\
Nota che l'user/role deve avere il permesso **`sts:GetFederationToken`**.
#### Script personalizzato
Il seguente script utilizzerà il profilo predefinito e una posizione AWS predefinita (non gov e non cn) per fornirti un URL firmato che puoi utilizzare per accedere alla console web:
Lo script seguente userà il profilo di default e una location AWS di default (non gov e non cn) per fornirti un signed URL che puoi usare per effettuare il login nella web console:
```bash
# Get federated creds (you must indicate a policy or they won't have any perms)
## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges
@@ -55,7 +55,7 @@ echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.co
```
#### aws_consoler
Puoi **generare un link alla console web** con [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
Puoi **generare un link alla web console** con [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
```bash
cd /tmp
python3 -m venv env
@@ -64,7 +64,7 @@ pip install aws-consoler
aws_consoler [params...] #This will generate a link to login into the console
```
> [!WARNING]
> Assicurati che l'utente IAM abbia il permesso `sts:GetFederationToken`, o fornisci un ruolo da assumere.
> Assicurati che l'utente IAM abbia il permesso `sts:GetFederationToken`, oppure fornisci un ruolo da assumere.
#### aws-vault
@@ -77,9 +77,9 @@ aws-vault login jonsmith # Open a browser logged as jonsmith
> [!NOTE]
> Puoi anche usare **aws-vault** per ottenere una **sessione della console del browser**
### **Evitare le restrizioni dell'User-Agent da Python**
### **Bypassare le restrizioni User-Agent in Python**
Se c'è una **restrizione nell'eseguire determinate azioni basate sull'user agent** utilizzato (come limitare l'uso della libreria python boto3 in base all'user agent), è possibile utilizzare la tecnica precedente per **connettersi alla console web tramite un browser**, oppure puoi direttamente **modificare l'user-agent di boto3** facendo:
Se esiste una **restrizione nell'eseguire certe azioni in base al user agent** usato (come limitare l'uso della libreria python boto3 in base al user agent) è possibile usare la tecnica precedente per **collegarsi alla console web tramite un browser**, oppure si può direttamente **modificare il boto3 user-agent** facendo:
```bash
# Shared by ex16x41
# Create a client
@@ -92,4 +92,14 @@ client.meta.events.register( 'before-call.secretsmanager.GetSecretValue', lambda
# Perform the action
response = client.get_secret_value(SecretId="flag_secret") print(response['SecretString'])
```
### **`sts:GetFederationToken`**
Con questa autorizzazione è possibile creare un'identità federata per l'utente che la esegue, limitata ai permessi che questo utente possiede.
```bash
aws sts get-federation-token --name <username>
```
Il token restituito da sts:GetFederationToken appartiene all'identità federata dell'utente chiamante, ma ha permessi limitati. Anche se l'utente dispone di diritti di amministratore, alcune azioni, come l'elenco degli utenti IAM o l'associazione di policy, non possono essere eseguite tramite il token federato.
Inoltre, questo metodo è più furtivo, poiché l'utente federato non compare nell'AWS Portal; può essere osservato solo attraverso i log di CloudTrail o strumenti di monitoraggio.
{{#include ../../../banners/hacktricks-training.md}}

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

@@ -6,9 +6,9 @@
### `sts:AssumeRole`
Ogni ruolo è creato con una **policy di fiducia del ruolo**, questa policy indica **chi può assumere il ruolo creato**. Se un ruolo dello **stesso account** dice 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 **privesc**).
Ad esempio, la seguente policy di fiducia del ruolo indica che chiunque può assumerlo, quindi **qualsiasi utente sarà in grado di privesc** ai permessi associati a quel ruolo.
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.
```json
{
"Version": "2012-10-17",
@@ -27,37 +27,18 @@ Puoi impersonare un ruolo eseguendo:
```bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
```
**Impatto Potenziale:** Privesc al ruolo.
**Impatto potenziale:** Privesc al ruolo.
> [!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 attaccante **deve anche** avere il **`sts:AssumeRole`** sul ruolo.
> Con un'eccezione, per **assumere un ruolo da un account diverso** l'account dell'attaccante **deve anche** avere la **`sts:AssumeRole`** sul ruolo.
### **`sts:GetFederationToken`**
Con questo permesso è possibile generare credenziali per impersonare qualsiasi utente:
```bash
aws sts get-federation-token --name <username>
```
Questo è il modo in cui questo permesso può essere concesso in modo sicuro senza dare accesso a impersonare altri utenti:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "arn:aws:sts::947247140022:federated-user/${aws:username}"
}
]
}
```
### `sts:AssumeRoleWithSAML`
Una policy di fiducia con questo ruolo concede **agli utenti autenticati tramite SAML l'accesso per impersonare il ruolo.**
Una trust policy con questo ruolo concede **agli utenti autenticati via SAML l'accesso per impersonare il ruolo.**
Un esempio di una policy di fiducia con questo permesso è:
Un esempio di trust policy con questo permesso è:
```json
{
"Version": "2012-10-17",
@@ -78,36 +59,36 @@ Un esempio di una policy di fiducia con questo permesso è:
]
}
```
Per generare credenziali per impersonare il ruolo in generale, potresti usare qualcosa come:
Per generare credenziali per impersonare il ruolo, in generale potresti usare qualcosa del genere:
```bash
aws sts assume-role-with-saml --role-arn <value> --principal-arn <value>
```
Ma i **provider** potrebbero avere i **loro strumenti** per rendere questo più facile, come [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
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):
```bash
onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
```
**Impatto Potenziale:** Privesc al ruolo.
**Impatto potenziale:** Privesc to the role.
### `sts:AssumeRoleWithWebIdentity`
Questo permesso consente di ottenere un insieme di credenziali di sicurezza temporanee per **utenti che sono stati autenticati in un'applicazione mobile, web, EKS...** con un provider di identità web. [Scopri di più 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 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)
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 come:
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:
```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
```
### Abuso di Federazione
### Federation Abuse
{{#ref}}
../aws-basic-information/aws-federation-abuse.md
{{#endref}}
### Privesc di IAM Roles Anywhere
### IAM Roles Anywhere Privesc
AWS IAM RolesAnywhere consente ai carichi di lavoro al di fuori di AWS di assumere ruoli IAM utilizzando certificati X.509. Ma quando le politiche di fiducia non sono correttamente definite, possono essere abusate per l'escalation dei privilegi.
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.
Questa politica manca di restrizioni su quali ancore di fiducia o attributi del certificato sono consentiti. Di conseguenza, qualsiasi certificato legato a qualsiasi ancoraggio di fiducia nell'account può essere utilizzato per assumere questo ruolo.
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.
```json
{
"Version": "2012-10-17",
@@ -127,9 +108,9 @@ Questa politica manca di restrizioni su quali ancore di fiducia o attributi del
}
```
Per il privesc, è necessario `aws_signing_helper` da https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
Per privesc è richiesto `aws_signing_helper` da https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
Quindi, utilizzando un certificato valido, l'attaccante può passare al ruolo con privilegi superiori.
Quindi, usando un certificato valido, l'attaccante può pivotare in un ruolo con privilegi più elevati
```bash
aws_signing_helper credential-process \
--certificate readonly.pem \
@@ -138,6 +119,14 @@ 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`).
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 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.
### Riferimenti
- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)