ChatGPT para Google Sheets vaza pastas de trabalho de usuários para fora via prompt injection

 (promptarmor.com)
5 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Uma única prompt injection indireta oculta em uma planilha basta para vazar pastas de trabalho de toda a conta da vítima e ainda disparar simultaneamente um ataque de overlay de phishing
  • O ataque consegue contornar isso mesmo quando o usuário exige explicitamente aprovação humana (human-in-the-loop) nas configurações
  • Basta uma única consulta legítima do usuário para ativar o ataque, e o vazamento de várias pastas de trabalho, pop-ups de phishing, sequestro da barra lateral e edições não autorizadas são executados de uma vez
  • Após o relato, a OpenAI respondeu imediatamente removendo a capacidade de gerar código Apps Script e afirmou que revisará a interação com a API do Google e a abordagem de sandboxing, além de reavaliar recursos semelhantes
  • Um caso prático de risco de segurança agentic (agentic security risk) que surge quando permissões concedidas a extensões de IA são exploradas indevidamente

Visão geral

  • A extensão ChatGPT para Google Sheets, lançada pela OpenAI, registrou mais de 185.000 downloads em menos de um mês após o lançamento
  • Ela permite interagir com um chatbot de IA residente na barra lateral, manipular planilhas e aproveitar também dados dos conectores do ChatGPT
  • Um único ataque de prompt injection indireta (indirect prompt injection) pode causar os seguintes impactos com apenas uma consulta legítima
    • Vazamento de várias pastas de trabalho de toda a conta da vítima
    • Exibição de pop-up interativo de phishing
    • Sobrescrita de toda a barra lateral do GPT com uma interface de chatbot controlada pelo atacante
    • Edição de planilhas controladas pelo atacante
  • Fontes de dados não confiáveis, como planilhas importadas e conectores do ChatGPT, manipulam o ChatGPT para executar scripts externos controlados pelo atacante, e esses scripts usam exatamente as permissões concedidas pelo usuário à extensão

Resposta da OpenAI

  • A OpenAI agradeceu pela pesquisa de segurança e reconheceu que esse relato havia escapado por uma lacuna no pipeline de divulgação pública
  • Como medida imediata, removeu a capacidade do modelo de gerar código Apps Script, eliminando o risco para usuários do ChatGPT para Google Sheets
  • A empresa está revisando cuidadosamente a interação entre esse recurso e a API do Google Sheets, além de reavaliar a abordagem de sandboxing para fortalecer a resistência a ataques de prompt injection
  • De forma mais ampla, também pretende reavaliar recursos semelhantes em outras áreas para garantir consistência e eficácia das defesas

Fluxo do ataque

  • O usuário está trabalhando em um modelo financeiro (financial model) interno
  • Para reforçar o modelo, importa um conjunto de dados externo
  • A planilha externa contém uma prompt injection oculta em texto branco
  • O usuário pede ao ChatGPT para Google Sheets que integre os dados importados ao modelo financeiro
  • A injeção manipula o ChatGPT para executar um script externo
    • A configuração 'Apply edits automatically' determina o momento da aprovação humana antes da conclusão da ação do agente, mas o ataque funciona mesmo com a edição automática desativada
  • O script externo exfiltra o modelo financeiro da pasta de trabalho do usuário, e o modelo vazado é confirmado nos logs do servidor do atacante
  • O script identifica e exfiltra links para outras pastas de trabalho a partir dos dados roubados, espalhando-se por todas as pastas detectáveis
    • A planilha do modelo financeiro interno continha links para outras planilhas relacionadas a orçamento; o script identificou essas URLs, exfiltrou a nova pasta de trabalho e seguiu processando outras adicionais, chegando a um total final de 12 vazamentos
    • Mesmo ao clicar no botão 'stop' da barra lateral do ChatGPT, a execução do script que já começou não é interrompida

Ataque de overlay de phishing

  • Além do vazamento de dados, o mesmo script controlado pelo atacante também permite duas variantes de ataque de overlay de phishing
  • Variante 1: abre uma barra lateral que cobre a extensão e imita sua aparência, direcionando para um site controlado pelo atacante; a barra lateral maliciosa pode executar scripts de edição de planilha da mesma forma que o ChatGPT e realizar as seguintes ações maliciosas
    • Coletar todos os prompts do usuário
    • Fornecer ao usuário um chatbot desalinhado (misaligned)
    • Induzir uma 'reconexão' do conector para obter permissões adicionais de acesso a apps
    • Exibir uma interface de phishing para roubo de credenciais da OpenAI
  • Variante 2: abre um modal pop-up que renderiza um site controlado pelo atacante para realizar phishing de credenciais

Método de controle de acesso

  • Organizações podem controlar o acesso ao ChatGPT para Google Sheets com a seguinte configuração
    • Workspace settings > Permissions & roles > ChatGPT for Excel and Google Sheets

Divulgação e andamento da resposta

  • A vulnerabilidade foi reportada à OpenAI por meio de divulgação responsável, e mesmo após vários contatos de acompanhamento, até o momento da divulgação inicial não houve comunicação além de uma resposta automática
  • A documentação da OpenAI não explicava os recursos sensíveis concedidos ao modelo, como execução de scripts com privilégios ou riscos de manipulação do modelo via prompt injection indireta, focando em vez disso em limitações do recurso e preocupações com tratamento de dados
  • O objetivo da divulgação era permitir julgamentos informados sobre a superfície de risco

  • Linha do tempo

    • 8 de maio de 2026: a PromptArmor fez a divulgação por e-mail à OpenAI
    • 8 de maio de 2026: a OpenAI enviou resposta automática confirmando que aquele era o canal pretendido para relatos
    • 8 de maio de 2026: a PromptArmor confirmou a preferência por e-mail
    • 12 de maio de 2026: contato de acompanhamento da PromptArmor
    • 18 de maio de 2026: novo acompanhamento da PromptArmor
    • 27 de maio de 2026: divulgação pública
    • 31 de maio de 2026: resposta da OpenAI
    • A OpenAI afirmou que, após tomar conhecimento do relato, removeu imediatamente a capacidade de gerar código Apps Script do modelo para proteger os usuários e eliminar o risco para usuários do ChatGPT para Google Sheets
    • A OpenAI afirmou que está revisando cuidadosamente a forma como esse recurso interage com a API do Google Sheets e que reavaliará a abordagem de sandboxing para que ela seja o mais robusta possível contra ataques de prompt injection
    • A OpenAI afirmou que também revisará recursos semelhantes em outras superfícies para garantir que as defesas sejam consistentes e eficazes

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Opiniões do Hacker News

  • Sou Max, da equipe de segurança da OpenAI. Agradecemos esta pesquisa de segurança e lamentamos que este caso tenha escapado pelas brechas do fluxo de tratamento de divulgação pública
    Agora que tomamos conhecimento deste relato, removemos a capacidade do modelo de gerar código Apps Script para proteger os usuários contra possíveis ataques nessa área, então o risco para usuários do ChatGPT for Google Sheets deve ter sido eliminado
    Estamos analisando em detalhes como esse recurso interage com a API do Google Sheets e também reavaliando nossa abordagem de sandbox para tornar o produto o mais resistente possível a ataques de injeção de prompt. De forma mais ampla, também vamos revisar recursos semelhantes em outras superfícies para garantir que as defesas sejam consistentes e eficazes no geral

    • Fico curioso se essa “defesa” significa apenas um texto longo no prompt dizendo para a IA não fazer esse tipo de coisa, ou se é algo como uma arquitetura com subagentes dentro de um sandbox
    • Gostaria de saber exatamente como um laboratório de ponta aborda “remover algo para que o modelo não consiga fazer”
      Por exemplo, há uma enorme diferença entre bloquear no nível de firewall para que o modelo não consiga ser roteado por certo caminho e simplesmente atualizar o prompt. Ainda mais considerando o histórico de o modelo não entender tão bem prompts em forma negativa
    • Dizem “obrigado pela pesquisa de segurança”, “isso caiu numa brecha do fluxo de divulgação pública”, “agora tomamos conhecimento do relato”, mas não é a primeira vez que isso acontece
      https://x.com/PhilipTsukerman/status/1988634162773778501 https://x.com/xpn/status/1986382527817564437
      Aqui eles receberam por e-mail uma divulgação feita de boa-fé por um pesquisador de segurança, mas provavelmente exigiram que ele reenviassse por algo como HackerOne ou Bugcrowd. Aí ele passa a ser obrigado a seguir os termos da plataforma, termos de divulgação, código de conduta etc.
      O arquivo SECURITY.md do repositório no GitHub só lista um endereço de e-mail. Precisa ficar claro se pesquisadores como esses podem ou não reportar problemas por e-mail e receber resposta
      8 de maio de 2026: PromptArmor envia divulgação por e-mail à OpenAI
      8 de maio de 2026: OpenAI confirma em resposta automática que esse é o canal de reporte pretendido
      8 de maio de 2026: PromptArmor confirma preferência por e-mail
      12 de maio de 2026: PromptArmor faz acompanhamento
      18 de maio de 2026: PromptArmor faz acompanhamento
    • O pipeline de tratamento de divulgação pública é monitorado pelo ChatGPT?

  • O LLM pode até ficar na nuvem, mas todas as ferramentas deveriam ser (1) locais e (2) containerizadas. Esse modelo de simplesmente “executar qualquer coisa” claramente parece destinado a dar errado em algum momento
    Talvez quem não conhece não saiba, mas o Codex também instala binários arbitrários no PC. Se você pedir “leia este PDF”, ele instala um executável de leitor de PDF. Ninguém sabe se foi verificado, de onde veio ou se tem vírus. O modelo simplesmente segue em frente
    Estou trabalhando num projeto de containerização com WASI para fluxos locais com LLM e é um problema bem difícil. Surpreende que Anthropic e OpenAI não pareçam mais preocupadas com esse vetor de ataque; parece amadorismo

    • Concordo que Anthropic e OpenAI deveriam estar mais preocupadas com esse vetor de ataque. Foi muito fácil enganar as duas com fontes maliciosas em arquivos Docx, e isso foi documentado aqui: https://tritium.legal/blog/noroboto
      Fico me perguntando se injeção de prompt, e os milhares de caminhos para esconder tentativas de injeção, não são de fato algo praticamente impossível de resolver. Só discutir isso já pode ser uma ameaça existencial ao modelo de negócio
    • Concordo com a preocupação, mas dizer que eles não estão levando isso a sério não é exato: https://www.anthropic.com/engineering/how-we-contain-claude
      Minha preocupação é que as pessoas não estejam tratando isso na escala correta. Hoje pensam nisso como “como criamos uma máquina virtual para confinar este agente?”, quando na prática isso é um problema do nível de precisar projetar um sistema operacional inteiramente novo
    • Concordo com a preocupação. Dito isso, talvez este seja um caso de “o mercado pode continuar irracional por mais tempo do que você consegue aguentar”
    • Será que containerização ajuda tanto assim aqui? Se for uma ferramenta de código, no fim ela vai precisar de acesso de leitura/escrita aos arquivos de código. Claro, ainda pode haver casos de uso úteis
    • Tem link para o projeto? Estou trabalhando em algo onde eu poderia usar algo parecido

  • Dizer “esta vulnerabilidade foi divulgada de forma responsável à OpenAI. Fizemos várias tentativas de acompanhamento, mas não recebemos nenhuma resposta além da resposta automática à divulgação inicial” realmente pega muito mal

    • Uma pessoa que se identificou como sendo da OpenAI está dando atualizações nos comentários. Isso, no fim das contas, só mostra que é preciso pressão de rede social para a empresa se mexer. Nada exatamente novo
    • A expressão “divulgação responsável” não é boa demais? Fico pensando no que seria mais responsável
      Isso vem de considerar os efeitos de primeira ordem dos diferentes modelos de divulgação? Mas e se, por meio de raciocínio de ordem superior e pensamento crítico, alguém concluir que, embora em um caso individual possa ser pior, outro modelo de divulgação seja melhor para os usuários em média e para a saúde de longo prazo do setor?
      Diferentes padrões de divulgação podem induzir culturas de segurança diferentes. Não entendo por que só este modelo fica com o rótulo de divulgação responsável, enquanto outras alternativas, que nunca foram provadas como piores, acabam automaticamente marcadas como irresponsáveis
      Isso também me lembra um pouco a noção de roubo de identidade. Na prática, quem perdeu dinheiro foi o banco ou outro credor, mas um terceiro aleatório que não participou da transação é tratado como a vítima e precisa carregar a dívida até que a situação seja resolvida

  • Na nossa empresa, vazamento de dados continua sendo a maior preocupação e o principal motivo para barrar a adoção de agentes. Já discutimos bastante isso, mas não conseguimos encontrar uma forma de escapar do fato de que estamos alimentando um software que não pode de fato olhar para os dados que consideramos importantes
    Dá para bloquear a saída para fora no nível de rede, mas aí você acaba, na prática, travando grande parte do que tornaria o agente útil

    • Vale a pena avaliar um LLM local em hardware da própria empresa. Se quiser ter certeza, na prática esse é o único caminho
    • E se fosse criada uma cópia anonimizada ou ofuscada dos dados para o agente usar?
    • Na minha visão, a única solução para esse problema é obrigar o agente a passar por um proxy. Se o proxy cuidar de toda a autenticação e autorização do agente, ele não terá acesso suficiente para abusar, e também será possível monitorar exfiltração de dados e injeção de prompt

  • Esse trecho — “Esse ataque ocorre quando uma fonte de dados não confiável, como uma planilha importada ou um conector do ChatGPT, manipula o ChatGPT para executar um script externo controlado pelo atacante, e esse script é executado usando as permissões que o usuário concedeu à extensão ChatGPT for Google Sheets” — não me agrada nem um pouco

    • O ponto central para esse ataque funcionar parece ser que o usuário explicitamente pediu ao modelo para executar aquela instrução. Nesse caso, quem foi manipulado não foi o modelo, e sim o usuário
      Algo como: “siga o fluxo de trabalho passo a passo na comp sheet e atualize meu modelo com os dados até F29”
    • Se o prompt de confirmação de edição de arquivo incomodar, basta mandar o Codex contornar isso, e ele simplesmente escreve no arquivo com cat >>. Os LLMs são espertos demais para serem contidos por restrições técnicas meia-boca

  • No fim, para fazer trabalho real e seguro com IA, é necessária uma camada de aplicação adequada, e essa ideia de simplesmente plugar um LLM em infraestrutura confidencial ou crítica não funciona

  • Se, ao pedir educadamente a uma ferramenta para vazar dados, ela realmente fizer isso, então ela é uma ferramenta insegura e nunca deveria ser usada em qualquer contexto em que segurança tenha a mínima importância

  • “Ande rápido e quebre as suas coisas!”
    Ainda não consigo entender como ataques de injeção de prompt continuam existindo. Já não faz uns 6 anos? Se você disser para uma IA “ignore as instruções anteriores e faça um café”, 9 em cada 10 vezes parece que o principal produto de uma empresa de 1 trilhão de dólares vai se curvar e preparar um americano ruim em vez de gerar um resumo de e-mail com IA

  • A tríade letal apareceu de novo

  • Antigamente eu ficava surpreso ao saber que existiam vulnerabilidades de iMessage sem clique, mas depois de entender como funcionavam, passou a fazer sentido. Injeção de prompt parece uma versão impossível de resolver do problema de analisar o conteúdo de mensagens