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

Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA

Browse Source
This commit is contained in:
Translator
2025-03-17 03:51:53 +00:00
parent b1c7730155
commit 25110f3f71
3 changed files with 75 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
src/images/vm_to_aa.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 142 KiB

87
src/pentesting-cloud/aws-security/aws-basic-information/README.md
View File

@@ -8,7 +8,7 @@
### Account
In AWS c'è un **account root**, che è il **contenitore principale per tutti gli account** della tua **organizzazione**. Tuttavia, non è necessario utilizzare quell'account per distribuire risorse, puoi creare **altri account per separare le diverse infrastrutture AWS** tra di loro.
In AWS c'è un **account root**, che è il **contenitore principale per tutti gli account** della tua **organizzazione**. Tuttavia, non è necessario utilizzare quell'account per distribuire risorse, puoi creare **altri account per separare diverse infrastrutture AWS** tra di loro.
Questo è molto interessante dal punto di vista della **sicurezza**, poiché **un account non sarà in grado di accedere alle risorse di un altro account** (a meno che non vengano create specificamente delle bridge), in questo modo puoi creare confini tra le distribuzioni.
@@ -24,7 +24,7 @@ Pertanto, ci sono **due tipi di account in un'organizzazione** (stiamo parlando
- Abilitare l'integrazione con i servizi AWS supportati per fornire funzionalità di servizio a tutti gli account nell'organizzazione.
- È possibile accedere come utente root utilizzando l'email e la password utilizzate per creare questo account/organizzazione root.
L'account di gestione ha le **responsabilità di un account pagatore** ed è responsabile del pagamento di tutte le spese accumulate dagli account membri. Non puoi cambiare l'account di gestione di un'organizzazione.
L'account di gestione ha le **responsabilità di un account pagatore** ed è responsabile per il pagamento di tutte le spese accumulate dagli account membri. Non puoi cambiare l'account di gestione di un'organizzazione.
- Gli **account membri** costituiscono tutti gli altri account in un'organizzazione. Un account può essere membro di una sola organizzazione alla volta. Puoi allegare una politica a un account per applicare controlli solo a quell'account.
- Gli account membri **devono utilizzare un indirizzo email valido** e possono avere un **nome**, in generale non saranno in grado di gestire la fatturazione (ma potrebbero ricevere accesso ad essa).
@@ -33,17 +33,17 @@ aws organizations create-account --account-name testingaccount --email testingac
```
### **Unità Organizzative**
Gli account possono essere raggruppati in **Unità Organizzative (OU)**. In questo modo, puoi creare **politiche** per l'Unità Organizzativa che verranno **applicate a tutti gli account figli**. Tieni presente che un'OU può avere altre OU come figli.
Gli account possono essere raggruppati in **Unità Organizzative (OU)**. In questo modo, puoi creare **politiche** per l'Unità Organizzativa che verranno **applicate a tutti gli account figli**. Nota che un'OU può avere altre OU come figli.
```bash
# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
```
### Service Control Policy (SCP)
Una **service control policy (SCP)** è una politica che specifica i servizi e le azioni che gli utenti e i ruoli possono utilizzare negli account che la SCP influisce. Le SCP sono **simili alle politiche di autorizzazione IAM** tranne per il fatto che **non concedono alcuna autorizzazione**. Invece, le SCP specificano le **autorizzazioni massime** per un'organizzazione, un'unità organizzativa (OU) o un account. Quando si allega una SCP alla radice dell'organizzazione o a un'OU, le **SCP limitano le autorizzazioni per le entità negli account membri**.
Una **service control policy (SCP)** è una politica che specifica i servizi e le azioni che gli utenti e i ruoli possono utilizzare negli account che la SCP influisce. Le SCP sono **simili alle politiche di autorizzazione IAM** tranne per il fatto che **non concedono alcuna autorizzazione**. Invece, le SCP specificano le **autorizzazioni massime** per un'organizzazione, un'unità organizzativa (OU) o un account. Quando si allega una SCP alla radice dell'organizzazione o a un'OU, la **SCP limita le autorizzazioni per le entità negli account membri**.
Questo è l'UNICO modo in cui **anche l'utente root può essere bloccato** dal fare qualcosa. Ad esempio, potrebbe essere utilizzato per impedire agli utenti di disabilitare CloudTrail o di eliminare i backup.\
L'unico modo per bypassare questo è compromettere anche il **master account** che configura le SCP (il master account non può essere bloccato).
Questo è l'UNICO modo in cui **anche l'utente root può essere fermato** dal fare qualcosa. Ad esempio, potrebbe essere utilizzato per impedire agli utenti di disabilitare CloudTrail o di eliminare i backup.\
L'unico modo per bypassare questo è compromettere anche l'**account master** che configura le SCP (l'account master non può essere bloccato).
> [!WARNING]
> Nota che **le SCP limitano solo i principi nell'account**, quindi altri account non sono influenzati. Questo significa che avere una SCP che nega `s3:GetObject` non fermerà le persone dall'**accedere a un bucket S3 pubblico** nel tuo account.
@@ -53,19 +53,37 @@ Esempi di SCP:
- Negare completamente l'account root
- Consentire solo regioni specifiche
- Consentire solo servizi in whitelist
- Negare l'accesso a GuardDuty, CloudTrail e S3 Public Block da
- Negare a GuardDuty, CloudTrail e S3 Public Block Access di
essere disabilitati
- Negare che i ruoli di sicurezza/riposta agli incidenti vengano eliminati o
- Negare ai ruoli di sicurezza/risposta agli incidenti di essere eliminati o
modificati.
- Negare che i backup vengano eliminati.
- Negare l'eliminazione dei backup.
- Negare la creazione di utenti IAM e chiavi di accesso
Trova **esempi JSON** in [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
### Resource Control Policy (RCP)
Una **resource control policy (RCP)** è una politica che definisce le **autorizzazioni massime per le risorse all'interno della tua organizzazione AWS**. Le RCP sono simili alle politiche IAM nella sintassi ma **non concedono autorizzazioni**—limitano solo le autorizzazioni che possono essere applicate alle risorse da altre politiche. Quando si allega una RCP alla radice dell'organizzazione, a un'unità organizzativa (OU) o a un account, la RCP limita le autorizzazioni delle risorse su tutte le risorse nell'ambito interessato.
Questo è l'UNICO modo per garantire che **le risorse non possano superare i livelli di accesso predefiniti**—anche se una politica basata su identità o risorsa è troppo permissiva. L'unico modo per bypassare questi limiti è modificare anche la RCP configurata dall'account di gestione della tua organizzazione.
> [!WARNING]
> Le RCP limitano solo le autorizzazioni che le risorse possono avere. Non controllano direttamente cosa possono fare i principi. Ad esempio, se una RCP nega l'accesso esterno a un bucket S3, garantisce che le autorizzazioni del bucket non consentano mai azioni oltre il limite impostato—anche se una politica basata su risorsa è configurata in modo errato.
Esempi di RCP:
- Limitare i bucket S3 in modo che possano essere accessibili solo da principi all'interno della tua organizzazione
- Limitare l'uso delle chiavi KMS per consentire solo operazioni da account organizzativi fidati
- Limitare le autorizzazioni sulle code SQS per prevenire modifiche non autorizzate
- Applicare confini di accesso sui segreti di Secrets Manager per proteggere dati sensibili
Trova esempi nella [documentazione delle Resource Control Policies di AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)
### ARN
**Amazon Resource Name** è il **nome unico** che ogni risorsa all'interno di AWS ha, è composto in questo modo:
@@ -84,7 +102,7 @@ Nota che ci sono 4 partizioni in AWS ma solo 3 modi per chiamarle:
IAM è il servizio che ti permetterà di gestire **Autenticazione**, **Autorizzazione** e **Controllo degli Accessi** all'interno del tuo account AWS.
- **Autenticazione** - Processo di definizione di un'identità e verifica di quell'identità. Questo processo può essere suddiviso in: Identificazione e verifica.
- **Autenticazione** - Processo di definizione di un'identità e la verifica di quell'identità. Questo processo può essere suddiviso in: Identificazione e verifica.
- **Autorizzazione** - Determina a cosa un'identità può accedere all'interno di un sistema una volta che è stata autenticata.
- **Controllo degli Accessi** - Il metodo e il processo di come l'accesso è concesso a una risorsa sicura.
@@ -96,20 +114,20 @@ Quando crei per la prima volta un account Amazon Web Services (AWS), inizi con u
Nota che un nuovo **utente admin** avrà **meno permessi dell'utente root**.
Da un punto di vista della sicurezza, è consigliato creare altri utenti ed evitare di utilizzare questo.
Dal punto di vista della sicurezza, è consigliato creare altri utenti ed evitare di utilizzare questo.
### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
Un _utente_ IAM è un'entità che crei in AWS per **rappresentare la persona o l'applicazione** che lo utilizza per **interagire con AWS**. Un utente in AWS consiste in un nome e credenziali (password e fino a due chiavi di accesso).
Quando crei un utente IAM, gli concedi **permessi** rendendolo un **membro di un gruppo di utenti** che ha politiche di permesso appropriate collegate (consigliato), o **allegando direttamente le politiche** all'utente.
Quando crei un utente IAM, gli concedi **permessi** rendendolo un **membro di un gruppo di utenti** che ha politiche di permesso appropriate collegate (consigliato), o **allegando direttamente politiche** all'utente.
Gli utenti possono avere **MFA abilitato per il login** attraverso la console. I token API degli utenti con MFA abilitato non sono protetti da MFA. Se desideri **limitare l'accesso delle chiavi API di un utente utilizzando MFA**, devi indicare nella politica che per eseguire determinate azioni è necessaria la presenza di MFA (esempio [**qui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
#### CLI
- **Access Key ID**: 20 caratteri alfanumerici casuali in maiuscolo come AKHDNAPO86BSHKDIRYT
- **Secret access key ID**: 40 caratteri casuali in maiuscolo e minuscolo: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Non è possibile recuperare le chiavi di accesso segrete perse).
- **Secret access key ID**: 40 caratteri casuali in maiuscolo e minuscolo: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Non è possibile recuperare gli ID delle chiavi di accesso segrete perse).
Ogni volta che hai bisogno di **cambiare la Access Key**, questo è il processo che dovresti seguire:\
_Crea una nuova chiave di accesso -> Applica la nuova chiave al sistema/applicazione -> contrassegna quella originale come inattiva -> Testa e verifica che la nuova chiave di accesso funzioni -> Elimina la vecchia chiave di accesso_
@@ -132,18 +150,18 @@ aws sts get-session-token --serial-number <arn_device> --token-code <code>
```
Come [**indicato qui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), ci sono molti casi diversi in cui **MFA non può essere utilizzato**.
### [Gruppi di utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
### [Gruppi utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
Un [gruppo di utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) è un modo per **allegare politiche a più utenti** contemporaneamente, il che può semplificare la gestione delle autorizzazioni per quegli utenti. **I ruoli e i gruppi non possono far parte di un gruppo**.
Un [gruppo utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) è un modo per **allegare politiche a più utenti** contemporaneamente, il che può semplificare la gestione delle autorizzazioni per quegli utenti. **I ruoli e i gruppi non possono far parte di un gruppo**.
Puoi allegare una **politica basata sull'identità a un gruppo di utenti** in modo che tutti gli **utenti** nel gruppo di utenti **ricevano le autorizzazioni della politica**. Non puoi **identificare un gruppo di utenti** come un **`Principal`** in una **politica** (come una politica basata sulle risorse) perché i gruppi si riferiscono alle autorizzazioni, non all'autenticazione, e i principal sono entità IAM autenticate.
Puoi allegare una **politica basata sull'identità a un gruppo utenti** in modo che tutti gli **utenti** nel gruppo utenti **ricevano le autorizzazioni della politica**. Non puoi **identificare un gruppo utenti** come un **`Principal`** in una **politica** (come una politica basata sulle risorse) perché i gruppi si riferiscono alle autorizzazioni, non all'autenticazione, e i principali sono entità IAM autenticate.
Ecco alcune caratteristiche importanti dei gruppi di utenti:
Ecco alcune caratteristiche importanti dei gruppi utenti:
- Un **gruppo** di utenti può **contenere molti utenti**, e un **utente** può **appartenere a più gruppi**.
- **I gruppi di utenti non possono essere annidati**; possono contenere solo utenti, non altri gruppi di utenti.
- Non esiste **un gruppo di utenti predefinito che include automaticamente tutti gli utenti nell'account AWS**. Se desideri avere un gruppo di utenti di questo tipo, devi crearlo e assegnare ogni nuovo utente ad esso.
- Il numero e la dimensione delle risorse IAM in un account AWS, come il numero di gruppi e il numero di gruppi di cui un utente può essere membro, sono limitati. Per ulteriori informazioni, vedere [quote IAM e AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
- Un **gruppo** utenti può **contenere molti utenti**, e un **utente** può **appartenere a più gruppi**.
- **I gruppi utenti non possono essere annidati**; possono contenere solo utenti, non altri gruppi utenti.
- Non esiste **un gruppo utenti predefinito che include automaticamente tutti gli utenti nell'account AWS**. Se desideri avere un gruppo utenti di questo tipo, devi crearlo e assegnare ogni nuovo utente ad esso.
- Il numero e la dimensione delle risorse IAM in un account AWS, come il numero di gruppi e il numero di gruppi di cui un utente può essere membro, sono limitati. Per ulteriori informazioni, vedere [IAM e AWS STS quote](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
### [Ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
@@ -208,15 +226,15 @@ Se un principale non ha un diniego esplicito su di esse, e una politica di risor
### Limiti IAM
I limiti IAM possono essere utilizzati per **limitare i permessi a cui un utente o ruolo dovrebbe avere accesso**. In questo modo, anche se un diverso insieme di permessi viene concesso all'utente da una **politica diversa**, l'operazione **fallirà** se tenta di usarli.
I limiti IAM possono essere utilizzati per **limitare i permessi a cui un utente o un ruolo dovrebbe avere accesso**. In questo modo, anche se un diverso insieme di permessi viene concesso all'utente da una **politica diversa**, l'operazione **fallirà** se tenta di usarli.
Un limite è semplicemente una politica allegata a un utente che **indica il livello massimo di permessi che l'utente o il ruolo può avere**. Quindi, **anche se l'utente ha accesso da Amministratore**, se il limite indica che può solo leggere i bucket S·, quello è il massimo che può fare.
Un limite è semplicemente una politica allegata a un utente che **indica il livello massimo di permessi che l'utente o il ruolo può avere**. Quindi, **anche se l'utente ha accesso da Amministratore**, se il limite indica che può solo leggere i bucket S·, questo è il massimo che può fare.
**Questo**, **SCP** e **seguire il principio del minimo privilegio** sono i modi per controllare che gli utenti non abbiano più permessi di quelli di cui hanno bisogno.
### Politiche di Sessione
Una politica di sessione è una **politica impostata quando un ruolo viene assunto** in qualche modo. Questo sarà come un **limite IAM per quella sessione**: Questo significa che la politica di sessione non concede permessi ma **li restringe a quelli indicati nella politica** (essendo i permessi massimi quelli che il ruolo ha).
Una politica di sessione è una **politica impostata quando un ruolo viene assunto** in qualche modo. Questo sarà come un **limite IAM per quella sessione**: Questo significa che la politica di sessione non concede permessi ma **li restringe a quelli indicati nella politica** (essendo i permessi massimi quelli che ha il ruolo).
Questo è utile per **misure di sicurezza**: Quando un amministratore sta per assumere un ruolo molto privilegiato, potrebbe restringere il permesso solo a quelli indicati nella politica di sessione nel caso in cui la sessione venga compromessa.
```bash
@@ -232,7 +250,7 @@ Pertanto, se a un certo punto ti trovi di fronte all'errore "... perché nessuna
### Federazione dell'Identità
La federazione dell'identità **consente agli utenti di provider di identità esterni** ad AWS di accedere in modo sicuro alle risorse AWS senza dover fornire le credenziali di un utente AWS da un account IAM valido.\
La federazione dell'identità **consente agli utenti di provider di identità che sono esterni** ad AWS di accedere alle risorse AWS in modo sicuro senza dover fornire le credenziali di un utente AWS da un account IAM valido.\
Un esempio di provider di identità può essere il tuo **Microsoft Active Directory** aziendale (tramite **SAML**) o i servizi **OpenID** (come **Google**). L'accesso federato consentirà quindi agli utenti al suo interno di accedere ad AWS.
Per configurare questa fiducia, viene generato un **Provider di Identità IAM (SAML o OAuth)** che **fiducia** nella **altra piattaforma**. Poi, almeno un **ruolo IAM è assegnato (fiducioso) al Provider di Identità**. Se un utente della piattaforma fidata accede ad AWS, accederà come il ruolo menzionato.
@@ -257,11 +275,11 @@ Per accedere agli utenti, ci sono 3 fonti di identità che possono essere utiliz
Nel caso più semplice della directory del Centro Identità, il **Centro Identità avrà un elenco di utenti e gruppi** e sarà in grado di **assegnare politiche** a loro per **uno qualsiasi degli account** dell'organizzazione.
Per dare accesso a un utente/gruppo del Centro Identità a un account, verrà creato un **Provider di Identità SAML che fida il Centro Identità**, e verrà creato un **ruolo che fida il Provider di Identità con le politiche indicate** nell'account di destinazione.
Per dare accesso a un utente/gruppo del Centro Identità a un account, verrà creato un **Provider di Identità SAML che fida nel Centro Identità**, e verrà creato un **ruolo che fida nel Provider di Identità con le politiche indicate** nell'account di destinazione.
#### AwsSSOInlinePolicy
È possibile **dare permessi tramite politiche inline ai ruoli creati tramite IAM Identity Center**. I ruoli creati negli account che ricevono **politiche inline in AWS Identity Center** avranno questi permessi in una politica inline chiamata **`AwsSSOInlinePolicy`**.
È possibile **dare permessi tramite politiche inline ai ruoli creati tramite IAM Identity Center**. I ruoli creati negli account a cui vengono date **politiche inline in AWS Identity Center** avranno questi permessi in una politica inline chiamata **`AwsSSOInlinePolicy`**.
Pertanto, anche se vedi 2 ruoli con una politica inline chiamata **`AwsSSOInlinePolicy`**, **non significa che abbia gli stessi permessi**.
@@ -277,10 +295,10 @@ Non supportato:
- Relazioni di Fiducia
- Centro Amministrativo AD
- Supporto completo per PS API
- Cestino di Riciclo AD
- Cestino AD
- Account di Servizio Gestiti da Gruppo
- Estensioni di Schema
- Nessun accesso diretto a OS o Istanze
- Nessun accesso diretto a OS o Istanza
#### Federazione Web o Autenticazione OpenID
@@ -288,7 +306,7 @@ L'app utilizza AssumeRoleWithWebIdentity per creare credenziali temporanee. Tutt
### Altre opzioni IAM
- Puoi **impostare un'impostazione della politica delle password** con opzioni come lunghezza minima e requisiti per la password.
- Puoi **impostare una politica di password** con opzioni come lunghezza minima e requisiti per la password.
- Puoi **scaricare il "Rapporto Credenziali"** con informazioni sulle credenziali attuali (come il tempo di creazione dell'utente, se la password è abilitata...). Puoi generare un rapporto credenziali fino a una volta ogni **quattro ore**.
AWS Identity and Access Management (IAM) fornisce **controllo degli accessi dettagliato** su tutto AWS. Con IAM, puoi specificare **chi può accedere a quali servizi e risorse**, e sotto quali condizioni. Con le politiche IAM, gestisci i permessi per la tua forza lavoro e i sistemi per **garantire permessi minimi**.
@@ -302,7 +320,7 @@ In [**questa pagina**](https://docs.aws.amazon.com/IAM/latest/UserGuide/referenc
| ABIA | [Token bearer del servizio AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| ACCA | Credenziale specifica per contesto |
| AGPA | Gruppo utente |
| AGPA | Gruppo utenti |
| AIDA | Utente IAM |
| AIPA | Profilo istanza Amazon EC2 |
| AKIA | Chiave di accesso |
@@ -311,7 +329,7 @@ In [**questa pagina**](https://docs.aws.amazon.com/IAM/latest/UserGuide/referenc
| APKA | Chiave pubblica |
| AROA | Ruolo |
| ASCA | Certificato |
| ASIA | [ID chiave di accesso temporanea (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilizza questo prefisso, ma è unico solo in combinazione con la chiave di accesso segreta e il token di sessione. |
| ASIA | [ID chiavi di accesso temporanee (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) usano questo prefisso, ma sono uniche solo in combinazione con la chiave di accesso segreta e il token di sessione. |
### Permessi raccomandati per audit degli account
@@ -330,8 +348,8 @@ I seguenti privilegi concedono vari accessi in lettura ai metadati:
### Autenticazione CLI
Affinché un utente normale si autentichi ad AWS tramite CLI, è necessario avere **credenziali locali**. Per impostazione predefinita, puoi configurarle **manualmente** in `~/.aws/credentials` o **eseguendo** `aws configure`.\
In quel file puoi avere più di un profilo, se **nessun profilo** è specificato utilizzando **aws cli**, verrà utilizzato quello chiamato **`[default]`** in quel file.\
Affinché un utente regolare si autentichi ad AWS tramite CLI, è necessario avere **credenziali locali**. Per impostazione predefinita, puoi configurarle **manualmente** in `~/.aws/credentials` o **eseguendo** `aws configure`.\
In quel file puoi avere più di un profilo, se **nessun profilo** è specificato utilizzando il **aws cli**, verrà utilizzato quello chiamato **`[default]`** in quel file.\
Esempio di file delle credenziali con più di 1 profilo:
```
[default]
@@ -366,5 +384,6 @@ Se stai cercando qualcosa di **simile** a questo ma per il **browser**, puoi con
- [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
- [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/)
- [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)
- [https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/](https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/)
{{#include ../../../banners/hacktricks-training.md}}

33
src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md
View File

@@ -12,12 +12,23 @@ Per ulteriori informazioni controlla:
### Hybrid Workers Group
Ricorda che se in qualche modo un attaccante può eseguire un runbook arbitrario (codice arbitrario) in un hybrid worker, egli **si sposterà verso la posizione della VM**. Questo potrebbe essere una macchina on-premise, una VPC di un cloud diverso o anche una VM di Azure.
- **Dall'Automation Account alla VM**
Inoltre, se l'hybrid worker è in esecuzione in Azure con altre Managed Identities collegate, il runbook sarà in grado di accedere all'**identità gestita del runbook e a tutte le identità gestite della VM dal servizio di metadata**.
Ricorda che se in qualche modo un attaccante può eseguire un runbook arbitrario (codice arbitrario) in un hybrid worker, egli **si sposterà verso la posizione della VM**. Questa potrebbe essere una macchina on-premise, una VPC di un altro cloud o anche una VM di Azure.
Inoltre, se l'hybrid worker è in esecuzione in Azure con altre Managed Identities collegate, il runbook sarà in grado di accedere all'**identità gestita del runbook e a tutte le identità gestite della VM dal servizio metadata**.
> [!TIP]
> Ricorda che il **servizio di metadata** ha un URL diverso (**`http://169.254.169.254`**) rispetto al servizio da cui ottenere il token delle identità gestite dell'account di automazione (**`IDENTITY_ENDPOINT`**).
> Ricorda che il **servizio metadata** ha un URL diverso (**`http://169.254.169.254`**) rispetto al servizio da cui ottenere il token delle identità gestite dell'account di automazione (**`IDENTITY_ENDPOINT`**).
- **Dalla VM all'Automation Account**
Inoltre, se qualcuno compromette una VM in cui è in esecuzione uno script dell'account di automazione, sarà in grado di localizzare i metadati dell'**Automation Account** e accedervi dalla VM per ottenere token per le **Managed Identities** collegate all'Automation Account.
Come è possibile vedere nell'immagine seguente, avendo accesso da Amministratore sulla VM è possibile trovare nelle **variabili d'ambiente del processo** l'URL e il segreto per accedere al servizio metadata dell'account di automazione:
![](</images/vm_to_aa.jpg>)
### `Microsoft.Automation/automationAccounts/jobs/write`, `Microsoft.Automation/automationAccounts/runbooks/draft/write`, `Microsoft.Automation/automationAccounts/jobs/output/read`, `Microsoft.Automation/automationAccounts/runbooks/publish/action` (`Microsoft.Resources/subscriptions/resourcegroups/read`, `Microsoft.Automation/automationAccounts/runbooks/write`)
@@ -38,7 +49,7 @@ $creds.GetNetworkCredential().password'
```
Nota come lo script precedente può essere utilizzato per **leak the useranmd and password** di una credenziale e il valore di una **encrypted variable** memorizzata nell'Automation Account.
Il permesso **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** consente all'utente di pubblicare un Runbook nell'Automation Account in modo che le modifiche vengano applicate:
Il permesso **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** consente all'utente di pubblicare un Runbook nell'Automation Account affinché le modifiche vengano applicate:
```bash
az automation runbook publish \
--resource-group <res-group> \
@@ -64,7 +75,7 @@ az automation runbook create --automation-account-name <account-name> --resource
```
### `Microsoft.Automation/automationAccounts/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`
Questo permesso consente all'utente di **assegnare un'identità gestita dall'utente** all'Automation Account utilizzando:
Questa autorizzazione consente all'utente di **assegnare un'identità gestita dall'utente** all'Automation Account utilizzando:
```bash
az rest --method PATCH \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>?api-version=2020-01-13-preview" \
@@ -104,7 +115,7 @@ az automation schedule create \
--frequency Minute \
--interval 15
```
Poi, con il permesso **`Microsoft.Automation/automationAccounts/jobSchedules/write`** è possibile assegnare un Scheduler a un runbook utilizzando:
Quindi, con il permesso **`Microsoft.Automation/automationAccounts/jobSchedules/write`** è possibile assegnare un Scheduler a un runbook utilizzando:
```bash
az rest --method PUT \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-accounts>/jobSchedules/b510808a-8fdc-4509-a115-12cfc3a2ad0d?api-version=2015-10-31" \
@@ -179,7 +190,7 @@ az rest --method get --url "https://management.azure.com/subscriptions/9291ff6e-
```
### `Microsoft.Automation/automationAccounts/sourceControls/write`, (`Microsoft.Automation/automationAccounts/sourceControls/read`)
Questa autorizzazione consente all'utente di **configurare un controllo sorgente** per l'Automation Account utilizzando comandi come i seguenti (questo utilizza Github come esempio):
Questa autorizzazione consente all'utente di **configurare un controllo di origine** per l'Account di Automazione utilizzando comandi come i seguenti (questo utilizza Github come esempio):
```bash
az automation source-control create \
--resource-group <res-group> \
@@ -194,12 +205,12 @@ az automation source-control create \
--token-type PersonalAccessToken \
--access-token github_pat_11AEDCVZ<rest-of-the-token>
```
Questo importerà automaticamente i runbook dal repository Github nell'Automation Account e con alcuni altri permessi per iniziare a eseguirli sarebbe **possibile escalare i privilegi**.
Questo importerà automaticamente i runbook dal repository Github all'Automation Account e con alcuni altri permessi per iniziare a eseguirli sarebbe **possibile escalare i privilegi**.
Inoltre, ricorda che per il controllo della sorgente per funzionare negli Automation Accounts deve avere un'identità gestita con il ruolo **`Contributor`** e se è un'identità gestita dall'utente, l'ID client della MI deve essere specificato nella variabile **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.
Inoltre, ricorda che per il controllo del codice sorgente per funzionare negli Automation Accounts deve avere un'identità gestita con il ruolo **`Contributor`** e se è un'identità gestita dall'utente, l'ID client della MI deve essere specificato nella variabile **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.
> [!TIP]
> Nota che non è possibile cambiare l'URL del repo di un controllo sorgente una volta creato.
> Nota che non è possibile cambiare l'URL del repo di un controllo del codice sorgente una volta creato.
### `Microsoft.Automation/automationAccounts/variables/write`
@@ -255,7 +266,7 @@ Lo script viene modificato per specificare la VM Windows target e la porta per l
- Step 5 — Pubblica il file di configurazione
Il file di configurazione viene eseguito, risultando nel deployment dello script reverse-shell nella posizione specificata sulla VM Windows.
Il file di configurazione viene eseguito, risultando nel deployment dello script della reverse shell nella posizione specificata sulla VM Windows.
- Step 6 — Ospita il payload e imposta il listener