mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-31 07:00:38 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
@@ -39,7 +39,7 @@ E l'hijack è possibile perché c'è un **breve intervallo di tempo dal momento
|
||||
.png>)
|
||||
|
||||
Il modulo Pacu [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) può essere utilizzato per automatizzare questo attacco.\
|
||||
Per ulteriori informazioni, controlla la ricerca originale: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
Per ulteriori informazioni controlla la ricerca originale: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
|
||||
|
||||
@@ -52,20 +52,19 @@ Ecco alcuni esempi:
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` (opzionale) su file di stato terraform
|
||||
|
||||
È molto comune che i file di stato [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) vengano salvati nello storage blob dei fornitori di cloud, ad esempio AWS S3. Il suffisso del file per un file di stato è `.tfstate`, e i nomi dei bucket spesso rivelano che contengono file di stato terraform. Di solito, ogni account AWS ha un bucket di questo tipo per memorizzare i file di stato che mostrano lo stato dell'account.\
|
||||
Inoltre, di solito, negli account del mondo reale quasi sempre tutti gli sviluppatori hanno `s3:*` e a volte anche gli utenti aziendali hanno `s3:Put*`.
|
||||
È molto comune che i file di stato [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) vengano salvati nello storage blob dei fornitori di cloud, ad esempio AWS S3. Il suffisso del file per un file di stato è `.tfstate`, e i nomi dei bucket spesso rivelano che contengono file di stato terraform. Di solito, ogni account AWS ha un bucket di questo tipo per memorizzare i file di stato che mostrano lo stato dell'account. Inoltre, di solito, negli account del mondo reale quasi sempre tutti gli sviluppatori hanno `s3:*` e a volte anche gli utenti aziendali hanno `s3:Put*`.
|
||||
|
||||
Quindi, se hai le autorizzazioni elencate su questi file, c'è un vettore di attacco che ti consente di ottenere RCE nella pipeline con i privilegi di `terraform` - la maggior parte delle volte `AdministratorAccess`, rendendoti l'amministratore dell'account cloud. Inoltre, puoi utilizzare quel vettore per effettuare un attacco di denial of service facendo sì che `terraform` elimini risorse legittime.
|
||||
Quindi, se hai le autorizzazioni elencate su questi file, c'è un vettore di attacco che ti consente di ottenere RCE nella pipeline con i privilegi di `terraform` - per la maggior parte delle volte `AdministratorAccess`, rendendoti l'amministratore dell'account cloud. Inoltre, puoi utilizzare quel vettore per effettuare un attacco di denial of service facendo sì che `terraform` elimini risorse legittime.
|
||||
|
||||
Segui la descrizione nella sezione *Abusing Terraform State Files* della pagina *Terraform Security* per codice di exploit direttamente utilizzabile:
|
||||
|
||||
{{#ref}}
|
||||
terraform-security.md#abusing-terraform-state-files
|
||||
pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
|
||||
{{#endref}}
|
||||
|
||||
### `s3:PutBucketPolicy`
|
||||
|
||||
Un attaccante, che deve essere **dallo stesso account**, altrimenti si attiverà l'errore `The specified method is not allowed`, con questo permesso sarà in grado di concedersi ulteriori autorizzazioni sui bucket, permettendogli di leggere, scrivere, modificare, eliminare ed esporre i bucket.
|
||||
Un attaccante, che deve essere **dallo stesso account**, altrimenti si attiverà l'errore `The specified method is not allowed`, con questo permesso sarà in grado di concedersi più autorizzazioni sui bucket, permettendogli di leggere, scrivere, modificare, eliminare ed esporre i bucket.
|
||||
```bash
|
||||
# Update Bucket policy
|
||||
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
|
||||
@@ -151,7 +150,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
|
||||
|
||||
Un attaccante potrebbe abusare di questi permessi per concedersi un accesso maggiore su oggetti specifici all'interno dei bucket.
|
||||
Un attaccante potrebbe abusare di questi permessi per concedersi maggiore accesso su oggetti specifici all'interno dei bucket.
|
||||
```bash
|
||||
# Update bucket object ACL
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
Per ulteriori informazioni sui servizi App di Azure, controlla:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/az-app-service.md
|
||||
../az-services/az-app-services.md
|
||||
{{#endref}}
|
||||
|
||||
### Microsoft.Web/sites/publish/Action, Microsoft.Web/sites/basicPublishingCredentialsPolicies/read, Microsoft.Web/sites/config/read, Microsoft.Web/sites/read
|
||||
@@ -37,7 +37,7 @@ ssh root@127.0.0.1 -p 39895
|
||||
2. Accedi all'estensione con l'account Azure.
|
||||
3. Elenca tutti i servizi App all'interno dell'abbonamento.
|
||||
4. Seleziona il servizio App che desideri debugare, fai clic destro e seleziona "Inizia Debugging".
|
||||
5. Se l'app non ha il debug abilitato, l'estensione cercherà di abilitarlo, ma il tuo account ha bisogno del permesso `Microsoft.Web/sites/config/write` per farlo.
|
||||
5. Se l'app non ha il debug abilitato, l'estensione cercherà di abilitarlo, ma il tuo account deve avere il permesso `Microsoft.Web/sites/config/write` per farlo.
|
||||
|
||||
### Ottenere le credenziali SCM e abilitare l'autenticazione di base
|
||||
|
||||
@@ -94,7 +94,7 @@ az webapp deployment list-publishing-profiles --name <app-name> --resource-group
|
||||
}
|
||||
]
|
||||
```
|
||||
Nota come il **nome utente è sempre lo stesso** (eccetto in FTP che aggiunge il nome dell'app all'inizio) ma la **password è la stessa** per tutti.
|
||||
Nota come il **nome utente è sempre lo stesso** (tranne in FTP che aggiunge il nome dell'app all'inizio) ma la **password è la stessa** per tutti.
|
||||
|
||||
Inoltre, l'**URL SCM è `<app-name>.scm.azurewebsites.net`**.
|
||||
|
||||
@@ -118,13 +118,13 @@ az webapp deployment list-publishing-credentials --name <app-name> --resource-gr
|
||||
```
|
||||
Nota come le **credenziali sono le stesse** di quelle del comando precedente.
|
||||
|
||||
- Un'altra opzione sarebbe **impostare le tue credenziali** e usarle:
|
||||
- Un'altra opzione sarebbe **impostare le proprie credenziali** e usarle:
|
||||
```bash
|
||||
az webapp deployment user set \
|
||||
--user-name hacktricks \
|
||||
--password 'W34kP@ssw0rd123!'
|
||||
```
|
||||
Poi, puoi usare queste credenziali per **accedere alle piattaforme SCM e FTP**. Questo è anche un ottimo modo per mantenere la persistenza.
|
||||
Poi, puoi utilizzare queste credenziali per **accedere alle piattaforme SCM e FTP**. Questo è anche un ottimo modo per mantenere la persistenza.
|
||||
|
||||
Ricorda che per accedere alla piattaforma SCM dal **web devi accedere a `<SCM-URL>/BasicAuth`**.
|
||||
|
||||
@@ -205,7 +205,7 @@ curl -X PUT \
|
||||
```
|
||||
### Microsoft.Web/sites/write, Microsoft.Web/sites/read, Microsoft.ManagedIdentity/userAssignedIdentities/assign/action
|
||||
|
||||
Queste autorizzazioni consentono di **assegnare un'identità gestita** al servizio App, quindi se un servizio App è stato precedentemente compromesso, questo consentirà all'attaccante di assegnare nuove identità gestite al servizio App e **escalare i privilegi** su di esse.
|
||||
Queste autorizzazioni consentono di **assegnare un'identità gestita** al servizio App, quindi se un servizio App è stato precedentemente compromesso, questo consentirà all'attaccante di assegnare nuove identità gestite al servizio App e **escalare i privilegi** a esse.
|
||||
```bash
|
||||
az webapp identity assign --name <app-name> --resource-group <res-group> --identities /subscriptions/<subcripttion-id>/resourceGroups/<res_group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<managed-identity-name>
|
||||
```
|
||||
@@ -218,7 +218,7 @@ az webapp config appsettings list --name <name> --resource-group <res-group>
|
||||
```
|
||||
### Leggi le credenziali di terze parti configurate
|
||||
|
||||
Eseguendo il seguente comando è possibile **leggere le credenziali di terze parti** configurate nell'account attuale. Nota che, ad esempio, se alcune credenziali di Github sono configurate in un utente diverso, non sarai in grado di accedere al token da un altro.
|
||||
Eseguendo il seguente comando è possibile **leggere le credenziali di terze parti** configurate nell'account attuale. Nota che, se ad esempio alcune credenziali di Github sono configurate in un utente diverso, non sarai in grado di accedere al token da un altro.
|
||||
```bash
|
||||
az rest --method GET \
|
||||
--url "https://management.azure.com/providers/Microsoft.Web/sourcecontrols?api-version=2024-04-01"
|
||||
|
||||
@@ -17,9 +17,9 @@
|
||||
- **Piano Dedicato**: Esegue su macchine virtuali dedicate con **fatturazione prevedibile** e supporta scalabilità manuale o automatica. Consente di eseguire più app sullo stesso piano, fornisce **isolamento di calcolo** e garantisce **accesso sicuro alla rete** tramite App Service Environments, rendendolo ideale per **applicazioni a lungo termine** che necessitano di allocazione costante delle risorse.
|
||||
- **Container Apps**: Consente di distribuire **app di funzione containerizzate** in un ambiente gestito, insieme a microservizi e API. Supporta librerie personalizzate, migrazione di app legacy e **elaborazione GPU**, eliminando la gestione del cluster Kubernetes. Ideale per **applicazioni containerizzate scalabili e basate su eventi**.
|
||||
|
||||
### **Storage Buckets**
|
||||
### **Bucket di Archiviazione**
|
||||
|
||||
Quando si crea una nuova Function App non containerizzata (ma si fornisce il codice da eseguire), il **codice e altri dati relativi alla Funzione saranno memorizzati in un account di Storage**. Per impostazione predefinita, la console web creerà un nuovo account per ogni funzione per memorizzare il codice.
|
||||
Quando si crea una nuova Function App non containerizzata (ma si fornisce il codice da eseguire), il **codice e altri dati relativi alla Funzione saranno memorizzati in un account di archiviazione**. Per impostazione predefinita, la console web creerà un nuovo account per ogni funzione per memorizzare il codice.
|
||||
|
||||
Inoltre, modificando il codice all'interno del bucket (nei diversi formati in cui potrebbe essere memorizzato), il **codice dell'app verrà modificato con il nuovo e verrà eseguito** la prossima volta che la Funzione viene chiamata.
|
||||
|
||||
@@ -28,7 +28,7 @@ Inoltre, modificando il codice all'interno del bucket (nei diversi formati in cu
|
||||
>
|
||||
> Maggiori informazioni su questo nella **sezione sull'escalation dei privilegi**.
|
||||
|
||||
È anche possibile trovare le **chiavi master e delle funzioni** memorizzate nell'account di storage nel container **`azure-webjobs-secrets`** all'interno della cartella **`<app-name>`** nei file JSON che puoi trovare all'interno.
|
||||
È anche possibile trovare le **chiavi master e delle funzioni** memorizzate nell'account di archiviazione nel contenitore **`azure-webjobs-secrets`** all'interno della cartella **`<app-name>`** nei file JSON che puoi trovare all'interno.
|
||||
|
||||
Nota che le Funzioni consentono anche di memorizzare il codice in una posizione remota semplicemente indicando l'URL.
|
||||
|
||||
@@ -42,26 +42,26 @@ Utilizzando un trigger HTTP:
|
||||
> [!CAUTION]
|
||||
> Questo è molto interessante dal punto di vista di un attaccante poiché potrebbe essere possibile **pivotare verso reti interne** da una Function vulnerabile esposta a Internet.
|
||||
|
||||
### **Impostazioni della Function App & Variabili d'Ambiente**
|
||||
### **Impostazioni della Function App e Variabili d'Ambiente**
|
||||
|
||||
È possibile configurare variabili d'ambiente all'interno di un'app, che potrebbero contenere informazioni sensibili. Inoltre, per impostazione predefinita, le variabili d'ambiente **`AzureWebJobsStorage`** e **`WEBSITE_CONTENTAZUREFILECONNECTIONSTRING`** (tra le altre) vengono create. Queste sono particolarmente interessanti perché **contengono la chiave dell'account per controllare con PERMESSI COMPLETI l'account di storage contenente i dati dell'applicazione**. Queste impostazioni sono anche necessarie per eseguire il codice dall'Account di Storage.
|
||||
È possibile configurare variabili d'ambiente all'interno di un'app, che potrebbero contenere informazioni sensibili. Inoltre, per impostazione predefinita, le variabili d'ambiente **`AzureWebJobsStorage`** e **`WEBSITE_CONTENTAZUREFILECONNECTIONSTRING`** (tra le altre) vengono create. Queste sono particolarmente interessanti perché **contengono la chiave dell'account per controllare con PERMESSI COMPLETI l'account di archiviazione contenente i dati dell'applicazione**. Queste impostazioni sono anche necessarie per eseguire il codice dall'Account di Archiviazione.
|
||||
|
||||
Queste variabili d'ambiente o parametri di configurazione controllano anche come la Funzione esegue il codice, ad esempio se **`WEBSITE_RUN_FROM_PACKAGE`** esiste, indicherà l'URL dove si trova il codice dell'applicazione.
|
||||
Queste variabili d'ambiente o parametri di configurazione controllano anche come la Funzione esegue il codice, ad esempio se **`WEBSITE_RUN_FROM_PACKAGE`** esiste, indicherà l'URL in cui si trova il codice dell'applicazione.
|
||||
|
||||
### **Function Sandbox**
|
||||
### **Sandbox della Funzione**
|
||||
|
||||
All'interno della sandbox linux il codice sorgente si trova in **`/home/site/wwwroot`** nel file **`function_app.py`** (se viene utilizzato python) l'utente che esegue il codice è **`app`** (senza permessi sudo).
|
||||
|
||||
In una **funzione Windows** che utilizza NodeJS il codice si trovava in **`C:\home\site\wwwroot\HttpTrigger1\index.js`**, il nome utente era **`mawsFnPlaceholder8_f_v4_node_20_x86`** ed era parte dei **gruppi**: `Mandatory Label\High Mandatory Level Label`, `Everyone`, `BUILTIN\Users`, `NT AUTHORITY\INTERACTIVE`, `CONSOLE LOGON`, `NT AUTHORITY\Authenticated Users`, `NT AUTHORITY\This Organization`, `BUILTIN\IIS_IUSRS`, `LOCAL`, `10-30-4-99\Dwas Site Users`.
|
||||
|
||||
### **Identità Gestite & Metadati**
|
||||
### **Identità Gestite e Metadati**
|
||||
|
||||
Proprio come [**VMs**](vms/), le Funzioni possono avere **Identità Gestite** di 2 tipi: Assegnate dal sistema e Assegnate dall'utente.
|
||||
Proprio come [**VM**](vms/index.html), le Funzioni possono avere **Identità Gestite** di 2 tipi: Assegnate dal sistema e Assegnate dall'utente.
|
||||
|
||||
L'**identità assegnata dal sistema** sarà un'identità gestita che **solo la funzione** a cui è assegnata potrà utilizzare, mentre le identità gestite **assegnate dall'utente** sono identità gestite che **qualsiasi altro servizio Azure potrà utilizzare**.
|
||||
L'**identità assegnata dal sistema** sarà un'identità gestita che **solo la funzione** che l'ha assegnata potrà utilizzare, mentre le **identità gestite assegnate dall'utente** sono identità gestite che **qualsiasi altro servizio Azure potrà utilizzare**.
|
||||
|
||||
> [!NOTE]
|
||||
> Proprio come in [**VMs**](vms/), le Funzioni possono avere **1 identità gestita assegnata dal sistema** e **diverse identità assegnate dall'utente**, quindi è sempre importante cercare di trovare tutte se si compromette la funzione perché si potrebbe essere in grado di aumentare i privilegi a diverse identità gestite da una sola Funzione.
|
||||
> Proprio come in [**VM**](vms/index.html), le Funzioni possono avere **1 identità gestita assegnata dal sistema** e **diverse identità assegnate dall'utente**, quindi è sempre importante cercare di trovare tutte se si compromette la funzione perché si potrebbe essere in grado di aumentare i privilegi a diverse identità gestite da una sola Funzione.
|
||||
>
|
||||
> Se non viene utilizzata un'identità gestita dal sistema ma una o più identità gestite dall'utente sono collegate a una funzione, per impostazione predefinita non sarà possibile ottenere alcun token.
|
||||
|
||||
@@ -76,7 +76,7 @@ Nota che devi trovare un modo per **controllare tutte le Identità Gestite a cui
|
||||
> [!NOTE]
|
||||
> Nota che non ci sono permessi RBAC per dare accesso agli utenti per invocare le funzioni. L'**invocazione della funzione dipende dal trigger** selezionato quando è stata creata e se è stato selezionato un Trigger HTTP, potrebbe essere necessario utilizzare una **chiave di accesso**.
|
||||
|
||||
Quando si crea un endpoint all'interno di una funzione utilizzando un **trigger HTTP**, è possibile indicare il **livello di autorizzazione della chiave di accesso** necessario per attivare la funzione. Sono disponibili tre opzioni:
|
||||
Quando si crea un endpoint all'interno di una funzione utilizzando un **trigger HTTP** è possibile indicare il **livello di autorizzazione della chiave di accesso** necessario per attivare la funzione. Sono disponibili tre opzioni:
|
||||
|
||||
- **ANONYMOUS**: **Tutti** possono accedere alla funzione tramite l'URL.
|
||||
- **FUNCTION**: L'endpoint è accessibile solo agli utenti che utilizzano una **chiave di funzione, host o master**.
|
||||
@@ -84,8 +84,8 @@ Quando si crea un endpoint all'interno di una funzione utilizzando un **trigger
|
||||
|
||||
**Tipo di chiavi:**
|
||||
|
||||
- **Chiavi di Funzione:** Le chiavi di funzione possono essere predefinite o definite dall'utente e sono progettate per concedere accesso esclusivamente a **endpoint di funzione specifici** all'interno di una Function App consentendo un accesso più dettagliato sugli endpoint.
|
||||
- **Chiavi Host:** Le chiavi host, che possono essere predefinite o definite dall'utente, forniscono accesso a **tutti gli endpoint di funzione all'interno di una Function App con livello di accesso FUNCTION**.
|
||||
- **Chiavi di Funzione:** Le chiavi di funzione possono essere predefinite o definite dall'utente e sono progettate per concedere accesso esclusivamente a **specifici endpoint di funzione** all'interno di una Function App consentendo un accesso più dettagliato sugli endpoint.
|
||||
- **Chiavi Host:** Le chiavi host, che possono essere anch'esse predefinite o definite dall'utente, forniscono accesso a **tutti gli endpoint di funzione all'interno di una Function App con livello di accesso FUNCTION**.
|
||||
- **Chiave Master:** La chiave master (`_master`) funge da chiave amministrativa che offre permessi elevati, incluso l'accesso a tutti gli endpoint di funzione (incluso il livello di accesso ADMIN). Questa **chiave non può essere revocata.**
|
||||
- **Chiavi di Sistema:** Le chiavi di sistema sono **gestite da estensioni specifiche** e sono necessarie per accedere agli endpoint webhook utilizzati dai componenti interni. Esempi includono il trigger Event Grid e le Funzioni Durature, che utilizzano chiavi di sistema per interagire in modo sicuro con le rispettive API.
|
||||
|
||||
@@ -99,12 +99,12 @@ Quando si crea un endpoint all'interno di una funzione utilizzando un **trigger
|
||||
Proprio come nei Servizi App, le Funzioni supportano anche l'autenticazione di base per connettersi a **SCM** e **FTP** per distribuire codice utilizzando un **nome utente e una password in un URL** fornito da Azure. Maggiori informazioni su questo in:
|
||||
|
||||
{{#ref}}
|
||||
az-app-service.md
|
||||
az-app-services.md
|
||||
{{#endref}}
|
||||
|
||||
### Distribuzioni Basate su Github
|
||||
|
||||
Quando una funzione viene generata da un repo Github, la console web di Azure consente di **creare automaticamente un Workflow Github in un repository specifico** in modo che ogni volta che questo repository viene aggiornato, il codice della funzione venga aggiornato. In realtà, il file yaml dell'azione Github per una funzione python appare così:
|
||||
Quando una funzione è generata da un repo Github, la console web di Azure consente di **creare automaticamente un Workflow Github in un repository specifico** in modo che ogni volta che questo repository viene aggiornato, il codice della funzione venga aggiornato. In realtà, il file yaml dell'azione Github per una funzione python appare così:
|
||||
|
||||
<details>
|
||||
|
||||
@@ -192,7 +192,7 @@ package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}
|
||||
```
|
||||
</details>
|
||||
|
||||
Inoltre, viene creata un'**Identità Gestita** affinché l'azione di Github del repository possa accedere ad Azure. Questo avviene generando una credenziale federata sull'**Identità Gestita** che consente all'**Emittente** `https://token.actions.githubusercontent.com` e all'**Identificatore del Soggetto** `repo:<org-name>/<repo-name>:ref:refs/heads/<branch-name>`.
|
||||
Inoltre, viene creata un'**Identità Gestita** affinché l'azione di Github del repository possa accedere ad Azure con essa. Questo avviene generando una credenziale Federata sull'**Identità Gestita** che consente all'**Emittente** `https://token.actions.githubusercontent.com` e all'**Identificatore del Soggetto** `repo:<org-name>/<repo-name>:ref:refs/heads/<branch-name>`.
|
||||
|
||||
> [!CAUTION]
|
||||
> Pertanto, chiunque comprometta quel repository sarà in grado di compromettere la funzione e le Identità Gestite ad essa collegate.
|
||||
@@ -249,7 +249,7 @@ curl "https://newfuncttest123.azurewebsites.net/admin/vfs/home/site/wwwroot/func
|
||||
# Get source code
|
||||
az rest --url "https://management.azure.com/<subscription>/resourceGroups/<res-group>/providers/Microsoft.Web/sites/<app-name>/hostruntime/admin/vfs/function_app.py?relativePath=1&api-version=2022-03-01"
|
||||
```
|
||||
## Escalation dei privilegi
|
||||
## Elevazione dei privilegi
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-functions-app-privesc.md
|
||||
|
||||
Reference in New Issue
Block a user