Cosa succederebbe se gli utenti IAM potessero generare liberamente chiavi API AWS senza restrizioni? Cosa succederebbe se gli amministratori della sicurezza non avessero visibilità sulla creazione delle chiavi API e non potessero controllare chi le utilizza?
Sebbene questo scenario non si applichi ad AWS, è una dura realtà per le chiavi Cloud di Google Cloud . Questo blog descrive tre vulnerabilità emerse dal modo in cui Google Cloud le chiavi HMAC associate agli utenti.
1. Vulnerabilità n. 1 - Registrazione insufficiente
2. Vulnerabilità n. 2 - Credenziali a lungo termine ingestibili
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 tramite l'API XMLCloud . per un massimo di 7 giorni dopo la creazione iniziale.
- I registri Cloud di Google Cloud non registrano gli eventi di creazione o eliminazione delle chiavi HMAC quando sono associati agli account utente.
- Gli amministratori non hanno a disposizione Cloud Google Cloud , il che impedisce loro di verificare l'esistenza delle chiavi HMAC associate agli account utente.
- Non sono disponibili autorizzazioni Cloud per limitare la creazione, l'eliminazione o l'utilizzo delle chiavi HMAC.
- Il problema è stato segnalato tramite il Vulnerability Reward Program di Google, che ha chiuso la segnalazione 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 tramite il servizio API privato cloud (cloudconsole-pa), accessibile dalla scheda Interoperabilità della console di archiviazione. Gli URL identificati di seguito rappresentano gli endpoint all'interno della 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.
Cloud Google Cloud possono creare una quantità apparentemente infinita di risorse del tipo: "type.googleapis.com/google.internal.cloud.console.clientapi.storage.UserHmac".
Durante i test non è stato individuato alcun limite massimo per le chiavi HMAC e non sono state riscontrate limitazioni di valutazione.
Vulnerabilità n. 1 - Registrazione insufficiente
I registri Cloud non acquisiscono le azioni mediate tramite il servizio API privato cloud (cloudconsole-pa). Di conseguenza, non viene registrata la creazione o l'eliminazione di chiavi HMAC collegate agli account utente. Questa assenza di registri ostacola la capacità dei difensori di segnalare o monitorare la creazione di chiavi HMAC per gli account utente, comportando un rischio di persistenza, o la loro eliminazione, presentando un rischio di denial of service.
Vulnerabilità n. 2 - Credenziali a lungo termine ingestibili
Gli utenti con Cloud Google Cloud possono creare chiavi HMAC, per cui è necessaria almeno l'autorizzazione resource manager.projects.get. Tuttavia, non esistono autorizzazioni Cloud per gestire le chiavi HMAC per sé stessi o per altri utenti, il che impedisce agli amministratori di controllarne la creazione. Di conseguenza, la presente nota informativa non fornisce raccomandazioni per mitigare il rischio di esposizione delle chiavi HMAC attraverso la limitazione dell'assegnazione delle autorizzazioni.
Vulnerabilità n. 3 - Credenziali a lungo termine non verificabili
Cloud devono affrontare sfide nella gestione delle chiavi HMAC all'interno delle loro organizzazioni, poiché non hanno visibilità su quali account utente abbiano generato tali chiavi e se queste vengano utilizzate attivamente per accedere agli oggetti di archiviazione. Inoltre, mancano funzionalità per revocare le chiavi associate ad altri utenti, limitando la loro capacità di applicare efficacemente le politiche di sicurezza.
I team di risposta agli incidenti si affidano a Cloud per monitorare l'accesso agli oggetti Cloud , ma non dispongono di indicatori specifici per determinare se le chiavi HMAC vengono utilizzate in questi tentativi di accesso. Sebbene varie azioni di contenimento, come la sospensione o l'eliminazione degli account utente compromessi, possano 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 può revocare l'accesso alle risorse di archiviazione 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 la modifica del ruolo.
Caso di abuso della chiave HMAC
Un malintenzionato in possesso di un account utente Google con accesso a un Cloud Google Cloud e almeno 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 hacker compromette un account utente 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. Esporta i dati da Google Cloud fino alla scadenza della firma dell'intestazione.
5. L'identificazione dell'accesso e/o della risposta dannosi alla memoria è ostacolata dalle vulnerabilità n. 1, n. 2 e n. 3 sopra descritte.
6. I tentativi di contenimento possono essere inefficaci, come la modifica della password dell'utente compromesso, o temporanei, se un utente interessato viene sospeso ma successivamente riattivato.
Prova di concetto
La funzionalità non è disponibile nel Google Cloud per convertire una chiave HMAC associata all'utente in credenziali utilizzabili tramite il processo di firma Sigv4. Pertanto, abbiamo fornito un semplice script di supporto Python per eseguire proprio questa operazione. Il programma accetta un ID chiave di accesso, un segreto, un oggetto e un nome 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.
La prova di concetto è fortemente influenzata da un articolo di Rosy Parmar sull'uso di HMAC per l'autenticazione su Google Cloud.
Raccomandazioni
Alla luce dei numerosi abusi associati alle chiavi HMAC specifiche dell'utente, di seguito vengono presentate una serie di raccomandazioni che migliorano la gestione, la registrazione e il ciclo di vita delle chiavi HMAC GCP.
1. Autorizzazioni e API
- Introdurre API e autorizzazioni associate che consentano agli amministratori di creare ed eliminare chiavi HMAC specifiche per utente in base alle necessità.
- Crea API e autorizzazioni associate che consentono agli amministratori di Google Workspace di controllare le chiavi HMAC di tutti gli utenti della loro organizzazione, il loro utilizzo e la possibilità di eliminare le chiavi per altri utenti.
2. Vincoli delle politiche aziendali
- Creare un vincolo di politica aziendale che consenta agli amministratori delle politiche di impedire la creazione di chiavi HMAC associate agli utenti.
3. Registrazione
- Scrivi all'amministratore L'attività di amministrazione registra la creazione e l'eliminazione di tutte le chiavi HMAC, comprese quelle associate agli utenti.
- Indicare nei Cloud quando si accede all'API XML Cloud utilizzando una credenziale dell'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.
- Mostra le chiavi HMAC agli utenti solo una volta, al momento della loro creazione, e non rivelare i segreti all'interfaccia utente nelle richieste successive.
Cronologia delle divulgazioni
2/07/24 [Kat Traxler]: Segnalato al Vulnerability Reward Program di Google con il titolo "Le chiavi HMAC generate per gli utenti comportano rischi per la sicurezza, in particolare a causa dell'assenza di eventi di registrazione al momento della loro creazione o cancellazione".
2/07/24 [Google]: Conferma di ricezione della segnalazione
2/08/24 [Google]: Ha indicato che avrebbe chiuso la questione per mancanza di dettagli. Ha richiesto uno scenario di attacco e una prova di concetto.
02/09/24 [Kat Traxler]: Ha risposto con una descrizione più dettagliata delle azioni dell'autore dell'attacco, tenendo conto delle caratteristiche delle chiavi HMAC, e con la promessa di scrivere un PoC.
2/12/24 [Google]: Stato modificato in "Assegnato, riaperto, valutato".
16/02/24 [Google]: Il team Bug Hunter di Google 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 oltre all'API XML di Google Cloud
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 .
19/02/24 [Kat Traxler]: Fornito al team Google Bug Hunter un link al PoC ospitato su Github che consente loro di generare le proprie intestazioni firmate con chiavi HMAC.
28/02/24 [Google]: Il problema èstato "identificato come rischio di abuso e segnalato al nostro team Trust & Safety".
28/02/24 [Google]: Ha risposto ringraziando per la segnalazione e indicando che il team stava analizzando la richiesta.
04/01/24 [Kat Traxler]: "Seguito di questa segnalazione. Sono passate circa 4 settimane dall'ultima volta che abbiamo parlato. Vi ricordo che ho intenzione di rendere pubblica questa questione intorno alla prima settimana di giugno. Vorrei utilizzare il tempo a nostra disposizione per coordinarmi con il team di assistenza al fine di implementare i controlli di registrazione e IAM mancanti. Senza la registrazione di nuovi eventi e nuovi controlli IAM, la divulgazione conterrà solo i dettagli del meccanismo di persistenza senza alcuna indicazione per i clienti su come prevenirlo o rilevarlo. A nessuno piace questo tipo di blog di divulgazione. *Vi prego di farmi sapere come posso contribuire a risolvere la questione o coordinarmi con le parti responsabili".
4/02/24 [Google]: “🎉 Ottima segnalazione! Ho segnalato il bug al team di prodotto responsabile sulla base della tua segnalazione. Collaboreremo con il team di prodotto per garantire che il problema venga risolto. Ti faremo sapere quando il problema sarà stato risolto.”
4/11/24 [Google]: "Il comitato del programma di ricompensa per la segnalazione di vulnerabilità di Google 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 indicano che il bug che abbiamo creato sulla base della tua segnalazione è stato chiuso senza fornire una correzione. Ciò può essere dovuto a vari motivi: l'impatto del rischio potrebbe essere troppo limitato per giustificare una correzione, potrebbero esserci altri fattori attenuanti o semplicemente il prodotto non è più sottoposto a manutenzione. Lo stato esatto è INTENDED_BEHAVIOR. Questa decisione è stata presa dai team di prodotto competenti e non influisce sull'importo del tuo premio VRP o sulla tua posizione nella classifica. Non possiamo fornire ulteriori dettagli in questa notifica automatica, ma saremo lieti di rispondere alle tue domande relative a questa decisione."