Credenciais incorporadas por recomendação do Google agora autenticam no Gemini após ativação da IA, expondo dados e riscos de cobranças milionárias em 22 aplicativos com 500 milhões de usuários
Chaves de API embutidas em 22 aplicativos Android com um total de mais de 500 milhões de usuários estão proporcionando acesso não autorizado ao Gemini, a inteligência artificial desenvolvida pelo Google.
Pesquisadores da CloudSEK descobriram que credenciais públicas, incorporadas nas aplicações por recomendação do Google, passaram a autenticar nos serviços de IA após a ativação do Gemini, tudo sem aviso prévio e sem que os desenvolvedores precisassem fazer qualquer ajuste.
Qualquer indivíduo capaz de descompilar um APK, o arquivo de instalação do Android, pode extrair essas chaves. Essas chaves podem ser utilizadas para acessar dados armazenados na plataforma ou gerar cobranças de milhares de dólares por dia na conta do desenvolvedor.
Por que a chave API ficava exposta de propósito
Uma chave de API funciona como um identificador entre um aplicativo e um serviço externo. Por exemplo, quando um aplicativo de mapas precisa carregar uma rota, ele envia essa chave para o servidor do Google junto com a solicitação.
O problema surge devido à natureza dos arquivos de aplicativos Android. Os pacotes APK, que são baixados das lojas e instalados nos dispositivos, podem ser descompilados com ferramentas gratuitas digitalmente disponíveis. Basicamente, qualquer um pode reverter um aplicativo à sua estrutura de código original.
O problema tem origem na própria documentação oficial do Google, que orientava desenvolvedores a incorporar as chaves diretamente no código dos aplicativos. Com as chaves de API sendo consideradas públicas, estar visível nesses arquivos não era visto como um risco. No pior cenário, alguém poderia apenas ver qual projeto Google estava por trás de determinado aplicativo. Essa lógica deixou de ser válida em 2024.
Como o Gemini transformou chaves inofensivas em credenciais sensíveis
Quando o Google ativou a API do Gemini no Google Cloud, as chaves de projeto existentes passaram a autenticar automaticamente nos novos endpoints de inteligência artificial.
Uma chave criada em 2019 para exibir mapas agora pode dar acesso a modelos de linguagem, arquivos hospedados na plataforma de IA e serviços de inferência que geram custos. Isso aconteceu sem que o desenvolvedor tivesse sido notificado ou precisasse modificar qualquer configuração.
A firma de segurança Truffle Security foi a primeira a registrar essa situação em larga escala, em fevereiro. Ao analisar milhões de sites, encontrou quase 3.000 chaves do Google que passaram a autenticar no Gemini, apesar de nunca terem sido criadas para esse fim.
A Quokka, especializada em segurança mobile e anteriormente conhecida como Kryptowire, analisou 250.000 aplicativos Android, identificando mais de 35.000 chaves únicas expostas, presente em 39,5% dos apps avaliados.
A CloudSEK, por sua vez, mapeou 32 chaves embutidas diretamente em 22 aplicativos populares, que possuem uma base combinada de mais de 500 milhões de usuários. Todas seguem o formato AIza…, padrão das chaves de projeto do Google Cloud.
O ataque não exige acesso à infraestrutura da vítima
O processo de exploração não requer habilidades técnicas avançadas. Um atacante descompila o APK com qualquer ferramenta de código aberto disponível, aplica uma expressão regular para identificar strings no formato das chaves do Google e testa a chave com uma única chamada à API do Gemini. Se receber uma resposta 200, a chave está ativa e com acesso ao serviço de IA.
A partir daí, as possibilidades de abuso se dividem em três categorias principais. A primeira é o acesso a dados: arquivos enviados ao Gemini pelo desenvolvedor, conteúdos armazenados e qualquer informação processada pela plataforma ficam acessíveis. Se o aplicativo faz upload de conteúdos dos usuários para a API, tais como imagens, documentos ou textos, esse material também pode ser acessado indiretamente.
A segunda categoria refere-se ao abuso financeiro. Chamadas automatizadas a inferências a grandes modelos de linguagem esgotam rapidamente a cota disponível. Estima-se que o custo pode atingir milhares de dólares diariamente em uma conta comprometida, com os encargos recaindo sobre o desenvolvedor.
A terceira é a interrupção do serviço, uma vez que esgotar a cota de API de um projeto impede que os sistemas legítimos do desenvolvedor funcionem. Isso ocorre porque a cota é por projeto, não por usuário.
O que torna o problema estruturalmente difícil de resolver
Um aspecto preocupante do problema, ressaltado pela Quokka e pela CloudSEK, é que os desenvolvedores não cometeram erros; eles seguiram as orientações documentadas pelo próprio Google. As chaves foram incorporadas nos aplicativos porque essa era a abordagem recomendada, e permanecem nas versões subsequentes dos aplicativos porque ninguém as removeu.
A escalada retroativa de privilégios é um dos elementos mais urgentes desta questão. Uma chave com permissões limitadas automaticamente ganha novos acessos quando o Google ativa serviços recentes no projeto, sem necessidade de ação do desenvolvedor ou notificação explícita. Um atacante que extraiu uma chave de um APK publicado há dois anos pode acessar um endpoint de IA habilitado recentemente.
As chaves também são públicas por design, uma vez que os APKs são distribuídos em lojas para que usuários possam baixá-los e instalá-los. Não é possível revogar o acesso a uma chave já distribuída sem rotacioná-la e publicar uma nova versão do aplicativo.
Como se proteger
Uma remediação imediata envolve auditar projetos no Google Cloud Console para identificar quais têm a Genetic Language API habilitada, verificar quais chaves nesses projetos são irrestritas ou possuem acesso ao Gemini, e rotacionar qualquer chave que apareça no código do cliente, repositórios públicos ou APKs distribuídos.
A forma correta de autenticação para APIs sensíveis é utilizar chaves restritas por IP, por referrer HTTP ou com escopo específico de API, limitando o que cada chave pode fazer mesmo se comprometida. Outra alternativa é migrar para fluxos OAuth 2.0, que autenticam o usuário sem expor uma credencial estática no código do aplicativo.
Acompanhe o TecMania nas redes sociais. Para mais notícias de segurança e tecnologia, inscreva-se em nossa newsletter e canal do YouTube.