Chiavi API Google: dopo la cancellazione restano attive fino a 23 minuti

Il ritardo nella revoca: come funziona la vulnerabilità

Il problema deriva dal modo in cui le modifiche alle credenziali si propagano nell'infrastruttura distribuita di Google. Quando una chiave viene cancellata, la revoca non viene applicata simultaneamente su tutti i server che gestiscono l'autenticazione delle API. Alcuni sistemi rifiutano la credenziale rapidamente, mentre altri possono continuare ad accettarla fino a quando l'aggiornamento non li raggiunge.

Aikido ha testato il comportamento inviando ripetutamente richieste di autenticazione dopo aver cancellato chiavi appena create. In dieci prove, l'autenticazione ha continuato a funzionare fino al completamento della propagazione della revoca, producendo la finestra osservata di 8-23 minuti con una mediana di circa 16 minuti.

Questo significa che una chiave che appare cancellata nell'interfaccia di Google Cloud potrebbe ancora funzionare brevemente su parti della piattaforma.

Perché questo ritardo crea un rischio reale

Per le organizzazioni che rispondono a una credenziale compromessa, la revoca immediata è fondamentale. Il ritardo scoperto da Aikido crea un periodo in cui gli attaccanti possono continuare a utilizzare la chiave anche dopo che i difensori credono di averla disabilitata.

Se un attaccante possiede una chiave compromessa durante quella finestra, potrebbe essere in grado di:

• Accedere alle API abilitate collegate al progetto
• Inviare ulteriori richieste API
• Generare costi imprevisti per l'utilizzo del cloud o la fatturazione

I ricercatori hanno confermato il comportamento con chiavi configurate per Gemini, e hanno osservato lo stesso ritardo nella revoca per chiavi collegate ad altre API di Google Cloud come BigQuery e Google Maps. La vulnerabilità è legata al tipo di credenziale della chiave API stessa, non a un servizio specifico.

La risposta di Google al rapporto

Secondo i resoconti e la divulgazione di Aikido, Google ha inizialmente trattato il comportamento come un previsto ritardo di propagazione in un sistema distribuito, piuttosto che come una falla di sicurezza critica. Alcuni rapporti indicano che il problema è stato inizialmente chiuso come "non risolvibile" ("won't fix").

Dopo un'ulteriore revisione, il rapporto è stato successivamente riaperto e classificato internamente come bug P0, indicando la massima priorità per le indagini.

La causa tecnica di base — gli aggiornamenti di revoca che si propagano gradualmente attraverso l'infrastruttura — significa che i tempi precisi di revoca possono variare a seconda di quali sistemi backend elaborano una richiesta.

Precauzioni pratiche per sviluppatori e team di sicurezza

Fino a quando il comportamento di revoca non sarà garantito come immediato, i team di sicurezza dovrebbero presumere che la cancellazione di una chiave API non blocchi istantaneamente tutto l'accesso.

Le precauzioni raccomandate includono:

Considerare la cancellazione come un passaggio di contenimento ritardato
Prevedere una finestra di rischio temporanea — all'incirca fino a 30 minuti — durante la quale una chiave compromessa potrebbe ancora funzionare.

Monitorare log e fatturazione dopo la revoca
Chiamate API impreviste o picchi improvvisi di utilizzo subito dopo la cancellazione potrebbero indicare un abuso continuato durante la finestra di propagazione.

Limitare le chiavi API il più possibile
Google raccomanda di applicare restrizioni come referrer consentiti, indirizzi IP o API specifiche, in modo che una chiave compromessa abbia un'utilità limitata.

Ruotare e sostituire le credenziali
Invece di fare affidamento esclusivamente sulla cancellazione, ruota le chiavi e aggiorna i servizi per utilizzare le credenziali appena generate il più rapidamente possibile.

La lezione più ampia per la sicurezza del cloud

La scoperta evidenzia un'importante realtà operativa dei grandi sistemi distribuiti: le modifiche alla configurazione, inclusa la revoca delle credenziali, spesso si propagano gradualmente piuttosto che istantaneamente.

Per sviluppatori e team di sicurezza, il messaggio è semplice: "cancellato" non significa sempre "reso inattivo immediatamente." I playbook difensivi dovrebbero tenere conto di brevi ritardi di propagazione ogni volta che vengono revocate credenziali sensibili.