Zranitelnost spočívá v opožděném odvolání

Problém pramení z toho, jak se změny přihlašovacích údajů šíří napříč distribuovanou infrastrukturou Googlu. Když je klíč smazán, není odvolání vynuceno současně na všech serverech, které ověřují API požadavky. Některé systémy odmítnou přihlašovací údaje rychle, zatímco jiné je mohou stále přijímat, dokud se k nim informace o smazání nedostane.

Aikido testoval toto chování opakovaným odesíláním autentizačních požadavků po smazání nově vytvořených klíčů. Během deseti pokusů úspěšná autentizace pokračovala, dokud se neprovedlo šíření informace o odvolání. Výsledkem bylo pozorované okno 8–23 minut s mediánem kolem 16 minut.

To znamená, že klíč, který se v rozhraní Google Cloud jeví jako smazaný, může na některých částech platformy stále krátce fungovat.

Proč tato prodleva představuje skutečné riziko

Pro organizace, které reagují na únik přihlašovacích údajů, je okamžité odvolání klíčové. Prodleva odhalená společností Aikido vytváří období, během kterého mohou útočníci klíč nadále používat, i když se obránci domnívají, že byl již deaktivován.

Pokud útočník v tomto okně disponuje kompromitovaným klíčem, může být stále schopen:

• Přístupu k povoleným API v rámci projektu
• Odesílání dalších API požadavků
• Generování neočekávaného využití cloudu nebo poplatků za fakturaci

Výzkumníci potvrdili toto chování u klíčů nakonfigurovaných pro Gemini a stejné opožděné odvolání pozorovali i u klíčů připojených k dalším Google Cloud API, jako jsou BigQuery a Google Maps. Zranitelnost je spojena s typem přihlašovacího údaje API klíče, nikoli s konkrétní službou.

Reakce Googlu na hlášení

Podle zpráv a informací od Aikido Google zpočátku toto chování považoval za očekávané propagační zpoždění v distribuovaném systému, nikoli za kritickou bezpečnostní chybu. Některé zprávy uvádějí, že problém byl zpočátku uzavřen jako „nebude opraveno“ („won’t fix“).

Po dalším přezkoumání byl problém znovu otevřen a interně překlasifikován na P0 bug, což označuje nejvyšší prioritu pro vyšetřování.

Základní technická příčina – postupně se šířící aktualizace o odvolání napříč infrastrukturou – znamená, že přesné načasování odvolání se může lišit v závislosti na tom, které backendové systémy požadavek zpracovávají.

Praktická opatření pro vývojáře a bezpečnostní týmy

Dokud nebude zaručeno okamžité odvolání, bezpečnostní týmy by měly předpokládat, že smazání API klíče neblokuje okamžitě všechen přístup.

Doporučená opatření zahrnují:

Považovat smazání za krok s opožděným účinkem
Počítejte s dočasným rizikovým oknem – zhruba do 30 minut – během kterého může kompromitovaný klíč stále fungovat.

Monitorovat logy a fakturaci po odvolání
Neočekávaná volání API nebo náhlé nárůsty využití krátce po smazání mohou indikovat pokračující zneužití během propagačního okna.

Omezit API klíče, kde je to možné
Google doporučuje používat omezení, jako jsou povolené referrery, IP adresy nebo konkrétní API, aby uniklý klíč měl omezenou použitelnost.

Rotovat a nahrazovat přihlašovací údaje
Místo spoléhání se pouze na smazání klíče pravidelně rotujte a co nejrychleji aktualizujte služby na nově vygenerované přihlašovací údaje.

Širší ponaučení pro cloudovou bezpečnost

Toto zjištění poukazuje na důležitou provozní realitu velkých distribuovaných systémů: konfigurační změny, včetně odvolání přihlašovacích údajů, se často šíří postupně, nikoli okamžitě.

Pro vývojáře a bezpečnostní týmy je ponaučení jasné – „smazáno“ neznamená vždy „okamžitě neaktivní.“ Bezpečnostní plány by měly počítat s krátkými propagačními zpožděními vždy, když jsou odvolávány citlivé přihlašovací údaje.

Zranitelnost spočívá v opožděném odvolání

Problém pramení z toho, jak se změny přihlašovacích údajů šíří napříč distribuovanou infrastrukturou Googlu. Když je klíč smazán, není odvolání vynuceno současně na všech serverech, které ověřují API požadavky. Některé systémy odmítnou přihlašovací údaje rychle, zatímco jiné je mohou stále přijímat, dokud se k nim informace o smazání nedostane.

Aikido testoval toto chování opakovaným odesíláním autentizačních požadavků po smazání nově vytvořených klíčů. Během deseti pokusů úspěšná autentizace pokračovala, dokud se neprovedlo šíření informace o odvolání. Výsledkem bylo pozorované okno 8–23 minut s mediánem kolem 16 minut.

To znamená, že klíč, který se v rozhraní Google Cloud jeví jako smazaný, může na některých částech platformy stále krátce fungovat.

Proč tato prodleva představuje skutečné riziko

Pro organizace, které reagují na únik přihlašovacích údajů, je okamžité odvolání klíčové. Prodleva odhalená společností Aikido vytváří období, během kterého mohou útočníci klíč nadále používat, i když se obránci domnívají, že byl již deaktivován.

Pokud útočník v tomto okně disponuje kompromitovaným klíčem, může být stále schopen:

• Přístupu k povoleným API v rámci projektu
• Odesílání dalších API požadavků
• Generování neočekávaného využití cloudu nebo poplatků za fakturaci

Výzkumníci potvrdili toto chování u klíčů nakonfigurovaných pro Gemini a stejné opožděné odvolání pozorovali i u klíčů připojených k dalším Google Cloud API, jako jsou BigQuery a Google Maps. Zranitelnost je spojena s typem přihlašovacího údaje API klíče, nikoli s konkrétní službou.

Reakce Googlu na hlášení

Podle zpráv a informací od Aikido Google zpočátku toto chování považoval za očekávané propagační zpoždění v distribuovaném systému, nikoli za kritickou bezpečnostní chybu. Některé zprávy uvádějí, že problém byl zpočátku uzavřen jako „nebude opraveno“ („won’t fix“).

Po dalším přezkoumání byl problém znovu otevřen a interně překlasifikován na P0 bug, což označuje nejvyšší prioritu pro vyšetřování.

Základní technická příčina – postupně se šířící aktualizace o odvolání napříč infrastrukturou – znamená, že přesné načasování odvolání se může lišit v závislosti na tom, které backendové systémy požadavek zpracovávají.

Praktická opatření pro vývojáře a bezpečnostní týmy

Dokud nebude zaručeno okamžité odvolání, bezpečnostní týmy by měly předpokládat, že smazání API klíče neblokuje okamžitě všechen přístup.

Doporučená opatření zahrnují:

Považovat smazání za krok s opožděným účinkem
Počítejte s dočasným rizikovým oknem – zhruba do 30 minut – během kterého může kompromitovaný klíč stále fungovat.

Monitorovat logy a fakturaci po odvolání
Neočekávaná volání API nebo náhlé nárůsty využití krátce po smazání mohou indikovat pokračující zneužití během propagačního okna.

Omezit API klíče, kde je to možné
Google doporučuje používat omezení, jako jsou povolené referrery, IP adresy nebo konkrétní API, aby uniklý klíč měl omezenou použitelnost.

Rotovat a nahrazovat přihlašovací údaje
Místo spoléhání se pouze na smazání klíče pravidelně rotujte a co nejrychleji aktualizujte služby na nově vygenerované přihlašovací údaje.

Širší ponaučení pro cloudovou bezpečnost

Toto zjištění poukazuje na důležitou provozní realitu velkých distribuovaných systémů: konfigurační změny, včetně odvolání přihlašovacích údajů, se často šíří postupně, nikoli okamžitě.

Pro vývojáře a bezpečnostní týmy je ponaučení jasné – „smazáno“ neznamená vždy „okamžitě neaktivní.“ Bezpečnostní plány by měly počítat s krátkými propagačními zpožděními vždy, když jsou odvolávány citlivé přihlašovací údaje.