I ricercatori di sicurezza informatica hanno scoperto diverse falle critiche nei servizi offerti da Amazon Web Services (AWS) che, se sfruttate con successo, potrebbero comportare conseguenze gravi.
Quali sono i problemi riscontrati in Amazon Web Services (AWS)
“L’impatto di queste vulnerabilità varia dall’esecuzione di codice da remoto (RCE), al completo controllo dell’account utente (che potrebbe fornire un accesso amministrativo potente), alla manipolazione dei moduli di intelligenza artificiale, all’esposizione di dati sensibili, all’esfiltrazione di dati e al denial-of-service“, ha dichiarato la società di sicurezza cloud Aqua in un rapporto dettagliato.
Dopo una segnalazione responsabile a febbraio 2024, Amazon ha affrontato le carenze nel corso di diversi mesi, da marzo a giugno e i risultati sono stati presentati al Black Hat USA 2024.
Al centro del problema, soprannominato Bucket Monopoly, vi è un vettore di attacco chiamato Shadow Resource, che in questo caso si riferisce alla creazione automatica di un bucket Amazon Web Services S3 quando si utilizzano servizi come CloudFormation, Glue, EMR, SageMaker, ServiceCatalog e CodeStar.
Il nome del bucket S3 creato in questo modo è unico e segue una convenzione di denominazione predefinita (ad esempio, “cf-templates-{Hash}-{Region}”); un attaccante potrebbe sfruttare questo comportamento per configurare bucket in regioni Amazon Web Services non utilizzate e attendere che un cliente di questo servizio legittimo utilizzi uno dei servizi vulnerabili per ottenere un accesso nascosto ai contenuti del bucket S3.
Basandosi sulle autorizzazioni concesse al bucket S3 controllato dall’avversario, questo approccio potrebbe essere utilizzato per innescare una condizione di DoS, eseguire codice, manipolare o rubare dati e persino ottenere il pieno controllo dell’account della vittima senza che l’utente ne sia consapevole.
I problemi che Bucket Monoply causa sui servizi Amazon
Per massimizzare le probabilità di successo, utilizzando Bucket Monopoly, gli attaccanti possono creare in anticipo bucket non reclamati in tutte le regioni disponibili e memorizzare codice dannoso nel bucket e quando l’organizzazione bersaglio abilita per la prima volta uno dei servizi vulnerabili in una nuova regione, il codice dannoso verrà eseguito inconsapevolmente, con la potenziale creazione di un utente amministratore che può concedere il controllo agli attaccanti.
Tuttavia, è importante considerare che l’attaccante dovrà attendere che la vittima distribuisca un nuovo stack CloudFormation in una nuova regione per la prima volta per lanciare con successo l’attacco. La modifica del file template di CloudFormation nel bucket S3 per creare un utente amministratore canaglia dipende anche dal fatto che l’account della vittima abbia o meno i permessi per gestire i ruoli IAM.
Aqua ha dichiarato di aver trovato altri cinque servizi AWS che si basano su una metodologia di denominazione simile per i bucket S3 – {Service Prefix}-{AWS Account ID}-{Region} – esponendoli così agli attacchi Shadow Resource e consentendo in ultima analisi a un criminale informatico malintenzionato di eseguire azioni dannose, tra cui DoS, divulgazione di informazioni, manipolazione dei dati ed esecuzione arbitraria di codice:
- AWS Glue: aws-glue-assets-{Account-ID}-{Region}
- AWS Elastic MapReduce (EMR): aws-emr-studio-{Account-ID}-{Region}
- AWS SageMaker: sagemaker-{Region}-{Account-ID}
- AWS CodeStar: aws-codestar-{Region}-{Account-ID}
- AWS Service Catalog: cf-templates-{Hash}-{Region}
Le dichiarazioni di Amazon
L’azienda ha anche osservato che gli ID degli account AWS dovrebbero essere considerati riservati, contrariamente a quanto affermato da Amazon nella sua documentazione, poiché potrebbero essere utilizzati per orchestrare attacchi simili.
Inoltre, gli hash utilizzati per gli account AWS possono essere scoperti utilizzando ricerche con espressioni regolari su GitHub o Sourcegraph, o, alternativamente, esaminando le issue aperte, rendendo così possibile ricostruire il nome del bucket S3 anche in assenza di un metodo per calcolare l’hash direttamente dall’ID dell’account o da altri metadati relativi all’account.
“Questo vettore di attacco colpisce non solo i servizi AWS, ma anche molti progetti open-source utilizzati dalle organizzazioni per distribuire risorse nei loro ambienti AWS“, ha affermato Aqua. “Molti progetti open-source creano automaticamente bucket S3 come parte della loro funzionalità o istruiscono i loro utenti a distribuire bucket S3.“
“Invece di utilizzare identificatori prevedibili o statici nel nome del bucket, è consigliabile generare un hash univoco o un identificatore casuale per ogni regione e account, incorporando questo valore nel nome del bucket S3. Questo approccio aiuta a proteggersi dagli attacchi in cui i bucket vengono rivendicati prematuramente dagli attaccanti.”