Configurazioni errate dell'IAM

Nel cloud, l'identità è il nuovo perimetro. IAM (Identity and Access Management) stabilisce chi può fare che cosa. Una falla in IAM consente a un attaccante di passare da un punto d'appoggio con privilegi ridotti al controllo completo dell'account.

• Utenti, ruoli e account di servizio sono identità
• I criteri definiscono le autorizzazioni
• I criteri configurati in modo errato rappresentano il principale rischio cloud

La maggior parte delle escalation dei privilegi nel cloud è un problema di IAM.

AWS IAM presenta tre elementi fondamentali che è necessario comprendere:

• Utenti — identità di lunga durata con chiavi di accesso
• Ruoli — identità temporanee che possono essere assunte da utenti o servizi
• Criteri — documenti JSON che concedono o negano azioni sulle risorse

Un criterio associato in modo troppo ampio è all'origine dell'assegnazione di permessi eccessivi.

Lo schema IAM più pericoloso in assoluto è il criterio con caratteri jolly. Concede qualsiasi azione su qualsiasi risorsa.

Se un attaccante compromette un'identità con questo criterio, ottiene il controllo dell'intero account.

Una volta ottenuta una credenziale, è necessario elencare le operazioni che consente di eseguire. IAM dispone di API di lettura che rivelano i criteri associati.

Alcuni account concedono persino iam:Get* e iam:List* agli utenti ordinari, fornendo una mappa già pronta.

Un'escalation classica: un utente dispone di iam:PassRole e di un'autorizzazione per creare servizi. Può avviare una risorsa che assume un ruolo con privilegi elevati ed ereditarne l'accesso.

• L'utente dispone di ec2:RunInstances + iam:PassRole
• Avvia un'istanza EC2 con associato un ruolo amministrativo
• L'istanza dispone ora di credenziali amministrative, che l'utente recupera

L'utente non disponeva direttamente dei privilegi amministrativi, ma è riuscito a effettuare l'escalation.

Singole autorizzazioni possono essere innocue, ma in combinazione possono diventare percorsi di escalation. Tra le combinazioni note a rischio figurano:

• iam:CreatePolicyVersion — riscrivere un criterio esistente per concedere privilegi amministrativi
• iam:AttachUserPolicy — associare AdministratorAccess a se stessi
• iam:CreateAccessKey su un altro utente — sottrarne l'identità
• sts:AssumeRole su un ruolo che accorda fiducia in modo eccessivo

Gli strumenti le enumerano automaticamente.

I ruoli dispongono di un criterio di trust che definisce chi può assumerli. Un criterio di trust troppo ampio è una backdoor.

Se, per errore, un ruolo accorda fiducia all'intero account o persino a un account esterno, un attaccante può assumerlo.

Controllare manualmente ogni combinazione di criteri è tedioso. Gli strumenti mappano i percorsi di escalation al posto vostro.

• Pacu — framework di sfruttamento AWS con moduli di escalation dei privilegi
• PMapper — rappresenta graficamente le relazioni IAM e individua i collegamenti che consentono l'escalation
• enumerate-iam — forza bruta sulle chiamate API che una chiave può effettuare

Le autorizzazioni possono essere concesse in due modi, ed è necessario verificarli entrambi:

• Criteri gestiti — riutilizzabili e associati a più identità
• Criteri inline — incorporati direttamente in un singolo utente o ruolo

I criteri inline sono facili da ignorare durante gli audit, quindi spesso nascondono autorizzazioni eccessive. Durante la valutazione di un'identità, enumerare sempre entrambi i tipi.

La soluzione alle configurazioni errate di IAM è il minimo privilegio: concedere solo le autorizzazioni esatte necessarie.

• Sostituire i caratteri jolly con azioni esplicite e ARN di risorse
• Utilizzare ruoli con credenziali a breve durata invece di chiavi di lunga durata
• Verificare le autorizzazioni inutilizzate con Access Analyzer
• Imporre l'MFA sulle identità con privilegi elevati

Il report dovrebbe associare ogni finding a una correzione basata sul minimo privilegio.

I test di escalation dei privilegi modificano attivamente lo stato dell'account. È necessario prestare attenzione:

• La creazione di criteri, chiavi o ruoli è intrusiva: ottenere un'approvazione scritta
• Documentare ogni modifica in modo che possa essere annullata
• Preferire l'enumerazione in sola lettura per dimostrare un percorso prima di sfruttarlo

Spesso è sufficiente dimostrare che un percorso di escalation dei privilegi esiste; non è sempre necessario sfruttarlo completamente.

Quale combinazione di autorizzazioni costituisce un percorso classico di escalation dei privilegi in AWS?

Ha imparato perché IAM è il vero perimetro del cloud e come gli attaccanti lo sfruttano.

• I criteri con caratteri jolly Action:* Resource:* sono catastrofici
• iam:PassRole + creazione di servizi consente l'escalation dei privilegi
• I criteri di trust troppo ampi consentono agli attaccanti di assumere ruoli
• Strumenti come Pacu e PMapper automatizzano l'individuazione dei percorsi
• La correzione consiste sempre nell'applicare il minimo privilegio

Ora analizzeremo S3 e l'esposizione dello storage.