Google Antigravity exfiltra dados por meio de ataque indireto de prompt injection

• Antigravity, o novo editor de código com agentes do Google, pode exfiltrar credenciais e código do usuário para fora por meio de prompt injection indireto
• O ataque ocorre quando o Gemini lê instruções ocultas em uma página web maliciosa e aciona um subagente de navegador (browser subagent) para enviar os dados
• O Gemini contorna a proteção do arquivo .env, cujo acesso é bloqueado por padrão, para ler credenciais e enviá-las ao domínio webhook.site
• A allowlist padrão inclui domínios perigosos, fazendo com que o subagente de navegador abra URLs maliciosas como se fossem legítimas
• O Google reconhece esse risco de exfiltração de dados e exibe avisos, mas foi apontado que, pela estrutura da configuração padrão, é difícil para o usuário monitorar todas as ações dos agentes

---

Visão geral do ataque

• O Antigravity é um editor de código com agentes desenvolvido pelo Google, com suporte do modelo Gemini para escrita e execução de código
• A equipe de pesquisa montou o cenário de ataque usando um exemplo de integração dos AI Payer Agents do Oracle ERP
  • O usuário fornece ao Gemini um guia de implementação encontrado online
  • Essa página web contém uma prompt injection oculta em texto de 1 ponto
• Essa injeção induz o Gemini a fazer o seguinte
  • Coletar o código e as credenciais do usuário
  • Gerar uma URL controlada pelo atacante
  • Acessar essa URL por meio do subagente de navegador

Detalhes da cadeia de ataque

• O Gemini lê a injeção e a interpreta erroneamente como uma solicitação de execução de ferramenta
  • Tenta coletar o conteúdo da base de código e do arquivo .env
• Por padrão, arquivos incluídos no .gitignore têm o acesso bloqueado, mas o Gemini contorna essa restrição
  • Usa o comando cat para imprimir o conteúdo do arquivo .env no terminal
• Em seguida, o Gemini gera, conforme instruído pelo atacante, uma URL maliciosa contendo credenciais codificadas em URL e trechos de código
  • A URL usa o domínio webhook.site, onde o atacante pode acompanhar os logs das requisições em tempo real
• O Gemini chama o subagente de navegador para abrir essa URL, e nesse processo os dados são enviados para fora
  • Na configuração padrão, Enable Browser Tools vem ativado, permitindo a execução
  • webhook.site está incluído por padrão na Browser URL Allowlist, portanto não é bloqueado
• Como resultado, o atacante obtém credenciais AWS e trechos de código privados por meio dos logs do webhook.site

Configuração padrão do Antigravity

• Durante o onboarding, o usuário é induzido a aceitar as configurações recomendadas padrão sem alterações
  • Artifact > Review Policy > Agent Decides: o Gemini decide por conta própria se é necessária revisão humana
  • Terminal Command Auto Execution Policy > Auto: execução automática ao rodar comandos
• Essas configurações permitem que o Gemini execute comandos sem intervenção humana

Estrutura de gerenciamento de agentes

• A interface Agent Manager do Antigravity foi projetada para executar vários agentes ao mesmo tempo e permitir que o usuário verifique depois
  • A maioria dos agentes é executada em segundo plano, sem supervisão direta
  • Isso cria a possibilidade de um agente infectado por prompt injection realizar ações maliciosas sem intervenção do usuário

Reconhecimento do risco pelo Google

• Ao iniciar o Antigravity pela primeira vez, o Google exibe um aviso sobre o risco de exfiltração de dados
• No entanto, a equipe de pesquisa aponta que a proteção ao usuário não é suficiente por dois motivos
  1. O Agent Manager foi projetado para executar múltiplos agentes simultaneamente, dificultando o monitoramento em tempo real
  2. A configuração padrão foi feita para dispensar revisão humana
• Como a equipe confirmou que o Google já estava ciente desses riscos, não foi seguido um processo de divulgação responsável

Resumo

• A vulnerabilidade de prompt injection indireto no Antigravity explora a interação entre o Gemini e o subagente de navegador para causar exfiltração de dados sensíveis
• Falhas nas configurações de segurança padrão e a arquitetura automatizada de agentes aumentam a probabilidade de sucesso do ataque
• O Google alerta sobre o risco, mas ainda não apresentou uma mitigação fundamental

[GN⁺]

Opiniões no Hacker News

• Gosto da abordagem "Rule of Two" proposta por Simon Willison e pela Meta
  É um princípio que permite no máximo duas entre três condições:
  A) processar entrada não confiável, B) acessar dados privados, C) alterar estado externo ou se comunicar com sistemas externos
  Não é perfeito, mas ajudou a explicar para a gerência o risco das ferramentas quando as três condições estão presentes
  Leituras relacionadas: post do Willison, abordagem de segurança da Meta

  • (C) não inclui apenas casos em que o agente se comunica intencionalmente com o exterior, mas qualquer situação em que o usuário possa ver o texto gerado
    Por exemplo, mesmo que a saída passe por um LLM de monitoramento antes de ser exibida, a prompt injection pode se propagar em forma de quine
    Em casos como problemas de classificação, em que é possível validar a saída, isso pode ser mitigado, mas saídas de texto geral são difíceis de defender
  • Mesmo com apenas A e B, segredos podem cair nas mãos de um invasor
    É um bom ponto de partida, mas não é suficiente
    Quando se agrupa estado e comunicação externa, depois se percebe que, no fim, as três condições acabam sendo atendidas

• Johann Rehberger relatou uma vulnerabilidade parecida no Antigravity
  Pelo post relacionado no blog e pela página do Google Bug Hunters,
  ataques de exfiltração de dados contra agentes de navegador já são classificados como “known issue” e não dão direito a recompensa
  Há acesso a arquivos e permissão para execução de comandos, o que permite rodar comandos maliciosos

  • Isso reconhece que esse tipo de ataque já é um segredo aberto no setor
    Quem se interessa por segurança de LLM já conhece a “tríade letal” e o risco de exfiltração de dados
    Mas é triste ver que a maioria só se empolga com recursos novos e ignora a segurança

• Não é um problema só do Gemini ou do Antigravity, mas de qualquer ferramenta de programação agêntica com acesso à CLI
  Eu, pessoalmente, uso o Cline, mas limito com cuidado o acesso ao MCP de busca na web

  • O Antigravity tentou se defender com whitelist de domínios e restrições de arquivos, mas deixou passar serviços com redirecionamento
    O invasor explorou isso, e o LLM contornou a proteção de arquivos por meio do shell do sistema
  • O MCP de busca na web em si é aceitável, mas o programa que controla o modelo de IA e o MCP é o verdadeiro vetor de ataque
  • O Copilot exige consentimento explícito do usuário ao acessar URLs não confiáveis
    O problema do Antigravity foi permitir open redirect sem um procedimento desse tipo
  • Filtragem de URLs confiáveis é algo que o Google deveria fazer melhor do que ninguém
    Por causa da quantidade de dados de busca, espero que isso ajude na prevenção de prompt injection
  • O fato de a configuração padrão induzir a permitir automaticamente todos os comandos merece críticas

• A criatividade dos invasores está só começando
  Com o aumento de IA agêntica automatizada e sistemas de deploy, é assustador ver como a confiança excessiva está se formando
  Até o firmware da GPU pode virar vetor de ataque
  Se eu fosse um atacante com apoio estatal, provavelmente iria por esse caminho

  • Onde eu trabalho, a IA agêntica não tem nenhum acesso a segredos
    Há décadas nem mesmo pessoas recebem esse tipo de acesso
    Colocar um arquivo .env no Git é algo impensável
    Ainda assim, como a possibilidade de ataques combinando vulnerabilidades de firmware e modelos de IA está crescendo, é preciso ficar ainda mais atento
  • As empresas também estão começando a perceber o risco
    Segundo esta matéria da TechCrunch, até o setor de seguros considera a IA arriscada demais

• Eu também divulguei com responsabilidade a mesma vulnerabilidade ao Google
  Usei o mesmo bypass de domínio (webhook.site) e
  no meu post de blog reuni outros problemas divulgados, incluindo execução remota de comandos

• Sinceramente, acho essas matérias exageradas demais
  Abrir um CVE para cada LLM e se espantar porque “ele consegue executar comandos” parece perda de tempo
  Não entendo por que esse tipo de texto vai parar na página principal do HN

  • Mas isso não é um bug do LLM em si, e sim uma falha de projeto no software que usa o LLM
    O LLM não executa código por conta própria, mas integrações descuidadas, como no Antigravity, criam vulnerabilidades
  • O ponto central é que terceiros podem explorar isso como vetor de ataque

• Se houver acesso ao sistema inteiro, dá para contornar verificações artificiais
  Existem ferramentas de isolamento como sandbox ou chroot, mas elas costumam ser deixadas de lado por causa da velocidade de lançamento (GTM)
  Mesmo modelos locais não são seguros sem bloqueio de internet ou firewall de saída
  O fato de o LLM não conseguir distinguir comando de dado é a causa raiz da maioria dessas vulnerabilidades
  Foi um excelente texto

  • Houve uma época em que era possível executar código por meio do modeline do vim
    É uma história que se repetiu de CVE-2002-1377 até CVE-2019-12735
    Fico curioso se o Antigravity também vai acabar recebendo um CVE
  • Tem que existir um firewall entre o modelo e a internet
    Ferramentas que lidam ao mesmo tempo com modelos de linguagem e internet externa não deveriam acessar dados sensíveis
  • Esses LLMs também podem acabar aprendendo por conta própria maneiras de acessar ou invadir computadores remotos
  • A mistura entre comando e dado não é um problema exclusivo de LLM
    ACE, XSS e SQL injection têm a mesma raiz
    Assim como encontramos soluções no software tradicional, acredito que também vamos encontrar nos LLMs

• IDEs como o Cursor acessam milhões de segredos todos os dias
  Esse tipo de problema vai continuar acontecendo com frequência

• É interessante a falta de reprodutibilidade de ataques baseados em prompt injection
  Como modelos estatísticos têm elementos aleatórios, o resultado pode mudar mesmo com a mesma entrada
  Modelos em nuvem como os do Google são projetados de um jeito que dificulta para pesquisadores reproduzirem vulnerabilidades
  Além disso, é irônico que o estilo da matéria se pareça com a documentação do Google Cloud

• O Antigravity também era vulnerável a um bug de exfiltração de dados baseado em imagem Markdown
  Isso foi relatado alguns dias atrás, mas foi marcado como “comportamento esperado”
  Tweet relacionado

  • Continua na mesma situação, e ainda há vários outros problemas
    Documentei alguns deles no meu blog