Last updated
Impara e pratica il Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
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.
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 specifiche connessioni), in questo modo puoi creare confini tra le distribuzioni.
Pertanto, ci sono due tipi di account in un'organizzazione (stiamo parlando di account AWS e non di account utente): un singolo account designato come account di gestione e uno o più account membri.
L'account di gestione (l'account root) è l'account che utilizzi per creare l'organizzazione. Dall'account di gestione dell'organizzazione, puoi fare quanto segue:
Creare account nell'organizzazione
Invitare altri account esistenti nell'organizzazione
Rimuovere account dall'organizzazione
Gestire inviti
Applicare politiche a entità (root, OU o account) all'interno dell'organizzazione
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.
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).
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.
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.
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 i backup. L'unico modo per bypassare questo è compromettere anche l'account master che configura le SCP (l'account master non può essere bloccato).
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.
Esempi di SCP:
Negare completamente l'account root
Consentire solo regioni specifiche
Consentire solo servizi in whitelist
Negare a GuardDuty, CloudTrail e S3 Public Block Access di
essere disabilitati
Negare ai ruoli di sicurezza/risposta agli incidenti di essere eliminati o
modificati.
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
Amazon Resource Name è il nome unico che ogni risorsa all'interno di AWS ha, è composto in questo modo:
Nota che ci sono 4 partizioni in AWS ma solo 3 modi per chiamarle:
AWS Standard: aws
AWS China: aws-cn
AWS US public Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws
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.
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.
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.
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 si accede 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.
Dal punto di vista della sicurezza, è consigliato creare altri utenti ed evitare di utilizzare questo.
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.
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).
ID chiave di accesso: 20 caratteri alfanumerici casuali in maiuscolo come AKHDNAPO86BSHKDIRYT
ID chiave di accesso segreta: 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
Viene utilizzato per creare un fattore aggiuntivo per l'autenticazione oltre ai tuoi metodi esistenti, come la password, creando quindi un livello di autenticazione multi-fattore. Puoi utilizzare un applicazione virtuale gratuita o un dispositivo fisico. Puoi utilizzare app come Google Authenticator gratuitamente per attivare un MFA in AWS.
Le politiche con condizioni MFA possono essere collegate ai seguenti:
Un utente o gruppo IAM
Una risorsa come un bucket Amazon S3, una coda Amazon SQS o un argomento Amazon SNS
La politica di fiducia di un ruolo IAM che può essere assunto da un utente
Se desideri accedere tramite CLI a una risorsa che controlla per MFA, devi chiamare GetSessionToken. Questo ti darà un token con informazioni su MFA.
Nota che le credenziali di AssumeRole non contengono queste informazioni.
Come indicato qui, ci sono molti casi diversi in cui MFA non può essere utilizzato.
Un gruppo di utenti IAM è 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 di utenti in modo che tutti gli utenti nel gruppo di utenti ricevano i permessi 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 ai permessi, non all'autenticazione, e i principal sono entità IAM autenticate.
Ecco alcune caratteristiche importanti dei gruppi di 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.
Un ruolo IAM è molto simile a un utente, in quanto è un identità con politiche di permesso che determinano cosa può e non può fare in AWS. Tuttavia, un ruolo non ha alcuna credenziale (password o chiavi di accesso) associata. Invece di essere associato in modo univoco a una persona, un ruolo è destinato a essere assunto da chiunque ne abbia bisogno (e abbia abbastanza permessi). Un utente IAM può assumere un ruolo per temporaneamente acquisire permessi diversi per un compito specifico. Un ruolo può essere assegnato a un utente federato che accede utilizzando un provider di identità esterno invece di IAM.
Un ruolo IAM consiste in due tipi di politiche: una politica di fiducia, che non può essere vuota, che definisce chi può assumere il ruolo, e una politica di permessi, che non può essere vuota, che definisce cosa può accedere.
Il Servizio di Token di Sicurezza AWS (STS) è un servizio web che facilita l'emissione di credenziali temporanee e con privilegi limitati. È specificamente progettato per:
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.
Vengono utilizzati per assegnare permessi. Ci sono 2 tipi:
Politiche gestite da AWS (preconfigurate da AWS)
Politiche gestite dai clienti: configurate da te. Puoi creare politiche basate su politiche gestite da AWS (modificando una di esse e creando la tua), utilizzando il generatore di politiche (una vista GUI che ti aiuta a concedere e negare permessi) o scrivendo la tua.
Per default l'accesso è negato, l'accesso sarà concesso se è stato specificato un ruolo esplicito. Se esiste un singolo "Deny", sovrascriverà il "Allow", tranne per le richieste che utilizzano le credenziali di sicurezza root dell'account AWS (che sono consentite per default).
I campi globali che possono essere utilizzati per le condizioni in qualsiasi servizio sono documentati qui. I campi specifici che possono essere utilizzati per le condizioni per servizio sono documentati qui.
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.
Queste sono politiche che possono essere definite in risorse. Non tutte le risorse di AWS le supportano.
Se un principale non ha un diniego esplicito su di esse, e una politica di risorsa concede loro accesso, allora sono autorizzati.
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.
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.
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.
Nota che per impostazione predefinita AWS potrebbe aggiungere politiche di sessione alle sessioni che verranno generate a causa di motivi terzi. Ad esempio, in ruoli assunti da cognito non autenticati per impostazione predefinita (utilizzando l'autenticazione avanzata), AWS genererà credenziali di sessione con una politica di sessione che limita i servizi a cui la sessione può accedere alla seguente lista.
Pertanto, se a un certo punto ti trovi di fronte all'errore "... perché nessuna politica di sessione consente il ...", e il ruolo ha accesso per eseguire l'azione, è perché c'è una politica di sessione che lo impedisce.
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.
Tuttavia, di solito vorrai dare un ruolo diverso a seconda del gruppo dell'utente nella piattaforma di terze parti. Quindi, diversi ruoli IAM possono fidarsi del Provider di Identità di terze parti e la piattaforma di terze parti sarà quella che consentirà agli utenti di assumere un ruolo o l'altro.
AWS IAM Identity Center (successore di AWS Single Sign-On) espande le capacità di AWS Identity and Access Management (IAM) per fornire un luogo centrale che riunisce l'amministrazione degli utenti e il loro accesso agli account AWS e alle applicazioni cloud.
Il dominio di accesso sarà qualcosa come <user_input>.awsapps.com.
Per accedere agli utenti, ci sono 3 fonti di identità che possono essere utilizzate:
Directory del Centro Identità: Utenti AWS regolari
Active Directory: Supporta diversi connettori
Provider di Identità Esterno: Tutti gli utenti e i gruppi provengono da un Provider di Identità esterno (IdP)
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.
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.
È 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.
Un utente (fiducioso) può creare un Ruolo tra Account con alcune politiche e poi, consentire a un altro utente (fidato) di accedere al suo account ma solo avendo l'accesso indicato nelle nuove politiche del ruolo. Per creare questo, basta creare un nuovo Ruolo e selezionare Ruolo tra Account. I ruoli per Accesso tra Account offrono due opzioni. Fornire accesso tra gli account AWS che possiedi e fornire accesso tra un account che possiedi e un account AWS di terze parti. È consigliato specificare l'utente che è fidato e non mettere qualcosa di generico perché altrimenti, altri utenti autenticati come gli utenti federati potranno anche abusare di questa fiducia.
Non supportato:
Relazioni di Fiducia
Centro Amministrativo AD
Supporto completo per PS API
Cestino AD
Account di Servizio Gestiti da Gruppo
Estensioni di Schema
Nessun accesso diretto a OS o Istanza
L'app utilizza AssumeRoleWithWebIdentity per creare credenziali temporanee. Tuttavia, questo non concede accesso alla console AWS, solo accesso alle risorse all'interno di AWS.
Puoi impostare un'impostazione della politica delle 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 anche 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 con il minimo privilegio.
In questa pagina puoi trovare i prefissi ID IAM delle chiavi a seconda della loro natura:
ABIA | |
ACCA | Credenziale specifica per contesto |
AGPA | Gruppo utente |
AIDA | Utente IAM |
AIPA | Profilo istanza Amazon EC2 |
AKIA | Chiave di accesso |
ANPA | Politica gestita |
ANVA | Versione in una politica gestita |
APKA | Chiave pubblica |
AROA | Ruolo |
ASCA | Certificato |
ASIA | ID chiave di accesso temporanea (AWS STS) utilizza questo prefisso, ma è unico solo in combinazione con la chiave di accesso segreta e il token di sessione. |
I seguenti privilegi concedono vari accessi in lettura ai metadati:
arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
codebuild:ListProjects
config:Describe*
cloudformation:ListStacks
logs:DescribeMetricFilters
directconnect:DescribeConnections
dynamodb:ListTables
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 il aws cli, verrà utilizzato quello chiamato [default] in quel file.
Esempio di file delle credenziali con più di 1 profilo:
Se hai bisogno di accedere a diversi account AWS e il tuo profilo ha ricevuto accesso per assumere un ruolo all'interno di quegli account, non è necessario chiamare manualmente STS ogni volta (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) e configurare le credenziali.
Puoi utilizzare il file ~/.aws/config per indicare quali ruoli assumere, e poi usare il parametro --profile come al solito (l'assume-role verrà eseguito in modo trasparente per l'utente).
Un esempio di file di configurazione:
Con questo file di configurazione puoi quindi utilizzare aws cli come:
Se stai cercando qualcosa di simile a questo ma per il browser, puoi controllare l'estensione AWS Extend Switch Roles.
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
