Resumo: Quando se elimina uma chave da API do Google, é indicado que a eliminação é imediata. Os nossos testes revelam que o processo demora cerca de 23 minutos. Durante esse período, um invasor que tenha obtido uma chave que vazou mantém acesso aos seus dados e às APIs ativadas (incluindo o Gemini). Não há forma de revogar a chave mais rapidamente nem de confirmar quando esta deixa de funcionar. O Google arquivou a nossa denúncia com a indicação «não será corrigido».
Quando se elimina uma chave API, espera-se que o acesso termine imediatamente.
As chaves API do Google não funcionam assim. A revogação propaga-se gradualmente pela infraestrutura do Google. Alguns servidores rejeitam a chave em poucos segundos, enquanto outros continuam a aceitá-la durante 23 minutos.
Um invasor que possua a sua chave eliminada pode continuar a enviar pedidos até que um deles chegue a um servidor que ainda não tenha sido atualizado. Se o Gemini estiver ativado no projeto, ele pode descarregar os ficheiros que carregou e extrair conversas armazenadas em cache.
A consola do GCP não mostra a chave e não indica se esta ainda está a funcionar. Está a confiar que a infraestrutura do Google acabará por se atualizar.
A autenticação não deve ser apenas consistente a longo prazo
Muitos dos serviços Cloud Google Cloud são, por definição, consistentemente diferidos. Neste modelo, as atualizações propagam-se gradualmente pelos servidores, em vez de de uma só vez. Esta escolha permite ao Google expandir-se globalmente e manter a rapidez e, na maioria dos serviços, o atraso é impercetível. No entanto, no que diz respeito à autenticação, essa escolha é mais difícil de justificar.
Os atrasos na revogação de credenciais são vulneráveis a ataques. Há alguns meses, Eduard Agavriloae revelou um atraso de 4 segundos que permitia que chaves de acesso da AWS eliminadas criassem novas credenciais. Quatro segundos foram suficientes para causar problemas na AWS.
Tendo em conta a atenção que tem sido dada recentemente às chaves API do Google utilizadas para aceder ao Gemini, decidimos avaliar durante quanto tempo permanece aberto o período de revogação das chaves API do Google.
O que é um período de revogação?
O período de revogação é o intervalo de tempo entre o momento em que se elimina uma chave e a última autenticação bem-sucedida.
Se esse intervalo for de alguns microssegundos, o comportamento corresponde ao que os utilizadores esperam. Se for mais longo, cada segundo adicional dá aos atacantes mais tempo para utilizar indevidamente uma chave roubada.
Determinar o período de revogação
Para avaliar o prazo de revogação das chaves API do Google, realizámos 10 testes ao longo de dois dias.
Em cada teste, criámos uma chave API, eliminámo-la e enviámos 3 a 5 pedidos autenticados por segundo até não obtermos nenhuma resposta válida durante vários minutos.
Escolhemos essa taxa porque não controlamos a forma como o Google encaminha os nossos pedidos para os diferentes servidores de autenticação espalhados pelo mundo. O objetivo era distribuir o volume pelo maior número possível desses servidores em cada teste, respeitando sempre a infraestrutura do Google. Não podemos afirmar se uma taxa de pedidos mais elevada prolongaria o intervalo observado. Um atacante não tem motivos para limitar o tráfego da forma como o fizemos, pelo que vale a pena referir que os nossos números podem não representar o pior cenário possível.
Para garantir a exaustividade, também verificámos aleatoriamente o nosso trabalho algumas semanas mais tarde, para nos certificarmos de que o comportamento observado não se devia a problemas de rede pontuais.
23 minutos
Em dez testes, o intervalo mais longo foi de quase 23 minutos! É um período de tempo incrivelmente longo durante o qual uma chave eliminada ainda consegue autenticar-se com sucesso.
O intervalo mais curto foi de quase 8 minutos, e a mediana situou-se em cerca de 16 minutos. Ao longo dos ensaios, a taxa de sucesso revelou-se altamente imprevisível: um minuto após a eliminação, num ensaio 79 % dos pedidos foram bem-sucedidos, enquanto noutro apenas 5 %.
Um invasor que possua uma chave roubada não observa um corte abrupto nem um declínio previsível. O acesso continua a funcionar, de forma irregular, até que, por fim, simplesmente cessa.
Rastrear um único teste na consola do GCP
Para ilustrar a inconsistência na infraestrutura do Google, monitorizámos um dos nossos testes utilizando o gráfico «Tráfego por credencial» no GCP. A linha inferior (azul) mostra as autenticações bem-sucedidas e reflete a duração do período de revogação.
Não esperávamos ver mais nenhum dado, mas apareceu uma segunda linha. A linha superior (verde) representa os pedidos rejeitados e está identificada como apikey:DESCONHECIDO. Tínhamos (erradamente) assumido que os pedidos inválidos seriam simplesmente descartados sem qualquer atribuição a um projeto. Em vez disso, o GCP inclui-os neste gráfico.
Para compreender melhor o misterioso apikey:DESCONHECIDO valor, tentámos autenticar-nos com uma chave API eliminada há alguns dias. Surpreendentemente, essas solicitações apareceram no mesmo gráfico, agrupadas na mesma apikey:DESCONHECIDO grupo.
A nossa melhor suposição é que o Google mantém a atribuição do projeto mesmo após a eliminação da chave, para o caso de os utilizadores decidirem restaurar a credencial.
Para as equipas de resposta a incidentes que investigam uma fuga de credenciais, o apikey:DESCONHECIDO Este valor pode ser confuso. Qualquer pedido efetuado com uma chave da API do Google eliminada é agrupado na mesma categoria «UNKNOWN», o que torna difícil distinguir quais os pedidos que se relacionam com uma credencial específica. Um pedido nessa categoria pode significar que um agente malicioso continua a tentar autenticar-se com a chave eliminada, ou pode tratar-se de um serviço legítimo a funcionar com uma chave desatualizada e sem relação com o caso.
Se estiver dentro do período de 23 minutos para revogação, verifique se existem autenticações válidas que utilizem a chave que foi divulgada. Se estiver fora desse período, o risco parece ser extremamente baixo.
Diferenças regionais em termos de consistência
Realizámos a primeira experiência a partir de um endereço IP residencial na Costa Leste dos EUA. A nossa hipótese era que a realização de uma experiência semelhante em máquinas virtuais (VM) em diferentes regiões do GCP poderia revelar inconsistências adicionais.
Criámos uma máquina virtual em três regiões: us-east1, Europa Ocidental 1, e sudeste-asiático1. Em seguida, realizámos 5 testes. Em cada um deles, eliminámos uma única chave API e enviámos pedidos a partir de cada uma das três máquinas virtuais em paralelo.
Dois aspetos chamaram a atenção. Em primeiro lugar, imediatamente após a eliminação de uma chave, as máquinas virtuais em diferentes regiões registaram taxas de sucesso na autenticação muito diferentes. A tabela abaixo apresenta a percentagem de pedidos válidos no primeiro minuto, por região.
Veja a tentativa 1: us-east1 82%, Europa Ocidental 1 60%, sudeste-asiático1 32%. As máquinas virtuais mais distantes dos EUA detetaram a eliminação mais rapidamente, o que é o oposto do que seria de esperar. Não podemos determinar com exatidão a razão para tal a partir do exterior. O encaminhamento de pedidos do Google é mais complexo do que a simples equação «região da máquina virtual = região do servidor», e uma máquina virtual em Singapura não comunica necessariamente com servidores em Singapura. No entanto, o padrão manteve-se consistente ao longo dos ensaios, o que sugere que a diferença se deve a algum fator relacionado com a infraestrutura regional, o armazenamento em cache ou a afinidade de encaminhamento.
Em segundo lugar, a diferença entre as regiões não se limitou apenas aos primeiros minutos. Ao longo de todo o período, sudeste-asiático1 apresentou uma taxa média de sucesso na autenticação de pedidos de 22%, enquanto us-east1 e Europa Ocidental 1 ambos ficaram na casa dos 49%. A Ásia manteve-se em baixa minuto a minuto, e não apenas no início.
Seja qual for a causa destas diferenças, a localização do servidor influencia claramente o comportamento de uma chave após a sua eliminação.
Outras credenciais do Google
Em todos os nossos testes, utilizámos chaves com acesso ao Gemini, mas observámos o mesmo comportamento com chaves limitadas a outras APIs do GCP, como o BigQuery e o Maps. O atraso é uma característica do tipo de credencial, e não das APIs ativadas no projeto.
Para completar, testámos outros dois tipos de credenciais do Google:
- Novas chaves API Gemini (prefixo AQ.). A eliminação foi propagada em cerca de 1 minuto.
- Chaves da conta de serviço do Google. A eliminação foi propagada em cerca de 5 segundos.
Ambos funcionam à escala do Google e ambos são revogados muito mais rapidamente do que os 23 minutos que medimos para as chaves da API do Google.
Divulgação ao Google
Comunicámos esta situação à Google. A Google arquivou a notificação com a indicação «não será corrigido». A posição da equipa, tal como a entendemos, é que o atraso de propagação é uma característica conhecida do sistema e não constitui um problema de segurança.
Embora o Google indique publicamente que a sua API IAM é «eventualmente consistente», não documenta especificamente este comportamento no que diz respeito às chaves de API do Google.
[Legenda: Captura de ecrã da página de documentação da API IAM do Google.]
Expectativas dos utilizadores não correspondidas
Os sistemas distribuídos à escala do Google são complexos, e isto não constitui uma crítica à equipa de IAM do GCP. No entanto, um intervalo de revogação de 23 minutos está em total contradição com o que os utilizadores esperam de um botão de eliminação. A discrepância entre essa expectativa e o comportamento do Google põe em evidência quatro problemas:
1. A interface do utilizador é extremamente enganadora.
Quando se elimina a chave, o Google retira-a da sua vista e informa que «uma vez eliminada, já não pode ser utilizada para efetuar pedidos à API». Essa afirmação é manifestamente falsa. O utilizador não tem como saber se a chave ainda está ativa, não tem como acelerar a revogação e não tem como confirmar quando esta deixou de funcionar por completo.
2. A Google implementou um processo de revogação mais rápido para outros tipos de credenciais.
As revogações de credenciais de contas de serviço são propagadas em cerca de 5 segundos. O formato mais recente de chaves API do Gemini é propagado em cerca de um minuto. Ambos funcionam à escala do Google. Ambos sugerem que isto também é tecnicamente viável para as chaves API do Google.
3. Janelas de consistência longas não são compatíveis com a autenticação.
Quando se elimina uma credencial, espera-se que esta deixe de existir. Mesmo um atraso de apenas alguns segundos é significativo, como demonstrou a investigação sobre a AWS realizada por Eduard no ano passado.
4. Os longos períodos de revogação prejudicam a emissão de credenciais Just-in-Time.
Um prestador de serviços que pretenda gerar chaves da API do Google de forma dinâmica tem de prever um intervalo de 23 minutos após a revogação antes de se ter a garantia de que a chave está inutilizada. Isso é incompatível com o modo como JIT funcionar.
Trabalhar à volta da janela
Até que o Google implemente um sistema de revogação mais rápido, a responsabilidade de colmatar esta lacuna recai sobre os utilizadores. Há duas coisas que podem ajudar.
1. Considere a eliminação de uma chave como uma operação que demora 30 minutos, e não como algo instantâneo.
Se estiver a lidar com uma chave de API do Google que tenha sido divulgada, considere que a chave permanecerá ativa durante 30 minutos após clicar em «Apagar». Isso proporciona uma margem de segurança adicional em relação ao máximo de 23 minutos que observámos. Planeie o resto da sua resposta ao incidente tendo em conta esse intervalo de tempo.
2. Acompanhe a utilização durante o período em questão.
Na secção «APIs e serviços ativados» da consola do GCP, analise os pedidos de API por credencial. Se detetar uma utilização inesperada dessa credencial após a sua eliminação, é possível que alguém a esteja a explorar ativamente.
Janelas de consistência eventual de grande duração são uma escolha de design inadequada para a revogação de credenciais. Até que a Google altere isso, considere cada eliminação de chave como uma operação com duração de 30 minutos e esteja atento à janela para evitar abusos.
