GitLost: enganando o agente de IA do GitHub para vazar repositórios privados

 (noma.security)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • A Noma Labs descobriu o GitLost, uma vulnerabilidade de injeção indireta de prompt nos GitHub Agentic Workflows, que permitia expor dados de repositórios privados da mesma organização em comentários públicos usando apenas uma issue em um repositório público
  • O recurso compila workflows em Markdown para arquivos YAML do Actions, e sua estrutura faz com que um agente de IA baseado no Claude ou no GitHub Copilot leia issues, chame ferramentas e acesse repositórios dentro da organização
  • O workflow vulnerável lia o Title e o Body da issue no evento issues.assigned e respondia com add-comment, tendo permissões de leitura para repositórios públicos e privados
  • O atacante só precisava abrir uma issue plausível em um repositório público, sem código, permissões de acesso ou credenciais; nos testes, o conteúdo de README.md de poc e testlocal foi publicado em comentários de uma issue pública
  • As guardrails do GitHub não bloquearam como esperado na variação com “Additionally”, e, em IAs agênticas, a própria janela de contexto deve ser vista como superfície de ataque, separando conteúdo controlado pelo usuário de instruções confiáveis

A fronteira de confiança explorada pelo GitLost

  • A Noma Labs descobriu uma vulnerabilidade chamada GitLost nos novos Agentic Workflows do GitHub
  • Quando um atacante não autenticado publicava uma GitHub Issue manipulada em um repositório público da mesma organização, era possível induzir o agente a buscar dados de repositórios privados dentro da organização
  • O método de ataque corresponde a uma injeção indireta de prompt, em que instruções maliciosas ficam ocultas no conteúdo lido pelo agente de IA
  • Se as instruções ocultas pelo atacante fossem processadas com prioridade sobre as instruções pretendidas pelo operador, dados privados poderiam ser expostos em comentários de issues públicas visíveis a qualquer pessoa

Como funcionam os GitHub Agentic Workflows

  • Os GitHub Agentic Workflows permitem que equipes escrevam automações de repositório em linguagem natural
  • O workflow é escrito em um arquivo Markdown .md e compilado para um arquivo GitHub Actions .yml em formato YAML
  • Na execução, um agente de IA baseado no Claude ou no GitHub Copilot trabalha dentro das permissões configuradas
    • Ler GitHub Issues
    • Chamar ferramentas
    • Acessar outros repositórios dentro da organização

Condições do workflow vulnerável

  • A configuração vulnerável identificada pela Noma Labs se tornava problemática quando issues públicas eram combinadas com permissões do agente
    • Acionamento do workflow pelo evento issues.assigned do GitHub
    • Leitura do Title e do Body da issue
    • Publicação de comentário com a ferramenta add-comment
    • Permissão de leitura para outros repositórios dentro da organização
      • Repositórios públicos
      • Repositórios privados
  • O atacante não precisava escrever código, ter permissões de acesso nem possuir credenciais adicionais
  • A única condição necessária era abrir uma issue em um repositório público de uma organização que usa GitHub Agentic Workflow

Fluxo do ataque

  • Os pesquisadores criaram uma GitHub Issue plausível, parecendo um pedido do VP de Sales após uma reunião com cliente
  • Quando a issue foi atribuída, a action do workflow foi acionada; nos testes, o mesmo comportamento ocorreu também em outra GitHub workflow action
  • Depois que a automação do GitHub atribuiu a issue, o workflow executado pelo evento fez o agente buscar o conteúdo dos repositórios
  • O agente foi induzido a buscar o conteúdo de README.md dos seguintes repositórios
    • Repositório público poc
    • Repositório privado testlocal
  • Em seguida, o agente do GitHub publicou esse conteúdo como comentário na issue do repositório público, deixando-o legível para qualquer pessoa

Contornando guardrails com “Additionally”

  • O GitHub tinha guardrails limitadas para impedir esse cenário
  • A Noma Labs testou repetidamente diversas variações, como faria um atacante
  • Ao adicionar a palavra-chave “Additionally”, ocorreu um comportamento inesperado em que o modelo reestruturou a saída sem recusá-la
  • Com esse bypass, as guardrails do GitHub não funcionaram como esperado e não impediram o vazamento de dados

PoC e dados expostos

Premissas de segurança que mudam em IAs agênticas

  • A janela de contexto do agente é, ao mesmo tempo, espaço de trabalho e superfície de ataque
  • Todo conteúdo lido pelo agente pode ser transformado em arma
    • Issues
    • Pull Requests
    • Comentários
    • Arquivos
  • Modelos tradicionais de segurança muitas vezes assumem que fronteiras de confiança são impostas por código
  • Em sistemas agênticos, parte da fronteira de confiança é imposta pelo comportamento do modelo
  • Como o modelo é inerentemente orientado a seguir instruções, a injeção de prompt se torna, para IAs agênticas, uma vulnerabilidade categórica do mesmo tipo que a injeção de SQL foi para aplicações web
  • Esse tipo de vulnerabilidade exige estratégias e defesas sistemáticas

Defesas recomendadas e processo de divulgação

  • Conteúdo controlado pelo usuário não deve ser tratado como entrada de instruções confiáveis para agentes de IA
  • As permissões do agente devem ser limitadas ao menor escopo necessário
    • Agentes que podem acessar vários repositórios se tornam alvos de ataque especialmente valiosos
  • Deve-se limitar o que o agente pode publicar publicamente, como em respostas a conteúdos de issues
  • Antes de passar entradas de usuário ao modelo, elas devem ser sanitizadas ou isoladas do contexto de instruções
  • O GitLost foi divulgado de forma responsável ao GitHub, e os detalhes da vulnerabilidade foram compartilhados com ciência do GitHub

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News

  • A analogia de que injeção de prompt ocupa, em IA agentiva, o mesmo lugar que SQL injection ocupava em apps web parece estranha. Dá a impressão de que injeção de prompt é muito mais grave para LLMs do que SQL injection era para SQL
    SQL injection surgia porque a entrada do usuário virava parte da string de comando enviada ao mecanismo SQL, e uma entrada maliciosa podia encerrar o comando atual com tokens da sintaxe SQL e anexar seu próprio comando SQL, fazendo o mecanismo executar ambos. A solução foi usar strings de comando fixas, estáticas e pré-compiladas, como prepared statements, e tratar a entrada arbitrária do usuário apenas como dados
    Em agentes, uma mitigação parecida seria ter ações fixas como “ler repo 1”, “ler repo 2”, e usar a entrada do usuário apenas como dado para escolher qual ação executar; mas isso é uma técnica que já chamamos de menu. O valor do LLM está justamente em ir além de um menu, enquanto o valor do SQL não precisa ir além de “lógica predefinida aplicada a dados arbitrários”

    • Sim. SQL injection acontecia porque a entrada do usuário era tratada não como dado puro, mas como parte do comando; separar os dois resolveu o problema. Injeção de prompt é difícil de evitar porque a própria entrada do usuário é intencionalmente tratada como comando
    • A “solução” não é exatamente prepared statements; o ponto central é binding de parâmetros. Você envia os parâmetros separadamente da instrução SQL, separando código e dados do usuário
      Permitir apenas ações limitadas ao agente cobre só alguns problemas específicos e também não separa código e dados do usuário, então não é o mesmo problema. Ter só ações limitadas se parece mais com usar permissões mais rígidas no banco de dados. Se só for permitido ao usuário executar SQL que ele já poderia executar de qualquer forma, SQL injection também perde muito do impacto
    • É o mesmo tipo de problema que SQL injection, mas a dificuldade de resolver não é a mesma. Podem surgir muitos problemas mais sutis, mas como analogia explicativa até que funciona bem
      Fazer o usuário escolher num menu é um caminho, mas a faixa de ações possíveis pode ser projetada de forma mais ampla. Se você der uma ferramenta de e-mail, ela pode enviar spam para clientes; se você travar para permitir apenas respostas, reduz o escopo do dano. Assim como em vulnerabilidades em que dados vazam por renderização de imagem, exfiltração de dados também precisa ser limitada
    • Injeção de prompt não é algo catastrófico, e na prática está mais para expor um problema subjacente de arquitetura de segurança do que para ser o problema em si. É parecido com ataques de engenharia social contra humanos
      A solução também é a mesma. Aplique controle de acesso baseado em papéis com privilégio mínimo e exija aprovação de administrador para ações importantes. Aí o pior que o LLM consegue fazer sozinho é gerar alguma saída com palavras inadequadas
    • Não tenho certeza de que isso seja um problema tão profundo quanto todo mundo imagina. SQL injection também é perigosíssimo. Ela abre acesso irrestrito a tudo que o usuário da consulta consegue fazer no banco de dados
      Uma mitigação é prepared statements, mas outra é nunca permitir a nenhum usuário acesso total ao banco inteiro. Um usuário somente leitura não deveria conseguir dar DROP TABLE, independentemente de haver SQL injection ou não
      Este agente tem acesso irrestrito de leitura e não tem conceito de “destinatário” da resposta. Se você incluir as permissões do destinatário, fazer com que o acesso de leitura seja negado automaticamente fica bem simples. Não é a única solução, mas não é difícil imaginar saídas nessa linha
      O exemplo do “menu” também significa que nada mudou. Seja um LLM ou um funcionário humano, o que é permitido continua sendo apenas um conjunto controlado e fixo de ações. A liberdade está principalmente na expressão, enquanto a autorização é um conjunto fixo. Não vejo por que precisaria ir além de um menu

  • Não entendo por que isso seria uma vulnerabilidade do GitHub. Os pesquisadores deram ao agente permissão de acesso a repositórios privados e o fizeram responder perguntas em um repositório público, então obviamente seria possível extrair informações privadas
    É o mesmo que criar uma tarefa comum de CI com acesso a segredos e executá-la em um PR público. Se você configura o GitHub para que código público ou instruções para o LLM sejam executados em um contexto com acesso a algo sensível, vai haver vazamento. Isso não é culpa do GitHub, é culpa de quem configurou

    • Parece que partiram da premissa de que as permissões ficam limitadas apenas ao repositório onde a pergunta é feita, e não incluem repositórios privados. Consigo entender as duas lógicas
    • O GitHub não facilita configurar o acesso do agente de forma segura. Tokens de acesso gerais e credenciais de app não oferecem controle granular suficiente para dar acesso direto a repositórios privados
      Mesmo apertando ao máximo o escopo do token, o acesso a repositórios públicos continua sempre permitido e, por exemplo, permanece um caminho de exfiltração por issues de repositórios públicos. Para fazer isso com segurança, seria preciso complementar com um proxy MITM que implemente controles mais rígidos do que os oferecidos pelo GitHub
      Os GitHub Agentic workflows deveriam ser a principal solução oficial para esse tipo de problema, mas ainda parece haver trabalho a fazer, seja no modelo de segurança, seja na usabilidade segura
      Mais detalhes: https://haulos.com/blog/do-not-give-your-agent-github-access...
    • No centro desses ataques de prompt injection está o problema de não conseguir limitar corretamente o escopo das permissões do agente. Neste caso, dependendo do que o agente realmente precisa fazer, dá para ter agentes de workflow separados por repositório ou então um agente com acesso mais amplo a repositórios, mas configurado para ser acionado apenas por usuários de uma allowlist
      Isso também é compatível com desenvolvimento aberto e permite que pessoas externas abram issues públicas, ao mesmo tempo refletindo o nível de confiança atribuído a cada usuário. Se pensar direito, provavelmente há ainda mais opções
      Para isso, é preciso suporte técnico para escopo e permissões bem detalhados, e também investir tempo em avaliar o que se quer alcançar com agentes e quais são as permissões e capacidades mínimas necessárias
      O primeiro ponto provavelmente vai chegar. O uso de agentes ainda está em clima de Velho Oeste. É interessante pensar quais abstrações vão reduzir o atrito de o ser humano precisar encontrar e definir escopo e permissões ao projetar agentes, e qual será a interface capaz de equilibrar granularidade e usabilidade ao limitar capacidades de agentes
      O segundo ponto sempre foi um dos principais obstáculos à construção de software de alta qualidade. Reservar tempo para pensar direito e implementar direito entra em choque frontal com a abordagem de “agir rápido e quebrar coisas” ao sair jogando agentes em qualquer lugar
    • Existe alguma forma de separar os acessos por workflow agêntico, de modo que um acesse dados sensíveis e outro acesse apenas dados públicos? O padrão é limitar o escopo somente ao repositório atual? O GitHub avisa de forma adequada sobre os riscos de combinar acesso a dados de repositórios privados com workflows agênticos?
      Se a resposta para qualquer uma dessas perguntas for “não”, então há um problema. Workflows clássicos do GitHub também estão cheios de elevação de privilégio por meio de workflows disparados por PR, mas isso é outro assunto
    • Do ponto de vista de permissões, um LLM é só um terminal burro. O que se quer parece ser criar permissões sintéticas na hora com base no prompt, mas isso está mais para “vou sanitizar SQL de usuário com regex” do que para uma solução de “frases prontas”. E já sabemos muito bem como isso termina
      A solução real é melhorar a UI de controle de permissões por prompt. Assim como se escolhe “usar busca na web ou não”, deveria ser fácil ligar e desligar uma opção como “incluir meus repositórios privados”

  • É engraçado ver os pesquisadores burlando as guardrails que o GitHub promovia com uma única palavra como “Additionally”. Isso mostra que tentar erguer uma fronteira de segurança forte dentro da janela de contexto de um LLM está condenado ao fracasso
    Como o modelo é feito essencialmente para seguir instruções, quando se misturam regras de sistema com entrada do usuário, a instrução mais recente ou mais insistente tende a vencer

  • Por que a seção de “divulgação responsável” não diz quando isso foi corrigido, nem se o GitHub reconheceu ou rejeitou o problema? Está escrito que o GitLost foi divulgado de forma responsável ao GitHub e que os detalhes estão sendo compartilhados com o GitHub ciente deles; então isso ainda não foi corrigido?

    • Isso não é um bug de software comum e não dá para “corrigir” da mesma forma, assim como não dá para corrigir o fato de um atendente de suporte cair em um golpe. A resposta é não permitir que o LLM acesse ao mesmo tempo entrada não confiável e dados sensíveis
    • Fico curioso se o autor do post original fez o experimento com a configuração abaixo ativada. Existe uma configuração literal para impedir isso. Quero saber se essa configuração surgiu por causa desse relatório ou se foi descuido do autor não mencioná-la no comentário
      https://github.github.com/gh-aw/reference/cross-repository/#...
    • O que exatamente haveria para corrigir? Só deram ao LLM acesso a dados privados e a capacidade de ler comentários públicos ao mesmo tempo. É simplesmente uma configuração errada

  • Grandes empresas como a Microsoft, sob pressão de investidores, agora tentam se vender como empresas de IA enfiando IA em todos os produtos. É parecido com o que a Adobe fez
    Os consumidores estão ficando cansados dessas integrações de IA meio inacabadas, e parece que em breve isso vai bater no limite

    • Para mim, já deu. Migrei para o Forgejo. É excelente e tudo funciona melhor
      Sério, ao clicar nas coisas aqui e ali, tudo é instantâneo, e o CI com runner conectado também funciona lindamente. A documentação de configuração do runner poderia ser um pouco mais clara, mas fora isso tudo foi extremamente fluido
    • A Microsoft é uma empresa de capital aberto. Que investidor estaria pressionando para estragar o GitHub com recursos de IA que ninguém quer? Em que reunião isso acontece?
    • Concordo, mas acho os produtos corporativos de IA bem impressionantes. Investidores e consumidores não entendem bem, e funcionários não podem negociar
      A receita existe de fato e é impressionante, substituindo receita de consumidores e por assento. O mercado ainda está reduzindo os múltiplos de SaaS, mas acho essa leitura correta. Se você separar a receita nos relatórios trimestrais, há uma grande história de crescimento vinda de eficiência real

  • Não entendo por que uma action executada no contexto de um repositório público tinha permissão de acesso a repositórios privados. Pelo workflow, parece que estava usando um github token que normalmente não recebe permissões para repositórios privados
    Ou então o próprio agente tinha, somehow, privilégios mais altos? Se for isso, então o agente foi configurado de forma incorreta. Já sabemos que não dá para confiar que o agente vá impor esse tipo de restrição

  • Este texto soa como marketing da Noma. Tem nome bonitinho, logo e título caça-cliques, além de um tom dramático que parece mirar leitores não técnicos
    A vulnerabilidade real, no fim das contas, é que, se você der dados privados a um LLM e deixar qualquer um interagir com ele, esses dados podem vazar. Isso é óbvio demais

  • Esse pessoal vai acabar dando ao LLM permissão de escrita no disco inteiro e depois reclamando quando ele fizer algo destrutivo
    Se você não quer que um agente de IA leia repositórios privados, basta não dar a ele permissão de acesso a repositórios privados. Isso não é um problema de bypass de permissões, e sim de prompt injection, e não dá para resolver isso de forma confiável na camada do agente

  • Ou isso já é um problema resolvido, ou o GitHub ainda não conseguiu resolver e, nesse meio-tempo, agentes maliciosos vão tentar explorar vulnerabilidades nos repositórios
    Como há muitos repositórios, a chance de haver vazamentos não é zero. Ainda assim, assim como em golpes, quase ninguém vai admitir que teve dados vazados