Italian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Basic Information

Impara l'hacking di AWS da zero a eroe con htARTE (Esperto Red Team di HackTricks AWS)!

Altri modi per supportare HackTricks:

Gerarchia dell'Organizzazione

Account

In AWS c'è un account principale, che è il contenitore principale per tutti gli account della tua organizzazione. Tuttavia, non è necessario utilizzare quell'account per distribuire risorse, è possibile creare altri account per separare diversi AWS infrastrutture tra di loro.

Questo è molto interessante da un punto di vista di sicurezza, poiché un account non sarà in grado di accedere alle risorse di un altro account (tranne che siano creati ponti specifici), in questo modo è possibile 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.

  • Il account di gestione (l'account principale) è l'account che si utilizza per creare l'organizzazione. Dall'account di gestione dell'organizzazione, è possibile fare quanto segue:

  • Creare account nell'organizzazione

  • Invitare altri account esistenti all'organizzazione

  • Rimuovere account dall'organizzazione

  • Gestire inviti

  • Applicare policy alle entità (radici, OU o account) all'interno dell'organizzazione

  • Abilitare l'integrazione con i servizi AWS supportati per fornire funzionalità del servizio in tutti gli account dell'organizzazione.

  • È possibile accedere come utente principale utilizzando l'email e la password utilizzate per creare questo account principale/organizzazione.

L'account di gestione ha le responsabilità di un account pagante ed è responsabile del pagamento di tutti i costi che sono accumulati dagli account membri. Non è possibile modificare l'account di gestione di un'organizzazione.

  • Gli account membri costituiscono tutti gli altri account di un'organizzazione. Un account può essere membro di una sola organizzazione alla volta. È possibile allegare una policy a un account per applicare controlli solo a quel determinato 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 essere autorizzati ad accedervi).

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, è possibile creare policy per l'Unità Organizzativa che verranno applicate a tutti gli account figli. Si noti che un'OU può avere altre OU come figli.

# 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 policy di controllo del servizio (SCP) è una policy che specifica i servizi e le azioni che gli utenti e i ruoli possono utilizzare negli account che l'SCP influisce. Gli SCP sono simili alle policy di autorizzazioni IAM tranne che non concedono alcuna autorizzazione. Invece, gli SCP specificano le autorizzazioni massime per un'organizzazione, un'unità organizzativa (OU) o un account. Quando si attacca un SCP alla radice dell'organizzazione o a un'OU, l'SCP limita le autorizzazioni per le entità negli account membri.

Questo è l'UNICO modo in cui anche l'utente root può essere fermato dall'eseguire determinate azioni. Ad esempio, potrebbe essere utilizzato per impedire agli utenti di disabilitare CloudTrail o eliminare i backup. L'unico modo per aggirare ciò è compromettere anche l'account principale che configura gli SCP (l'account principale non può essere bloccato).

Nota che gli SCP limitano solo i principali nell'account, quindi gli altri account non sono interessati. Ciò significa che negare a un SCP s3:GetObject non impedirà alle persone di accedere a un bucket S3 pubblico nel tuo account.

Esempi di SCP:

  • Negare completamente l'account root

  • Consentire solo regioni specifiche

  • Consentire solo servizi autorizzati

  • Negare la disabilitazione di GuardDuty, CloudTrail e l'accesso pubblico a S3

  • Negare la cancellazione o modifica dei ruoli di sicurezza/incident response

  • Negare la cancellazione dei backup

  • Negare la creazione di utenti IAM e chiavi di accesso

Trova esempi in formato JSON su https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

ARN

Amazon Resource Name è il nome univoco che ogni risorsa all'interno di AWS ha, è composto come segue:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

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 - Identity and Access Management

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 la verifica di tale identità. Questo processo può essere suddiviso in: Identificazione e verifica.

  • Autorizzazione - Determina a cosa può accedere un'identità 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.

IAM può essere definito dalla sua capacità di gestire, controllare e governare meccanismi di autenticazione, autorizzazione e controllo degli accessi delle identità alle risorse all'interno del tuo account AWS.

Utente root dell'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 utilizzando l'indirizzo email e la password che hai usato per creare l'account.

Nota che un nuovo utente amministratore avrà meno permessi rispetto all'utente root.

Da un punto di vista della sicurezza, è consigliabile creare altri utenti e evitare di utilizzare questo.

Utenti IAM

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 è composto da un nome e credenziali (password e fino a due chiavi di accesso).

Quando crei un utente IAM, gli concedi autorizzazioni rendendolo un membro di un gruppo di utenti a cui sono associate le politiche di autorizzazione appropriate (raccomandato), o collegando direttamente le politiche all'utente.

Gli utenti possono avere MFA abilitato per l'accesso tramite la console. I token API degli utenti con MFA abilitato non sono protetti da MFA. Se desideri limitare l'accesso alle chiavi API di un utente utilizzando MFA è necessario indicare nella policy che per eseguire determinate azioni è necessaria la presenza di MFA (esempio qui).

CLI

  • ID chiave di accesso: 20 caratteri alfanumerici maiuscoli casuali come AKHDNAPO86BSHKDIRYT

  • ID chiave di accesso segreta: 40 caratteri casuali maiuscoli e minuscoli: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Non è possibile recuperare le ID chiave di accesso segrete perse).

Ogni volta che devi cambiare la chiave di accesso, questo è il processo che dovresti seguire: Creare una nuova chiave di accesso -> Applicare la nuova chiave al sistema/applicazione -> contrassegnare quella originale come inattiva -> Testare e verificare che la nuova chiave di accesso funzioni -> Eliminare la vecchia chiave di accesso

MFA - Autenticazione Multifattore

Viene utilizzata per creare un fattore aggiuntivo per l'autenticazione oltre ai tuoi metodi esistenti, come la password, creando quindi un livello di autenticazione multifattore. Puoi utilizzare un'applicazione virtuale gratuita o un dispositivo fisico. Puoi utilizzare app come autenticazione di Google gratuitamente per attivare un MFA in AWS.

Le policy con condizioni MFA possono essere collegate ai seguenti:

  • Un utente IAM o gruppo

  • Una risorsa come un bucket Amazon S3, una coda Amazon SQS o un topic Amazon SNS

  • La policy di trust di un ruolo IAM che può essere assunto da un utente

Se desideri accedere tramite CLI a una risorsa che verifica la presenza di MFA è necessario chiamare GetSessionToken. Questo ti fornirà un token con informazioni su MFA. Nota che le credenziali di AssumeRole non contengono queste informazioni.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

Come dichiarato qui, ci sono molti casi in cui MFA non può essere utilizzato.

Gruppi utenti IAM

Un gruppo utenti IAM è un modo per associare le policy a più utenti contemporaneamente, il che può rendere più semplice gestire le autorizzazioni per quegli utenti. Ruoli e gruppi non possono far parte di un gruppo.

È possibile associare una policy basata sull'identità a un gruppo utenti in modo che tutti gli utenti nel gruppo utenti ricevano le autorizzazioni della policy. Non è possibile identificare un gruppo utenti come un Principal in una policy (come una policy 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 utenti:

  • Un gruppo utenti può contenere molti utenti, e un utente può appartenere a più gruppi.

  • I gruppi utenti non possono essere nidificati; possono contenere solo utenti, non altri gruppi utenti.

  • Non esiste un gruppo utenti predefinito che includa automaticamente tutti gli utenti nell'account AWS. Se si desidera avere un gruppo utenti del genere, è necessario crearlo e assegnare a ciascun nuovo utente.

  • 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, consultare IAM and AWS STS quotas.

Ruoli IAM

Un ruolo IAM è molto simile a un utente, nel senso che è un'identità con policy di autorizzazione che determinano cosa può e non può fare in AWS. Tuttavia, un ruolo non ha credenziali (password o chiavi di accesso) associate. Invece di essere associato in modo univoco a una persona, un ruolo è destinato ad essere assumibile da chiunque ne abbia bisogno (e abbia abbastanza permessi). Un utente IAM può assumere un ruolo per assumere temporaneamente diverse autorizzazioni per un compito specifico. Un ruolo può essere assegnato a un utente federato che accede utilizzando un provider di identità esterno anziché IAM.

Un ruolo IAM è composto da due tipi di policy: Una policy di trust, che non può essere vuota, definisce chi può assumere il ruolo, e una policy di autorizzazioni, che non può essere vuota, definisce a cosa può accedere.

AWS Security Token Service (STS)

Il servizio AWS Security Token Service (STS) è un servizio web che facilita l'emissione di credenziali temporanee e a privilegi limitati. È specificamente progettato per:

Credenziali temporanee in IAM

Le credenziali temporanee sono utilizzate principalmente con i ruoli IAM, ma ci sono anche altri utilizzi. È possibile richiedere credenziali temporanee che hanno un insieme di autorizzazioni più restrittivo rispetto alle normali credenziali IAM dell'utente. Questo impedisce di eseguire accidentalmente attività non consentite dalle credenziali più restrittive. Un vantaggio delle credenziali temporanee è che scadono automaticamente dopo un periodo di tempo prestabilito. Si ha il controllo sulla durata per cui le credenziali sono valide.

Policy

Autorizzazioni della policy

Vengono utilizzate per assegnare autorizzazioni. Ci sono 2 tipi:

  • Policy gestite da AWS (preconfigurate da AWS)

  • Policy gestite dal cliente: Configurate da te. Puoi creare policy basate su policy gestite da AWS (modificandone una e creandone una tua), utilizzando il generatore di policy (una vista GUI che ti aiuta a concedere e negare autorizzazioni) o scrivendo la tua.

Per default l'accesso è negato, l'accesso sarà concesso se è stato specificato un ruolo esplicito. Se esiste un singolo "Deny", esso sovrascriverà l'"Allow", tranne per le richieste che utilizzano le credenziali di sicurezza radice dell'account AWS (che sono consentite per impostazione predefinita).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

I campi globali che possono essere utilizzati per condizioni in qualsiasi servizio sono documentati qui. I campi specifici che possono essere utilizzati per condizioni per servizio sono documentati qui.

Policy Inline

Questo tipo di policy è assegnato direttamente a un utente, gruppo o ruolo. Quindi, non compare nell'elenco delle Policy poiché può essere utilizzato da chiunque altro. Le policy inline sono utili se si desidera mantenere una rigorosa relazione uno a uno tra una policy e l'identità a cui è applicata. Ad esempio, si desidera essere sicuri che le autorizzazioni in una policy non vengano assegnate per errore a un'identità diversa da quella prevista. Quando si utilizza una policy inline, le autorizzazioni nella policy non possono essere erroneamente collegate all'identità sbagliata. Inoltre, quando si utilizza la Console di gestione AWS per eliminare quell'identità, le policy incorporate nell'identità vengono eliminate anche. Questo perché fanno parte dell'entità principale.

Policy del Bucket delle Risorse

Queste sono policy che possono essere definite nelle risorse. Non tutte le risorse di AWS le supportano.

Se un principale non ha un rifiuto esplicito su di esse e una policy delle risorse concede loro l'accesso, allora sono consentite.

Limiti IAM

I limiti IAM possono essere utilizzati per limitare le autorizzazioni a cui un utente o ruolo dovrebbe avere accesso. In questo modo, anche se un diverso insieme di autorizzazioni viene concesso all'utente da una diversa policy, l'operazione fallirà se prova a utilizzarle.

Un limite è semplicemente una policy allegata a un utente che indica il livello massimo di autorizzazioni che l'utente o il ruolo può avere. Quindi, anche se l'utente ha accesso di amministratore, se il limite indica che può solo leggere i bucket S3, quello è il massimo che può fare.

Questo, SCPs e seguire il principio del privilegio minimo sono i modi per controllare che gli utenti non abbiano più autorizzazioni di quelle di cui hanno bisogno.

Policy di Sessione

Una policy di sessione è una policy impostata quando un ruolo viene assunto in qualche modo. Questo sarà come un limite IAM per quella sessione: ciò significa che la policy di sessione non concede autorizzazioni ma le limita a quelle indicate nella policy (essendo le autorizzazioni massime quelle del ruolo).

Questo è utile per misure di sicurezza: quando un amministratore sta per assumere un ruolo molto privilegiato, potrebbe limitare le autorizzazioni solo a quelle indicate nella policy di sessione nel caso in cui la sessione venga compromessa.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

Nota che per impostazione predefinita AWS potrebbe aggiungere le policy di sessione alle sessioni che verranno generate a causa di terzi motivi. Ad esempio, in ruoli ipotetici di Cognito non autenticati per impostazione predefinita (utilizzando l'autenticazione avanzata), AWS genererà credenziali di sessione con una policy di sessione che limita i servizi ai quali la sessione può accedere alla seguente lista.

Pertanto, se in un certo momento ti trovi di fronte all'errore "... perché nessuna policy di sessione consente il...", e il ruolo ha accesso per eseguire l'azione, è perché c'è una policy di sessione che lo impedisce.

Federazione delle identità

La federazione delle identità consente agli utenti provenienti da provider di identità esterni ad AWS di accedere in modo sicuro alle risorse AWS senza dover fornire le credenziali utente AWS da un account utente IAM valido. Un esempio di provider di identità può essere il tuo Microsoft Active Directory aziendale (tramite SAML) o 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 conferirà fiducia all'altra piattaforma. Successivamente, almeno un ruolo IAM viene assegnato (con fiducia) al Provider di identità. Se un utente dalla piattaforma fidata accede ad AWS, lo farà come il ruolo menzionato.

Tuttavia, di solito si desidera assegnare 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 sarà la piattaforma di terze parti a consentire agli utenti di assumere uno o l'altro ruolo.

Centro delle identità IAM

Il Centro delle identità IAM di AWS (successore di AWS Single Sign-On) espande le capacità di Identity and Access Management (IAM) di AWS per fornire un punto 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 delle 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 delle identità, il Centro delle identità avrà un elenco di utenti e gruppi e sarà in grado di assegnare policy a essi per qualsiasi account dell'organizzazione.

Per concedere l'accesso a un utente/gruppo del Centro delle identità a un account, verrà creato un Provider di identità SAML che si fida del Centro delle identità, e verrà creato un ruolo che si fida del Provider di identità con le policy indicate nell'account di destinazione.

AwsSSOInlinePolicy

È possibile concedere autorizzazioni tramite policy inline ai ruoli creati tramite il Centro delle identità IAM. I ruoli creati negli account a cui vengono assegnate policy inline nel Centro delle identità IAM avranno queste autorizzazioni in una policy inline chiamata AwsSSOInlinePolicy.

Pertanto, anche se vedi 2 ruoli con una policy inline chiamata AwsSSOInlinePolicy, non significa che abbiano le stesse autorizzazioni.

Fiducie e ruoli tra account

Un utente (che si fida) può creare un Ruolo tra account con alcune policy e quindi, consentire a un altro utente (fidato) di accedere al suo account ma solo avendo l'accesso indicato nelle nuove policy del ruolo. Per creare questo, basta creare un nuovo Ruolo e selezionare Ruolo tra account. I Ruoli per l'accesso tra account offrono due opzioni. Fornire accesso tra account AWS di tua proprietà e fornire accesso tra un account di tua proprietà e un account AWS di terze parti. Si consiglia di specificare l'utente di fiducia e non inserire qualcosa di generico perché altrimenti, altri utenti autenticati come utenti federati saranno in grado di abusare di questa fiducia.

AWS Simple AD

Non supportato:

  • Relazioni di fiducia

  • Centro amministrativo AD

  • Supporto completo API PS

  • Cestino di riciclo AD

  • Account di servizio gestiti dal gruppo

  • Estensioni dello schema

  • Nessun accesso diretto al sistema operativo o alle istanze

Federazione Web o Autenticazione OpenID

L'applicazione utilizza l'AssumeRoleWithWebIdentity per creare credenziali temporanee. Tuttavia, ciò non concede l'accesso alla console AWS, ma solo l'accesso alle risorse all'interno di AWS.

Altre opzioni IAM

  • Puoi impostare una policy sulla password con opzioni come lunghezza minima e requisiti della password.

  • Puoi scaricare il "Report delle credenziali" con informazioni sulle credenziali attuali (come l'ora di creazione dell'utente, se la password è abilitata...). Puoi generare un report delle credenziali fino a una volta ogni quattro ore.

Identity and Access Management (IAM) di AWS fornisce un controllo degli accessi dettagliato su tutti i servizi AWS. Con IAM, puoi specificare chi può accedere a quali servizi e risorse, e in quali condizioni. Con le policy IAM, gestisci le autorizzazioni per la tua forza lavoro e i sistemi per garantire autorizzazioni a privilegi minimi.

Prefissi ID IAM

In questa pagina puoi trovare i prefissi ID IAM delle chiavi in base alla loro natura:

ABIA

Token di portatore del servizio AWS STS

ACCA

Credenziale specifica del contesto

AGPA

Gruppo utenti

AIDA

Utente IAM

AIPA

Profilo istanza Amazon EC2

AKIA

Chiave di accesso

ANPA

Policy gestita

ANVA

Versione in una policy gestita

APKA

Chiave pubblica

AROA

Ruolo

ASCA

Certificato

ASIA

ID chiavi temporanee (AWS STS) utilizza questo prefisso, ma è univoco solo in combinazione con la chiave di accesso segreta e il token di sessione.

Autorizzazioni consigliate per verificare gli account

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

Varie

Autenticazione CLI

Affinché un utente regolare possa autenticarsi ad AWS tramite CLI, è necessario disporre di credenziali locali. Per impostazione predefinita è possibile configurarle manualmente in ~/.aws/credentials o eseguendo aws configure. In quel file è possibile avere più di un profilo, se nessun profilo viene specificato utilizzando la cli aws, verrà utilizzato quello chiamato [default] in quel file. Esempio di file delle credenziali con più di 1 profilo:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

Se hai bisogno di accedere a diversi account AWS e il tuo profilo è stato autorizzato ad 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 quindi utilizzare il parametro --profile come al solito (l'assume-role verrà eseguito in modo trasparente per l'utente). Un esempio di file di configurazione:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Con questo file di configurazione è possibile utilizzare aws cli in questo modo:

aws --profile acc2 ...

Se stai cercando qualcosa simile a questo ma per il browser puoi controllare l'estensione AWS Extend Switch Roles.

Riferimenti

Impara l'hacking AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

PreviousAWS PentestingNextAWS - Federation Abuse

Last updated