Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/

This commit is contained in:
Translator
2025-01-06 23:56:24 +00:00
parent 9b140bb3de
commit fb1d786be5
4 changed files with 16 additions and 18 deletions

View File

@@ -52,19 +52,15 @@ 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` - 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.
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.
Segui la descrizione nella sezione *Abusing Terraform State Files* della pagina *Terraform Security* per codice di exploit direttamente utilizzabile:
{{#ref}}
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 più autorizzazioni sui bucket, permettendogli di leggere, scrivere, modificare, eliminare ed esporre i bucket.
pentesting-ci-cd/terraform-security.md#ab
```bash
# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>

View File

@@ -124,7 +124,7 @@ az webapp deployment user set \
--user-name hacktricks \
--password 'W34kP@ssw0rd123!'
```
Poi, puoi utilizzare queste credenziali per **accedere alle piattaforme SCM e FTP**. Questo è anche un ottimo modo per mantenere la persistenza.
Poi, puoi usare 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`**.
@@ -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, se ad esempio 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, ad esempio, se 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"
@@ -266,7 +266,7 @@ https://graph.microsoft.com/v1.0/me/drive/root/children
> Nota che avere il permesso `Microsoft.Web/sites/config/list/action` e le credenziali SCM rende sempre possibile distribuire in un webapp (anche se era configurato per utilizzare un fornitore di terze parti) come menzionato in una sezione precedente.
> [!WARNING]
> Nota che avere i permessi sottostanti rende anche **possibile eseguire un container arbitrario** anche se il webapp era configurato diversamente.
> Nota che avere i permessi qui sotto rende anche **possibile eseguire un container arbitrario** anche se il webapp era configurato diversamente.
### `Microsoft.Web/sites/config/Write`, `Microsoft.Web/sites/config/Read`, `Microsoft.Web/sites/config/list/Action`, `Microsoft.Web/sites/Read`

View File

@@ -7,7 +7,7 @@
**Azure Function Apps** sono un **servizio di calcolo serverless** che consente di eseguire piccoli pezzi di codice, chiamati **funzioni**, senza gestire l'infrastruttura sottostante. Sono progettate per eseguire codice in risposta a vari trigger, come **richieste HTTP, timer o eventi da altri servizi Azure** come Blob Storage o Event Hubs. Le Function Apps supportano più linguaggi di programmazione, tra cui C#, Python, JavaScript e Java, rendendole versatili per costruire **applicazioni basate su eventi**, automatizzare flussi di lavoro o integrare servizi. Sono economiche, poiché di solito si paga solo per il tempo di calcolo utilizzato quando il codice viene eseguito.
> [!NOTE]
> Nota che **le Funzioni sono un sottoinsieme dei Servizi App**, pertanto, molte delle funzionalità discusse qui saranno utilizzate anche dalle applicazioni create come Azure Apps (`webapp` in cli).
> Nota che **le Funzioni sono un sottoinsieme dei Servizi App**, pertanto molte delle funzionalità discusse qui saranno utilizzate anche dalle applicazioni create come Azure Apps (`webapp` in cli).
### Piani Diversi
@@ -36,7 +36,7 @@ Nota che le Funzioni consentono anche di memorizzare il codice in una posizione
Utilizzando un trigger HTTP:
- È possibile dare **accesso a una funzione da tutto Internet** senza richiedere alcuna autenticazione o dare accesso basato su IAM. Anche se è possibile limitare questo accesso.
- È possibile dare **accesso a una funzione da tutto Internet** senza richiedere alcuna autenticazione o dare accesso basato su IAM. Sebbene sia anche possibile limitare questo accesso.
- È anche possibile **dare o limitare l'accesso** a una Function App da **una rete interna (VPC)**.
> [!CAUTION]
@@ -58,7 +58,7 @@ In una **funzione Windows** che utilizza NodeJS il codice si trovava in **`C:\ho
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** che l'ha 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** a cui è assegnata potrà utilizzare, mentre le identità gestite **assegnate dall'utente** sono identità gestite che **qualsiasi altro servizio Azure potrà utilizzare**.
> [!NOTE]
> 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.
@@ -69,14 +69,14 @@ L'**identità assegnata dal sistema** sarà un'identità gestita che **solo la f
{% embed url="https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#azure-vm" %}
Nota che devi trovare un modo per **controllare tutte le Identità Gestite a cui una funzione è collegata** poiché se non lo indichi, l'endpoint dei metadati utilizzerà **solo quella predefinita** (controlla il link precedente per ulteriori informazioni).
Nota che è necessario trovare un modo per **controllare tutte le Identità Gestite a cui una funzione è collegata** poiché se non lo indichi, l'endpoint dei metadati utilizzerà **solo quella predefinita** (controlla il link precedente per ulteriori informazioni).
## Chiavi di Accesso
> [!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,7 +84,7 @@ 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 **specifici endpoint di funzione** all'interno di una Function App consentendo un accesso più dettagliato sugli endpoint.
- **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 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.
@@ -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 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>`.
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>`.
> [!CAUTION]
> Pertanto, chiunque comprometta quel repository sarà in grado di compromettere la funzione e le Identità Gestite ad essa collegate.