Un pericoloso scambio di identità

Amazon Web Services è il cloud di Amazon, una delle principali piattaforme cloud disponibili. La quantità di servizi che offre è enorme, praticamente qualsiasi cosa si possa immaginare nel mondo del cloud computing, e sono solitamente indicati con delle sigle. S3, per esempio, è un semplice storage cloud. EC2 offre macchine virtuali. Mentre EKS (Elastic Kubernetes Service) è l’implementazione in chiave Amazon di Kubernetes. Naturalmente, nella logica di Amazon, tutti i vari servizi sono interconnessi, in particolare per quanto riguarda l’autenticazione. Su Kubernetes è, infatti, presente un meccanismo di autenticazione basato su utenti e ruoli, per cui a ogni utente vengono assegnati dei token identificativi e una serie di autorizzazioni per l’accesso a specifiche risorse. Questo permette di definire con estrema precisione quali attività possano essere svolte da ciascun utente, rendendo l’ambiente molto sicuro, perché non è necessario dare a qualcuno più permessi di quanti ne servono. L’aspetto interessante è che già da prima che esistesse Kubernetes, il sistema di autenticazione di Amazon, AWS IAM, funzionava con la stessa logica.

DOVE RISIEDE LA VULNERABILITÀ

Per evitare di dover ripetere tutto due volte, cosa piuttosto complicata in aziende con centinaia o migliaia di dipendenti, Amazon ha deciso di integrare il proprio IAM con la sua implementazione di Kubernetes, così è possibile utilizzare le utenze AWS preesistenti, magari già in uso per accedere a servizi come S3 o CloudFront, per accedere anche alle risorse allocate sul cluster Kubernetes. È quindi stato pubblicato il modulo AWS IAM authenticator for Kubernetes, che permette l’utilizzo del sistema di autenticazione di Amazon per accedere alle risorse di un cluster Kubernetes (uno qualsiasi, in realtà, non necessariamente EKS). Kubernetes è infatti open source, quindi chiunque può realizzarsi un cluster sul proprio hardware, e Amazon ha rilasciato come open source anche la propria implementazione, col nome di “EKS Anywhere”. E chiunque può decidere di utilizzare come autenticatore il servizio IAM di Amazon, su qualsiasi cluster Kubernetes. Semplicemente, Kubernetes continua a gestire i suoi ruoli e permessi come al solito, ma per l’autenticazione di un accesso non si fa il classico scambio di chiave direttamente in Kubernetes: l’utente si autentica su Amazon e riceve un token di autorizzazione temporaneo, che viene poi utilizzato nelle varie chiamate alle KubeAPI per collegare l’attività all’utente. Il modulo  aws-iam-authenticator si occupa proprio di mettere in relazione i ruoli nativi di Kubernetes con l’autenticazione di Amazon. Ed è in questa “traduzione” che è stato trovata una vulnerabilità, a meno di un anno dalla pubblicazione di EKS Anywhere.

Figura 1 – Il problema è che il nome utente viene cercato come lowercase, quindi è possibile che due nomi, che differiscono solo per le maiuscole, vengano confusi. [Fonte]

UN DIZIONARIO PER LA TRADUZIONE

La procedura di autenticazione percorre sostanzialmente sei passi:

1. L’utente invia una richiesta alle API di EKS, per ottenere delle risorse Kubernetes (per esempio, “kubectl get pods”). La richiesta include un token di autorizzazione nell’intestazione, che è una stringa base64 di AWS Security Token Service.
2. Il server riceve la richiesta, estrae il token, e lo invia nel corpo della richiesta verso il server di AWS IAM.
3. Il server di autenticazione di AWS IAM riceve il token dal server API, lo decodifica e lo verifica. Se è corretto, il server IAM invia la richiesta di autenticazione firmata ad AWS STS.
4. AWS STS riceve la richiesta e contolla la firma. Se la firma è valida, poi invia i dettagli dell’identità IAM dell’utente come risposta alla chiamata GetCallerIdentityResponse (chiamata che IAM fa a STS).
5. L’autenticatore IAM riceve la risposta della propria chiamata GetCallerIdentityResponse da STS e traduce l’identità IAM collegata a quel token in un serviceaccount di Kubernetes, basandosi sulle regole scritte nella ConfigMap aws-auth. L’identità Kubernetes che viene riconosciuta grazie a questa ConfigMap deve ovviamente essere presente nel cluster, e avere delle regole RBAC che le permettano l’accesso a delle risorse. AWS IAM passa l’identità Kubernetes corrispondente alla propria alle API di EKS.
6. Il server delle API riceve l’identità, controlla i permessi tramite RBAC, e verifica se la richiesta (“get pods”, nell’esempio) è autorizzata per questo serviceaccount. In caso positivo, esegue la richiesta e restituisce il risultato direttamente al chiamante.

Uno dei punti deboli è che è possibile modificare la ConfigMap, come si farebbe con una qualsiasi altra ConfigMap:

kubectl edit configmaps aws-auth -n kube-system

Se si aggiungesse un elemento di questo tipo alla sezione mapUsers:

mapUsers: |
– userarn: arn:aws:iam::000000000000:user/testuser
username: user:

Sarebbe possibile assegnare una access key IAM arbitraria (per esempio la propria) all’utente testuser. Naturalmente, per poterlo fare bisogna prima di tutto avere l’accesso alla ConfigMap in questione, ma è possibile che un utente possa accedere al namespace kube-system senza però avere altri privilegi. Con questo meccanismo, potrebbe modificare la ConfigMap e assegnarsi un serviceaccount Kubernetes che ha maggiori privilegi, andando quindi a impersonare un altro ruolo. Ci si potrebbe chiedere: ma, se viene mappato un utente già presente nella ConfigMap, non dovrebbe generare un errore? La realtà è che questo non accade a causa di questo bug nella lettura della ConfigMap da parte del sistema di verifica dei token:

queryParamsLower.Set(strings.ToLower(key), values[0])

Come si può vedere, la chiave (l’utente) viene trasformata in minuscolo. È quindi possibile modificare la ConfigMap per sostituire l’utente “amministratore” con un piccolo trucco: basta aggiungere la propria access key per l’utente “Amministratore”. Siccome le due stringhe sono diverse, non ci sarà una sovrascrittura e nessun errore nell’inserimento. Poi, quando AWS cercherà di confrontare le varie access key, selezionerà questa stringa ma trasformandola in minuscolo, quindi dando l’accesso al service account “amministratore”.

LA SOLUZIONE

Amazon ha risolto il problema semplicemente aggiungendo al codice una funzione che faccia un vero controllo dei duplicati, per assicurarsi che nessuno aggiunga una seconda volta l’access key per un utente già esistente. Il nuovo codice è stato caricato su tutte le istanze EKS gestite da Amazon, e per quelle installate dagli utenti sul proprio hardware basta fare un aggiornamento di EKS Anywhere. A ogni modo, il bug era presente fin dal 2020, e non sappiamo se sia stato sfruttato da qualcuno prima che venisse scoperto e corretto, quindi conviene assicurarsi che i permessi degli utenti nel proprio cluster EKS siano rimasti come previsto. In particolare, all’amministratore basta controllare la ConfigMap aws-auth nel namespace kube-system, per assicurarsi che non ci siano “duplicati” (pur con differenze tra maiuscole e minuscole) dei nomi degli account.

Figura 2 – Il problema è stato risolto con una nuova funzione che controlla la presenza di eventuali utenti duplicati  a prescindere da maiuscole e minuscole, e segnala l’errore. [Fonte]