E se gli utenti IAM potessero generare liberamente chiavi API AWS senza restrizioni? E se gli amministratori della sicurezza non avessero visibilità sulla creazione delle chiavi API e non potessero controllare chi le usa?
Sebbene questo scenario non si applichi ad AWS, è una cruda realtà per le chiavi HMAC di Google Cloud . Questo blog illustra tre vulnerabilità emerse dal modo in cui Google Cloud gestisce le chiavi HMAC associate agli utenti.
1. Vulnerabilità n. 1 - Registrazione insufficiente
2. Vulnerabilità n. 2 - Credenziali a lungo termine non gestibili
3. Vulnerabilità n. 3 - Credenziali a lungo termine non verificabili
TLDR;
- Le chiavi HMAC hanno uno scopo pratico. Possono essere utilizzate per creare intestazioni firmate Sigv4 utilizzate per l'autenticazione contro l'API XML di Cloud Storage. per un massimo di 7 giorni dopo la creazione iniziale.
- I registri di audit di Google Cloud non registrano gli eventi di creazione o eliminazione della chiave HMAC quando sono associati agli account utente.
- Gli amministratori non hanno a disposizione alcuna API di Google Cloud , il che impedisce loro di verificare l'esistenza delle chiavi HMAC associate agli account utente.
- Non sono disponibili autorizzazioni Cloud IAM per limitare la creazione, l'eliminazione o l'uso delle chiavi HMAC.
- Questo problema è stato segnalato tramite il Vulnerability Reward Program di Google, che ha chiuso il problema senza fornire una soluzione, sostenendo che il comportamento segnalato funziona come previsto.
Utilizzo delle chiavi HMAC
Le API per la creazione e l'eliminazione delle chiavi HMAC associate agli account utente non sono accessibili dall'esterno. Queste azioni possono essere eseguite solo attraverso il servizio API privato della console cloud (cloudconsole-pa), accessibile dalla scheda Interoperabilità della console di archiviazione. Gli URL identificati di seguito rappresentano gli endpoint all'interno della console cloud utilizzati per la creazione e l'eliminazione delle chiavi HMAC associate agli utenti, se accompagnati da un cookie di accesso valido.
- Una richiesta POST a `/v3/entityServices/StorageEntityService/entities/STORAGE_USER_HMAC/CREATE` crea una chiave HMAC utilizzata nel processo di firma Sigv4.
- Una richiesta POST a `/v3/entityServices/StorageEntityService/entities/STORAGE_USER_HMAC/DELETE` elimina un HMAC associato a un utente.
Gli utenti di Google Cloud sono in grado di creare una quantità apparentemente infinita di risorse di questo tipo: "type.googleapis.com/google.internal.cloud.console.clientapi.storage.UserHmac"
Durante i test non è stato identificato alcun limite massimo di chiavi HMAC e non sono stati riscontrati limiti di valutazione.
Vulnerabilità n. 1 - Registrazione insufficiente
I registri di audit Cloud non catturano le azioni mediate attraverso il servizio API privato della console cloud (cloudconsole-pa). Di conseguenza, non vi è alcuna registrazione della creazione o dell'eliminazione di chiavi HMAC legate agli account utente. Questa assenza di registri ostacola la capacità dei difensori di avvisare o monitorare la creazione di chiavi HMAC per gli account utente, con un rischio di persistenza, o la loro eliminazione, con un rischio di negazione del servizio.
Vulnerabilità n. 2 - Credenziali a lungo termine non gestibili
Gli utenti con accesso a Google Cloud possono creare chiavi HMAC, richiedendo almeno l'autorizzazione resource manager.projects.get. Tuttavia, non esistono autorizzazioni Cloud IAM per gestire le chiavi HMAC per sé o per altri utenti, impedendo agli amministratori di controllarne la creazione. Di conseguenza, questo avviso non fornisce raccomandazioni per mitigare il rischio di esposizione delle chiavi HMAC limitando l'assegnazione dei permessi.
Vulnerabilità n. 3 - Credenziali a lungo termine non verificabili
Gli amministratori Cloud si trovano ad affrontare problemi di gestione delle chiavi HMAC all'interno delle loro organizzazioni, non avendo visibilità su quali account utente hanno generato queste chiavi e se vengono utilizzate attivamente per accedere agli oggetti di storage. Inoltre, manca la funzionalità per revocare le chiavi associate ad altri utenti, limitando la capacità di applicare efficacemente i criteri di sicurezza.
I team di risposta agli incidenti si affidano a Cloud Logging per monitorare l'accesso agli oggetti di Cloud Storage, ma non dispongono di indicatori specifici per determinare se le chiavi HMAC vengono utilizzate in questi tentativi di accesso. Mentre varie azioni di contenimento, come la sospensione o l'eliminazione degli account utente compromessi, possono inizialmente sembrare efficaci rifiutando le intestazioni firmate Sigv4 create in precedenza, la riattivazione o la ricreazione dello stesso utente consente il riutilizzo delle credenziali a meno che non siano scadute.
Inoltre, la rimozione dei ruoli Cloud IAM può revocare l'accesso alle risorse di storage interessate. Tuttavia, è importante notare che la riassegnazione dei ruoli non invalida le intestazioni firmate Sigv4 create in precedenza, consentendo loro di continuare a funzionare anche dopo il cambio di ruolo.
Caso di abuso della chiave HMAC
Un utente malintenzionato in possesso di un account utente Google con accesso a un progetto Google Cloud e, in minima parte, con l'autorizzazione `resource manager.projects.get` è in grado di generare chiavi HMAC nella scheda interoperabilità della console di archiviazione.
Un percorso di attacco che sfrutta le chiavi HMAC può svolgersi come segue:
1. Un aggressore compromette un account utente di Google
2. Genera una chiave HMAC per l'utente.
3. Utilizza la chiave HMAC per generare una serie di intestazioni firmate Sigv4 con scadenza di 7 giorni.
4. Esfiltra i dati da Google Cloud Storage fino alla scadenza della firma dell'intestazione.
5. L'identificazione dell'accesso e/o della risposta dello storage dannoso è ostacolata dalle vulnerabilità #1, #2 e #3 sopra descritte.
6. I tentativi di contenimento possono essere inefficaci, come la modifica della password dell'utente compromesso, o temporanei, se l'utente colpito viene sospeso ma riattivato successivamente.
Prova di concetto
Nell'SDK di Google Cloud non è esposta la funzionalità per convertire una chiave HMAC associata all'utente in credenziali utilizzabili attraverso il processo di firma Sigv4. Per questo motivo, abbiamo fornito un semplice script helper in python per farlo. Esso riceve l'id della chiave di accesso, il segreto, l'oggetto e il nome del bucket e restituisce una richiesta curl con un'intestazione di autorizzazione firmata, che verrà utilizzata per recuperare l'oggetto GCS desiderato tramite l'API XML.
Il proof of concept è fortemente influenzato da un articolo di Rosy Parmar sull'uso di HMAC per l'autenticazione a Google Cloud.
Raccomandazioni
Alla luce dei numerosi abusi associati alle chiavi HMAC specifiche per l'utente, vengono qui presentate una serie di raccomandazioni che migliorano la gestione, la registrazione e il ciclo di vita delle chiavi HMAC GCP.
1. Permessi e API
- Introdurre API e autorizzazioni associate che conferiscano agli amministratori l'autorità di creare ed eliminare chiavi HMAC specifiche per l'utente, come necessario.
- Creare API e autorizzazioni associate che consentano agli amministratori di Google Workspace di verificare le chiavi HMAC di tutti gli utenti della propria organizzazione, il loro utilizzo e la possibilità di eliminare le chiavi per altri.
2. Vincoli di politica organizzativa
- Creare un vincolo di criterio Org che consenta agli amministratori dei criteri di impedire la creazione di chiavi HMAC associate all'utente.
3. Registrazione
- Scrivere su Admin L'attività di admin registra la creazione e l'eliminazione di tutte le chiavi HMAC, comprese quelle associate agli utenti.
- Indicare nei registri Cloud quando si accede all'API XML di Cloud Storage utilizzando una credenziale di intestazione Sigv4.
4. Gestione delle credenziali
- Limitare il numero di chiavi HMAC che ogni utente può creare a un massimo di due.
- Introdurre una data di scadenza configurata dall'utente per le chiavi HMAC.
- Visualizzare le chiavi HMAC agli utenti solo una volta, al momento della loro creazione, e non lasciare segreti all'interfaccia utente nelle richieste successive.
Timeline di divulgazione
2/07/24 [Kat Traxler]: Segnalato al Vulnerability Reward Program di Google con il titolo "Le chiavi HMAC generate per gli utenti presentano rischi per la sicurezza, in particolare a causa dell'assenza di eventi di registrazione alla loro creazione o cancellazione".
2/07/24 [Google]: Conferma la ricezione del rapporto
2/08/24 [Google]: Ha indicato che stavano chiudendo il problema a causa della mancanza di dettagli. Richiesto uno scenario di attacco e una prova di concetto.
02/09/24 [Kat Traxler]: Risponde con una descrizione più dettagliata delle azioni dell'attaccante date le caratteristiche delle chiavi HMAC e promette di scrivere un PoC.
2/12/24 [Google]: Stato modificato in "Assegnato, riaperto, gestito".
16/02/24 [Google]: Il team di Google Bug Hunter ha riassunto i dettagli della vulnerabilità segnalata, ha richiesto un esempio di intestazione firmata Sigv4 e ha chiesto se le credenziali possono essere utilizzate per accedere a qualcosa di diverso dall'API XML di Google Cloud Storage.
18/02/24 [Kat Traxler]: Ha risposto alla serie di domande e ha confermato che le credenziali generate dalle chiavi HMAC possono essere utilizzate solo per accedere all'API XML di Google Cloud Storage.
19/02/24 [Kat Traxler]: Fornito al team di Google Bug Hunter un link al PoC ospitato su Github che consente di generare le proprie intestazioni firmate con chiavi HMAC.
2/28/24 [Google]: Il problema è stato "identificato come rischio di abuso e assegnato al nostro team Fiducia e sicurezza".
2/28/24 [Google]: Ha risposto ringraziando per la segnalazione e indicando che il team stava analizzando l'invio.
04/01/24 [Kat Traxler]: "Faccio seguito a questo rapporto. Sono passate circa 4 settimane dall'ultima volta che abbiamo parlato. Come promemoria, ho intenzione di divulgare questo problema intorno alla prima settimana di giugno. Vorrei utilizzare il tempo a nostra disposizione per coordinarci con il team di assistenza e implementare i controlli IAM e i log mancanti. Senza nuovi eventi registrati e nuovi controlli IAM, la divulgazione conterrà solo dettagli sul meccanismo di persistenza senza alcuna guida per i clienti su come prevenirlo o rilevarlo. A nessuno piace questo tipo di blog di divulgazione. *Per favore, fatemi sapere come posso aiutarvi a risolvere questo problema o a coordinarvi con le parti responsabili".
4/02/24 [Google]: "🎉 Bella scoperta! Ho segnalato un bug al team di prodotto responsabile in base alla tua segnalazione. Lavoreremo con il team di prodotto per assicurarci che il problema venga risolto. Ti faremo sapere quando il problema sarà risolto".
4/11/24 [Google]: "La commissione del Google Vulnerability Reward Program ha deciso che l'impatto sulla sicurezza di questo problema non soddisfa i requisiti per una ricompensa finanziaria".
6/04/24 [Google]: "I nostri sistemi mostrano che il bug che abbiamo creato sulla base della sua segnalazione è stato chiuso senza fornire una correzione. Questo può essere accaduto per vari motivi: l'impatto del rischio potrebbe essere troppo piccolo per giustificare una correzione, potrebbero esserci altri fattori di attenuazione, o semplicemente il prodotto non è più mantenuto. Lo stato esatto è INTENDED_BEHAVIOR. Questa decisione è stata presa dai team di prodotto competenti e non influisce sull'importo della ricompensa VRP o sulla posizione in classifica. Non possiamo fornire ulteriori dettagli in questa notifica automatica, ma saremo lieti di rispondere alle vostre domande su questa decisione".