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

Translated ['src/pentesting-cloud/azure-security/az-services/az-automati

Browse Source
This commit is contained in:
Translator
2025-02-12 13:50:45 +00:00
parent 5c5f9e22ac
commit a6329a337b
4 changed files with 27 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
src/pentesting-cloud/azure-security/az-services/az-automation-accounts.md
View File

@@ -1,10 +1,10 @@
# Az - Automation Accounts
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Informazioni di base
Gli Azure Automation Accounts sono servizi basati sul cloud in Microsoft Azure che aiutano a **automatizzare i compiti** come la gestione delle risorse, la configurazione e gli aggiornamenti attraverso Azure e ambienti on-premises. Forniscono **Runbooks** (script per l'automazione che vengono eseguiti), **programmazioni** e **gruppi di lavoratori ibridi** per eseguire **lavori di automazione**, abilitando l'infrastruttura come codice (IaC) e l'automazione dei processi per migliorare l'efficienza e la coerenza nella gestione delle risorse cloud.
Gli Azure Automation Accounts sono servizi basati sul cloud in Microsoft Azure che aiutano a **automatizzare i compiti** come la gestione delle risorse, la configurazione e gli aggiornamenti in ambienti Azure e on-premises. Forniscono **Runbooks** (script per l'automazione che vengono eseguiti), **programmazioni** e **gruppi di lavoratori ibridi** per eseguire **lavori** di automazione, abilitando l'infrastruttura come codice (IaC) e l'automazione dei processi per migliorare l'efficienza e la coerenza nella gestione delle risorse cloud.
### Impostazioni
@@ -32,8 +32,8 @@ Un lavoro contiene l'**output** dell'**esecuzione del Runbook**. Se puoi **legge
Ci sono 3 modi principali per eseguire un Runbook:
- **Programmazioni**: Queste vengono utilizzate per **attivare** i Runbooks a un **orario specifico** o **intervallo**.
- **Webhook**: Questi sono **endpoint HTTP** che possono essere utilizzati per **attivare** i Runbooks da **servizi esterni**. Nota che l'URL del webhook è **non visibile** dopo la creazione.
- **Programmazioni**: Queste vengono utilizzate per **attivare** i Runbooks a un **orario specifico** o a **intervalli**.
- **Webhook**: Questi sono **endpoint HTTP** che possono essere utilizzati per **attivare** i Runbooks da **servizi esterni**. Nota che l'URL del webhook **non è visibile** dopo la creazione.
- **Attivazione manuale**: Puoi **attivare manualmente** un Runbook dal Portale Azure e dalla CLI.
### Controllo del codice sorgente
@@ -44,7 +44,7 @@ Quando la sincronizzazione è abilitata, nel **repository Github viene creato un
Nota che questi webhook **non saranno visibili** quando si elencano i webhook nei runbooks associati al repository Github. Inoltre, nota che **non è possibile cambiare l'URL del repository** di un controllo del codice sorgente una volta creato.
Affinché il controllo del codice sorgente configurato funzioni, l'**Azure Automation Account** deve avere un'identità gestita (sistema o utente) con il ruolo di **`Contributor`**. Inoltre, per assegnare un'identità gestita utente all'Automation Account, è necessario indicare l'ID client dell'utente MI nella variabile **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.
Affinché il controllo del codice sorgente configurato funzioni, l'**Azure Automation Account** deve avere un'identità gestita (di sistema o utente) con il ruolo di **`Contributor`**. Inoltre, per assegnare un'identità gestita a un'Automation Account, è necessario indicare l'ID client dell'utente MI nella variabile **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.
### Ambienti di esecuzione
@@ -57,16 +57,16 @@ Quando si crea un Runbook è possibile selezionare l'ambiente di esecuzione. Per
- **Python 3.8**
- **Python 2.7**
Tuttavia, è anche possibile **creare i propri ambienti**, utilizzando uno di questi come base. Nel caso di Python, è possibile caricare pacchetti `.whl` nell'ambiente che verranno utilizzati. Nel caso di PowerShell, è possibile caricare pacchetti `.zip` con i moduli da avere nell'esecuzione.
Tuttavia, è anche possibile **creare i propri ambienti**, utilizzando uno di questi come base. Nel caso di Python, è possibile caricare pacchetti `.whl` nell'ambiente che verrà utilizzato. Nel caso di PowerShell, è possibile caricare pacchetti `.zip` con i moduli da avere nell'esecuzione.
### Gruppi di lavoratori ibridi
In Azure Automation, l'ambiente di esecuzione predefinito per i runbooks è il **Azure Sandbox**, una piattaforma basata sul cloud gestita da Azure, adatta per compiti che coinvolgono risorse Azure. Tuttavia, questo sandbox ha limitazioni, come l'accesso ristretto alle risorse on-premises e vincoli sul tempo di esecuzione e sull'uso delle risorse. Per superare queste limitazioni, vengono impiegati i Gruppi di Lavoratori Ibridi. Un Gruppo di Lavoratori Ibridi è composto da **uno o più Hybrid Runbook Workers installati sulle proprie macchine**, sia on-premises, in altri ambienti cloud o VM Azure. Questa configurazione consente ai runbooks di eseguire direttamente su queste macchine, fornendo accesso diretto alle risorse locali, la possibilità di eseguire compiti più lunghi e intensivi in termini di risorse, e la flessibilità di interagire con ambienti al di là della portata immediata di Azure.
In Azure Automation, l'ambiente di esecuzione predefinito per i runbook è il **Azure Sandbox**, una piattaforma basata sul cloud gestita da Azure, adatta per compiti che coinvolgono risorse Azure. Tuttavia, questo sandbox ha limitazioni, come l'accesso ristretto alle risorse on-premises e vincoli sul tempo di esecuzione e sull'uso delle risorse. Per superare queste limitazioni, vengono impiegati i Gruppi di Lavoratori Ibridi. Un Gruppo di Lavoratori Ibridi è composto da **uno o più Hybrid Runbook Workers installati sulle proprie macchine**, sia on-premises, in altri ambienti cloud o VM Azure. Questa configurazione consente ai runbook di essere eseguiti direttamente su queste macchine, fornendo accesso diretto alle risorse locali, la possibilità di eseguire compiti più lunghi e intensivi in termini di risorse, e la flessibilità di interagire con ambienti al di là della portata immediata di Azure.
Quando viene creato un gruppo di lavoratori ibridi, è necessario indicare le **credenziali** da utilizzare. Ci sono 2 opzioni:
- **Credenziali predefinite**: Non è necessario fornire le credenziali e i runbooks verranno eseguiti all'interno delle VM come **Sistema**.
- **Credenziali specifiche**: È necessario fornire il nome dell'oggetto credenziali all'interno dell'account di automazione, che verrà utilizzato per eseguire i **runbooks all'interno delle VM**. Pertanto, in questo caso, potrebbe essere possibile **rubare credenziali valide** per le VM.
- **Credenziali predefinite**: Non è necessario fornire le credenziali e i runbook verranno eseguiti all'interno delle VM come **Sistema**.
- **Credenziali specifiche**: È necessario fornire il nome dell'oggetto credenziali all'interno dell'account di automazione, che verrà utilizzato per eseguire i **runbook all'interno delle VM**. Pertanto, in questo caso, potrebbe essere possibile **rubare credenziali valide** per le VM.
Pertanto, se puoi scegliere di eseguire un **Runbook** in un **Lavoratore Ibrido**, eseguirai **comandi arbitrari** all'interno di una macchina esterna come **Sistema** (ottima tecnica di pivot).
@@ -77,10 +77,10 @@ Inoltre, se il lavoratore ibrido è in esecuzione in Azure con altre identità g
### Configurazione dello stato (SC)
>[!WARNING]
> Come indicato in [documentazione](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview), Azure Automation State Configuration sarà ritirato il 30 settembre 2027 e sostituito da [Azure Machine Configuration](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview).
> [!WARNING]
> Come indicato nella [documentazione](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview), la Configurazione dello Stato di Azure Automation sarà ritirata il 30 settembre 2027 e sostituita da [Azure Machine Configuration](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview).
Gli Automation Accounts supportano anche la **Configurazione dello Stato (SC)**, che è una funzionalità che aiuta a **configurare** e **mantenere** lo **stato** delle tue VM. È possibile **creare** e **applicare** configurazioni DSC a **macchine Windows** e **Linux**.
Gli Automation Accounts supportano anche la **Configurazione dello Stato (SC)**, che è una funzionalità che aiuta a **configurare** e **mantenere** lo **stato** delle tue VM. È possibile **creare** e **applicare** configurazioni DSC a macchine **Windows** e **Linux**.
Dal punto di vista di un attaccante, questo era interessante perché consentiva di **eseguire codice PS arbitrario in tutte le VM configurate**, consentendo di elevare i privilegi alle identità gestite di queste VM, potenzialmente pivotando verso nuove reti... Inoltre, le configurazioni potrebbero contenere **informazioni sensibili**.
@@ -238,4 +238,4 @@ Get-AzAutomationHybridWorkerGroup -AutomationAccountName <AUTOMATION-ACCOUNT> -R
- [https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview)
- [https://github.com/rootsecdev/Azure-Red-Team#runbook-automation](https://github.com/rootsecdev/Azure-Red-Team#runbook-automation)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}

6
src/pentesting-cloud/azure-security/az-services/az-container-instances.md
View File

@@ -1,10 +1,10 @@
# Az - Container Instances
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Informazioni di base
Azure Container Instances (ACI) forniscono un **modo serverless e on-demand** per eseguire **container** nel cloud di Azure. Puoi **distribuire** uno o più container in un gruppo con **compute scalabile**, **opzioni di rete** e la flessibilità di connetterti ad **altri servizi Azure** (come Storage, Virtual Networks o Container Registries).
Azure Container Instances (ACI) forniscono un **modo serverless e on-demand** per eseguire **container** nel cloud Azure. Puoi **distribuire** uno o più container in un gruppo con **compute scalabile**, **opzioni di rete** e la flessibilità di connetterti ad **altri servizi Azure** (come Storage, Virtual Networks o Container Registries).
Poiché sono carichi di lavoro **effimeri**, non è necessario gestire l'infrastruttura VM sottostante: Azure si occupa di questo per te. Tuttavia, da una **prospettiva di sicurezza offensiva**, è fondamentale comprendere come **permessi**, **identità**, **configurazioni di rete** e **log** possano rivelare superfici di attacco e potenziali misconfigurazioni.
@@ -25,7 +25,7 @@ Poiché sono carichi di lavoro **effimeri**, non è necessario gestire l'infrast
## Enumerazione
> [!WARNING]
> Quando si enumera ACI, è possibile rivelare configurazioni sensibili come **variabili di ambiente**, **dettagli di rete** o **identità gestite**. Fai attenzione a registrarle o visualizzarle.
> Quando si enumerano ACI, è possibile rivelare configurazioni sensibili come **variabili di ambiente**, **dettagli di rete** o **identità gestite**. Fai attenzione a registrarle o visualizzarle.
```bash
# List all container instances in the subscription
az container list

18
src/pentesting-cloud/azure-security/az-services/az-container-registry.md
View File

@@ -1,10 +1,10 @@
# Az - Container Registry
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Informazioni di base
Azure Container Registry (ACR) è un registro privato e sicuro che consente di **memorizzare, gestire e accedere alle immagini dei container nel cloud Azure**. Si integra perfettamente con diversi servizi Azure, fornendo flussi di lavoro automatizzati per la creazione e il deployment su larga scala. Con funzionalità come la geo-replica e la scansione delle vulnerabilità, ACR aiuta a garantire sicurezza e conformità di livello enterprise per le applicazioni containerizzate.
Azure Container Registry (ACR) è un registro privato e sicuro che ti consente di **memorizzare, gestire e accedere alle immagini dei container nel cloud Azure**. Si integra perfettamente con diversi servizi Azure, fornendo flussi di lavoro automatizzati per la creazione e il deployment su larga scala. Con funzionalità come la geo-replica e la scansione delle vulnerabilità, ACR aiuta a garantire sicurezza e conformità di livello enterprise per le applicazioni containerizzate.
### Permessi
@@ -20,7 +20,7 @@ Questi sono i **diversi permessi** [secondo la documentazione](https://learn.mic
Ci sono anche alcuni **ruoli predefiniti** che possono essere assegnati, ed è anche possibile creare **ruoli personalizzati**.
![](</images/registry_roles.png>)
![](/images/registry_roles.png)
### Autenticazione
@@ -31,7 +31,7 @@ Ci sono 4 modi per autenticarsi a un ACR:
- **Con Entra ID**: Questo è il **metodo predefinito** per autenticarsi a un ACR. Utilizza il comando **`az acr login`** per autenticarsi all'ACR. Questo comando **memorizzerà le credenziali** nel file **`~/.docker/config.json`**. Inoltre, se stai eseguendo questo comando da un ambiente senza accesso a un socket docker come in una **cloud shell**, è possibile utilizzare il flag **`--expose-token`** per ottenere il **token** per autenticarsi all'ACR. Poi, per autenticarti, devi usare come nome utente `00000000-0000-0000-0000-000000000000` come: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
- **Con un account admin**: L'utente admin è disabilitato per impostazione predefinita, ma può essere abilitato e poi sarà possibile accedere al registro con il **nome utente** e la **password** dell'account admin con pieni permessi sul registro. Questo è ancora supportato perché alcuni servizi Azure lo utilizzano. Nota che **2 password** vengono create per questo utente e entrambe sono valide. Puoi abilitarlo con `az acr update -n <acrName> --admin-enabled true`. Nota che il nome utente è solitamente il nome del registro (e non `admin`).
- **Con un token**: È possibile creare un **token** con una **specifica `scope map`** (permessi) per accedere al registro. Poi, è possibile utilizzare questo nome di token come nome utente e alcune delle password generate per autenticarsi al registro con `docker login -u <registry-name> -p <password> aregistry-url>`
- **Con un token**: È possibile creare un **token** con una **mappa di scope specifica** (permessi) per accedere al registro. Poi, è possibile utilizzare questo nome di token come nome utente e alcune delle password generate per autenticarsi al registro con `docker login -u <registry-name> -p <password> aregistry-url>`
- **Con un Service Principal**: È possibile creare un **service principal** e assegnare un ruolo come **`AcrPull`** per scaricare immagini. Poi, sarà possibile **accedere al registro** utilizzando l'appId SP come nome utente e un segreto generato come password.
Esempio di script dalla [documentazione](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) per generare un SP con accesso su un registro:
@@ -63,17 +63,17 @@ Questo ti consente di **scansionare le immagini** nel registro per **vulnerabili
### Soft-delete
La funzione di **soft-delete** ti consente di **recuperare un registro eliminato** entro il numero di giorni indicato. Questa funzione è **disabilitata per impostazione predefinita**.
La funzione di **soft-delete** consente di **recuperare un registro eliminato** entro il numero di giorni indicato. Questa funzione è **disabilitata per impostazione predefinita**.
### Webhook
È possibile **creare webhook** all'interno dei registri. In questo webhook è necessario specificare l'URL dove una **richiesta sarà inviata ogni volta che viene eseguita un'azione di push o delete**. Inoltre, i Webhook possono indicare un ambito per indicare i repository (immagini) che saranno interessati. Ad esempio, 'foo:*' significa eventi sotto il repository 'foo'.
È possibile **creare webhook** all'interno dei registri. In questo webhook è necessario specificare l'URL dove una **richiesta sarà inviata ogni volta che viene eseguita un'azione di push o delete**. Inoltre, i Webhook possono indicare un ambito per indicare i repository (immagini) che saranno interessati. Ad esempio, 'foo:\*' significa eventi sotto il repository 'foo'.
Dal punto di vista di un attaccante, è interessante controllare questo **prima di eseguire qualsiasi azione** nel registro e rimuoverlo temporaneamente se necessario, per evitare di essere rilevati.
### Registri connessi
Questo consente fondamentalmente di **rispecchiare le immagini** da un registro a un altro, solitamente situato in locale.
Questo consente fondamentalmente di **rispecchiare le immagini** da un registro a un altro, solitamente situato on-premises.
Ha 2 modalità: **ReadOnly** e **ReadWrite**. Nella prima, le immagini vengono solo **scaricate** dal registro sorgente, e nella seconda, le immagini possono anche essere **caricate** nel registro sorgente.
@@ -94,7 +94,7 @@ az acr run --registry mycontainerregistry008 --cmd '$Registry/sample/hello-world
```
Tuttavia, ciò attiverà esecuzioni che non sono molto interessanti dal punto di vista di un attaccante poiché non hanno alcuna identità gestita ad esse associata.
Tuttavia, **tasks** possono avere un'**identità gestita di sistema e utente** ad esse associata. Questi tasks sono quelli utili per **escalare privilegi** nel container. Nella sezione di escalation dei privilegi è possibile vedere come utilizzare i tasks per escalare privilegi.
Tuttavia, **tasks** possono avere un'**identità gestita di sistema e utente** ad esse associata. Queste attività sono quelle utili per **escalare privilegi** nel contenitore. Nella sezione sull'escalation dei privilegi è possibile vedere come utilizzare le attività per escalare privilegi.
### Cache
@@ -154,4 +154,4 @@ az acr cache show --name <cache-name> --registry <registry-name>
- [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli)
- [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}