AWS - Informazioni di Base

Tip

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) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Gerarchia dell’Organizzazione

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 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.

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 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. Nota 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 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 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

Nota che le SCP limitano solo i principi nell’account, quindi altri account non sono influenzati. Ciò 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

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 un RCP alla radice dell’organizzazione, a un’unità organizzativa (OU) o a un account, l’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 l’RCP configurato 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 un 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 risorse è 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

ARN

Amazon Resource Name è il nome unico che ogni risorsa all’interno di AWS ha, è composto in questo modo:

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 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.

AWS account root user

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.

Dal punto di vista della sicurezza, è consigliato creare altri utenti ed evitare di utilizzare questo.

IAM users

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 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).

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 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 -> 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

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.

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

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

Gruppi utenti IAM

Un gruppo 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 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 IAM e AWS STS quote.

Ruoli IAM

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.

Servizio di Token di Sicurezza AWS (STS)

Il Servizio di Token di Sicurezza AWS (STS) è un servizio web che facilita l’emissione di credenziali temporanee con privilegi limitati. È specificamente progettato per:

Credenziali temporanee in IAM

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

Permessi delle Politiche

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 le tue.

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).

{
"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.

Politiche Inline

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

Queste sono politiche che possono essere definite nelle 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.

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 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.

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).

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.

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 politiche di sessione alle sessioni che verranno generate per 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.

Federazione dell’Identità

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.

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.

Centro IdentitĂ  IAM

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 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.

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.

Fiducia e Ruoli tra Account

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.

AWS Simple AD

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

Federazione Web o Autenticazione OpenID

L’app utilizza AssumeRoleWithWebIdentity per creare credenziali temporanee. Tuttavia, questo non concede accesso alla console AWS, solo accesso alle risorse all’interno di AWS.

Altre opzioni IAM

  • 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.

Prefissi ID IAM

In questa pagina puoi trovare i prefissi ID IAM delle chiavi a seconda della loro natura:

Codice IdentificatoreDescrizione
ABIAToken bearer del servizio AWS STS

| 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 chiavi di accesso temporanee (AWS STS) 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

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 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:

[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 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:

[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 puoi quindi utilizzare aws cli come:

aws --profile acc2 ...

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

Automazione delle credenziali temporanee

Se stai sfruttando un’applicazione che genera credenziali temporanee, può essere noioso aggiornarle nel tuo terminale ogni pochi minuti quando scadono. Questo può essere risolto utilizzando una direttiva credential_process nel file di configurazione. Ad esempio, se hai qualche webapp vulnerabile, potresti fare:

[victim]
credential_process = curl -d 'PAYLOAD' https://some-site.com

Nota che le credenziali devono essere restituite a STDOUT nel seguente formato:

{
"Version": 1,
"AccessKeyId": "an AWS access key",
"SecretAccessKey": "your AWS secret access key",
"SessionToken": "the AWS session token for temporary credentials",
"Expiration": "ISO8601 timestamp when the credentials expire"
}

Riferimenti

Tip

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) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks