diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md index 5c3e16cf9..7b6058025 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md @@ -24,16 +24,16 @@ 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 per il 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 del 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** costituiscono tutti gli altri account in un'organizzazione. Un account può essere membro di un'unica 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). ``` aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com ``` ### **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 @@ -42,7 +42,7 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU 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 eliminare backup.\ +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 eliminare backup.\ L'unico modo per bypassare questo è compromettere anche l'**account master** che configura le SCP (l'account master non può essere bloccato). > [!WARNING] @@ -53,7 +53,7 @@ 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 Access da +- Negare a GuardDuty, CloudTrail e S3 Public Block Access di essere disabilitati @@ -102,25 +102,25 @@ 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 viene concesso l'accesso a una risorsa sicura. +- **Controllo degli Accessi** - Il metodo e il processo di come l'accesso è concesso a una risorsa sicura. IAM può essere definito dalla sua capacità di gestire, controllare e governare i meccanismi di autenticazione, autorizzazione e controllo degli accessi delle identità alle tue risorse all'interno del tuo account AWS. ### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) -Quando crei per la prima volta un account Amazon Web Services (AWS), inizi con un'unica identità di accesso che ha **accesso completo a tutti** i servizi e le risorse AWS nell'account. Questo è l'_**utente root**_ dell'account AWS e viene accesso effettuando il login con **l'indirizzo email e la password che hai usato per creare l'account**. +Quando crei per la prima volta un account Amazon Web Services (AWS), inizi con un'identità di accesso singolo che ha **accesso completo a tutti** i servizi e le risorse AWS nell'account. Questo è l'_**utente root**_ dell'account AWS e viene accesso effettuando il login con **l'indirizzo email e la password che hai usato per creare l'account**. 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) 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)). @@ -129,8 +129,8 @@ Gli utenti possono avere **MFA abilitato per il login** attraverso la console. I - **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 gli ID delle chiavi di accesso segrete perse). -Ogni volta che hai bisogno di **cambiare la chiave di accesso**, 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_ +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 -> segna quella originale come inattiva -> Testa e verifica che la nuova chiave di accesso funzioni -> Elimina la vecchia chiave di accesso_ ### MFA - Multi Factor Authentication @@ -154,14 +154,14 @@ Come [**indicato qui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_cred 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ò rendere più facile gestire i permessi 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 utenti** in modo che tutti gli **utenti** nel gruppo utenti **ricevano i permessi 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 ai permessi, non all'autenticazione, e i principali 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 i permessi 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 ai permessi, non all'autenticazione, e i principali sono entità IAM autenticate. Ecco alcune caratteristiche importanti dei gruppi utenti: - 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 [quote IAM e AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). +- 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) @@ -175,7 +175,7 @@ Il Servizio di Token di Sicurezza AWS (STS) è un servizio web che facilita l'** ### [Credenziali temporanee in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) -**Le credenziali temporanee sono utilizzate principalmente con i ruoli IAM**, ma ci sono anche altri usi. Puoi richiedere credenziali temporanee che hanno un insieme di permessi più ristretto rispetto al tuo utente IAM standard. Questo **previene** che tu **esegua accidentalmente compiti non consentiti** dalle credenziali più ristrette. Un vantaggio delle credenziali temporanee è che scadono automaticamente dopo un periodo di tempo stabilito. Hai il controllo sulla durata per cui le credenziali sono valide. +Le **credenziali temporanee sono utilizzate principalmente con i ruoli IAM**, ma ci sono anche altri usi. Puoi richiedere credenziali temporanee che hanno un insieme di permessi più ristretto rispetto al tuo utente IAM standard. Questo **previene** che tu **esegua accidentalmente compiti non consentiti** dalle credenziali più ristrette. Un vantaggio delle credenziali temporanee è che scadono automaticamente dopo un periodo di tempo stabilito. Hai il controllo sulla durata per cui le credenziali sono valide. ### Politiche @@ -210,12 +210,12 @@ Se **esiste un singolo "Deny", sovrascriverà il "Allow"**, tranne per le richie ] } ``` -I [campi globali che possono essere utilizzati per le condizioni in qualsiasi servizio sono documentati qui](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\ -I [campi specifici che possono essere utilizzati per le condizioni per servizio sono documentati qui](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html). +I [campi globali che possono essere utilizzati per condizioni in qualsiasi servizio sono documentati qui](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\ +I [campi specifici che possono essere utilizzati per condizioni per servizio sono documentati qui](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html). #### Politiche Inline -Questo tipo di politiche sono **assegnate direttamente** a un utente, gruppo o ruolo. Quindi, non appaiono nell'elenco delle Politiche poiché nessun altro può usarle.\ +Questo tipo di politiche è **assegnato direttamente** a un utente, gruppo o ruolo. Quindi, non appaiono nell'elenco delle Politiche poiché nessun altro può usarle.\ Le politiche inline sono utili se si desidera **mantenere una relazione rigorosa uno a uno tra una politica e l'identità** a cui è applicata. Ad esempio, si vuole essere certi che i permessi in una politica non siano assegnati inavvertitamente a un'identità diversa da quella per cui sono destinati. Quando si utilizza una politica inline, i permessi nella politica non possono essere attaccati inavvertitamente all'identità sbagliata. Inoltre, quando si utilizza la Console di gestione AWS per eliminare quell'identità, le politiche incorporate nell'identità vengono eliminate anch'esse. Questo perché fanno parte dell'entità principale. #### Politiche dei Bucket di Risorse @@ -226,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 un ruolo dovrebbe avere accesso**. In questo modo, anche se un insieme diverso 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·, questo è 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·, quello è 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 ha il ruolo). +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). 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 @@ -250,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** la **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. @@ -273,13 +273,13 @@ 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 **qualsiasi degli account** dell'organizzazione. +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 un **ruolo che fida il Provider di Identità con le politiche indicate sarà creato** 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 il Centro Identità**, e verrà creato un **ruolo che fida il 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 a cui vengono dati **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**. @@ -329,7 +329,7 @@ In [**questa pagina**](https://docs.aws.amazon.com/IAM/latest/UserGuide/referenc | APKA | Chiave pubblica | | AROA | Ruolo | | ASCA | Certificato | -| ASIA | [ID chiavi di accesso temporanee (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilizzano questo prefisso, ma sono uniche 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 unici solo in combinazione con la chiave di accesso segreta e il token di sessione. | ### Permessi raccomandati per audit degli account @@ -348,7 +348,7 @@ 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`.\ +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 di credenziali con più di 1 profilo: ``` diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md index d4c6bee80..4c65b34dc 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md @@ -43,7 +43,7 @@ Il permesso `cloudformation:SetStackPolicy` può essere utilizzato per **darti i ### `cloudformation:UpdateStack` | `cloudformation:SetStackPolicy` -Se hai questo permesso ma **nessun `iam:PassRole`** puoi comunque **aggiornare gli stack** utilizzati e abusare dei **ruoli IAM che hanno già allegato**. Controlla la sezione precedente per un esempio di sfruttamento (basta non indicare alcun ruolo nell'aggiornamento). +Se hai questo permesso ma **nessun `iam:PassRole`**, puoi comunque **aggiornare gli stack** utilizzati e abusare dei **ruoli IAM che hanno già allegato**. Controlla la sezione precedente per un esempio di sfruttamento (basta non indicare alcun ruolo nell'aggiornamento). Il permesso `cloudformation:SetStackPolicy` può essere utilizzato per **darti il permesso `UpdateStack`** su uno stack e eseguire l'attacco.