Pesquisadores demonstram novas técnicas de ataque CI/CD na cadeia de suprimentos PyTorch

Início / Tecnologia da Informação / Pesquisadores demonstram novas técnicas de ataque CI/CD na cadeia de suprimentos PyTorch
Pesquisadores demonstram novas técnicas de ataque CI/CD na cadeia de suprimentos PyTorch

Dois pesquisadores de segurança conseguiram se infiltrar na infraestrutura de desenvolvimento do PyTorch usando novas técnicas que exploram configurações inseguras nos fluxos de trabalho do GitHub Actions. Seu ataque de prova de conceito foi divulgado de forma responsável ao desenvolvedor líder do PyTorch, Meta AI, mas outras organizações de desenvolvimento de software que usam GitHub Actions provavelmente cometeram os mesmos erros de implantação, expondo-se potencialmente a ataques à cadeia de suprimentos de software.

“Nosso caminho de exploração resultou na capacidade de fazer upload de versões maliciosas do PyTorch para o GitHub, fazer upload de versões para a AWS, potencialmente adicionar código à ramificação do repositório principal, dependências backdoor do PyTorch – a lista continua”, disse o pesquisador de segurança John Stawinski em uma redação detalhada sobre o ataque ao seu blog pessoal. “Resumindo, foi ruim. Muito ruim.

Stawinski planejou o ataque junto com o colega Adnan Khan. Ambos trabalham como engenheiros de segurança para a empresa de segurança cibernética Praetorian e no verão passado começaram a investigar e desenvolver uma nova classe de explorações para plataformas de integração contínua e entrega contínua (CI/CD). Um de seus primeiros alvos foi o GitHub Actions, um serviço de CI/CD que permite aos usuários do GitHub automatizar a construção e o teste de código de software, definindo fluxos de trabalho que são executados automaticamente dentro de contêineres na infraestrutura do GitHub ou do próprio usuário.

Khan inicialmente encontrou uma vulnerabilidade crítica isso poderia ter levado ao envenenamento das imagens oficiais dos executores do GitHub Actions. Os “executores” são as máquinas virtuais (VMs) que executam ações de construção definidas nos fluxos de trabalho do GitHub Actions. Depois de relatar a vulnerabilidade ao GitHub e receber uma recompensa de US$ 20.000 por bug, Khan percebeu que o problema principal que encontrou era sistêmico e que milhares de outros repositórios provavelmente foram afetados.

Desde então, Khan e Stawinski encontraram vulnerabilidades nos repositórios de software e na infraestrutura de desenvolvimento de grandes corporações e projetos de software e coletaram centenas de milhares de dólares em recompensas por meio de programas de recompensa por bugs. Suas “vítimas” incluíam o Microsoft Deepspeed, um aplicativo Cloudflare, a biblioteca de aprendizado de máquina TensorFlow, as carteiras criptográficas e os nós de vários blockchains, e o PyTorch, uma das estruturas de aprendizado de máquina de código aberto mais amplamente utilizadas.

PyTorch foi originalmente desenvolvido pela Meta AI, uma subsidiária da Meta (anteriormente Facebook), mas seu desenvolvimento agora é governado pela PyTorch Foundation, uma organização independente que opera sob a égide da Linux Foundation.

“Começamos descobrindo todas as nuances da exploração do GitHub Actions, executando ferramentas, táticas e procedimentos (TTPs) que nunca haviam sido vistos antes”, disse Stawinski em uma postagem no blog no início deste mês. “À medida que nossa pesquisa avançava, evoluímos nossos TTPs para atacar múltiplas plataformas CI/CD, incluindo GitHub Actions, Buildkite, Jenkins e CircleCI.”

Leia também: OWASP AI Exchange: um guia de segurança cibernética de código aberto para componentes de IA

Executar executores do GitHub Actions auto-hospedados é arriscado

GitHub oferece diferentes tipos de “executores” pré-configurados (Windows, Linux e macOS) que são executados diretamente na infraestrutura do GitHub e podem ser usados ​​para testar e criar aplicativos para esses sistemas operacionais. No entanto, os usuários também têm a opção de implantar o agente de compilação GitHub Actions em suas próprias infraestruturas e vinculá-lo à sua organização e repositórios GitHub. Eles são conhecidos como executores auto-hospedados e oferecem vários benefícios, como a execução de diferentes versões de sistemas operacionais e combinações de hardware, bem como ferramentas de software adicionais que os executores hospedados do GitHub não fornecem.

Dada esta flexibilidade, não é surpreendente que muitos projetos e organizações optem por implementar executores auto-hospedados. Esse também foi o caso do PyTorch, que faz uso extensivo de agentes de construção hospedados no GitHub e auto-hospedados. A organização tem mais de 70 arquivos de fluxo de trabalho GitHub diferentes em seus repositórios e normalmente executa mais de dez fluxos de trabalho por hora.

Os fluxos de trabalho de ações são definidos em arquivos .yml que contêm instruções na sintaxe YAML sobre quais comandos executar e em qual executor. Esses fluxos de trabalho são acionados automaticamente em diferentes eventos — por exemplo, pull_request — quando alguém propõe uma alteração de código em uma ramificação do repositório. Isso é útil porque o fluxo de trabalho será acionado e poderá executar, por exemplo, uma série de testes no código antes mesmo que um revisor humano olhe para ele e decida mesclá-lo.

“Não ajuda o fato de algumas das configurações padrão do GitHub serem menos seguras”, disse Stawinski. “Por padrão, quando um executor auto-hospedado é anexado a um repositório, qualquer um dos fluxos de trabalho desse repositório pode usar esse executor. Essa configuração também se aplica a fluxos de trabalho de solicitações pull de fork [PRs]. Lembre-se de que qualquer pessoa pode enviar uma solicitação fork pull para um repositório público do GitHub. Sim, até você. O resultado dessas configurações é que, por padrão, qualquer contribuidor do repositório pode executar código no executor auto-hospedado enviando um PR malicioso.”

Uma solicitação pull de fork significa que alguém criou uma cópia pessoal (um fork) desse repositório, trabalhou nela e agora está tentando mesclar as alterações. Esta é uma prática padrão, pois os contribuidores geralmente trabalham em seus próprios forks antes de enviar as alterações de volta ao repositório principal para aprovação.

Da perspectiva do GitHub, um “contribuidor” é qualquer pessoa cujas solicitações pull foram mescladas de volta ao branch padrão e a configuração padrão para execução do fluxo de trabalho é executar automaticamente em solicitações pull fork de contribuidores anteriores. Isso significa que se alguém alguma vez tiver um PR de bifurcação mesclado, os fluxos de trabalho serão executados automaticamente para todos os seus futuros PRs de bifurcação. Essa configuração pode ser alterada para exigir aprovação antes da execução de fluxos de trabalho em todos os PRs de bifurcação, independentemente de o proprietário ser um colaborador anterior ou não.

“Ao visualizar o histórico de pull request, encontramos vários PRs de colaboradores anteriores que acionaram fluxos de trabalho pull_request sem exigir aprovação”, disseram os pesquisadores. “Isso indicou que o repositório não exigia aprovação de fluxo de trabalho para PRs de fork de contribuidores anteriores. Bingo.”

Leia também: Não há transformação digital sem segurança cibernética

Portanto, um invasor precisaria primeiro se tornar um contribuidor enviando um PR de fork legítimo que fosse mesclado e então ele poderia abusar de seu privilégio recém-adquirido, criar um fork, escrever um arquivo de fluxo de trabalho malicioso dentro dele e fazer uma solicitação pull. Isso executará automaticamente seu fluxo de trabalho malicioso no executor GitHub Actions auto-hospedado da organização.

Parece muito trabalho, mas não é. Você não precisa adicionar novos recursos a um projeto para se tornar um colaborador. Os pesquisadores ganharam status de contribuidor do PyTorch ao encontrar um erro de digitação em um arquivo de documentação e fazer um PR para corrigi-lo. Depois que sua pequena correção gramatical foi aceita, eles conseguiram executar fluxos de trabalho maliciosos.

Leia também: Juntos somos mais fortes: Criando uma comunidade de cibersegurança

Usando o executor GitHub Actions como um trojan

Outro comportamento padrão dos executores do GitHub Actions auto-hospedados é que eles não são efêmeros. Eles não são redefinidos e apagados quando um fluxo de trabalho é concluído. “Isso significa que o fluxo de trabalho malicioso pode iniciar um processo em segundo plano que continuará em execução após a conclusão do trabalho, e as modificações nos arquivos (como programas no caminho, etc.) persistirão após o fluxo de trabalho atual”, disseram os pesquisadores. . “Isso também significa que os fluxos de trabalho futuros serão executados no mesmo executor.”

Isso o torna um bom alvo para implantar algo como um trojan que se conecta aos invasores e, em seguida, coleta todas as informações confidenciais possíveis expostas por futuras execuções de fluxo de trabalho. Mas o que usar como trojan que não seria detectado por produtos antivírus ou cujas comunicações não seriam bloqueadas? O próprio agente executor GitHub Actions, ou melhor, outra instância dele que não está vinculada à organização PyTorch, mas a uma organização GitHub controlada pelos invasores.

“Nossa técnica 'Runner on Runner' (RoR) usa os mesmos servidores para C2 que o executor existente, e o único binário que descartamos é o binário oficial do agente executor GitHub, que já está em execução no sistema. Até mais, EDR e proteções de firewall”, disse Stawinski.

Extraindo tokens de acesso confidenciais

Até esta etapa, os invasores conseguiram executar um programa de trojan muito furtivo dentro de uma máquina que faz parte da infraestrutura de desenvolvimento da organização e que é usada para executar trabalhos confidenciais como parte de seu pipeline de CI/CD. O próximo passo é a pós-exploração: tentar exfiltrar dados confidenciais e migrar para outras partes da infraestrutura.

Os fluxos de trabalho geralmente incluem tokens de acesso ao próprio GitHub ou a outros serviços de terceiros. Esses tokens são necessários para que os trabalhos definidos no fluxo de trabalho sejam executados corretamente. Por exemplo, o agente de construção precisa de privilégios de leitura para fazer check-out do repositório primeiro e também pode precisar de acesso de gravação para publicar o binário resultante como uma nova versão ou para modificar versões existentes.

Esses tokens são armazenados no sistema de arquivos do executor em vários locais, como o arquivo de configuração.git ou em variáveis ​​de ambiente e podem obviamente ser lidos pelo “trojan” furtivo que é executado com privilégios de root. Alguns, como GITHUB_TOKEN, são efêmeros e válidos apenas durante a execução do fluxo de trabalho, mas os pesquisadores encontraram maneiras de prolongar sua vida útil. Mesmo que eles não tivessem encontrado esses métodos, novos fluxos de trabalho com tokens recém-gerados são executados o tempo todo em um repositório movimentado como o PyTorch, portanto, há muitos novos para coletar.

“O repositório PyTorch usou segredos do GitHub para permitir que os executores acessassem sistemas confidenciais durante o processo de lançamento automatizado”, disse Stawinski. “O repositório usava muitos segredos, incluindo vários conjuntos de chaves AWS e GitHub Personal Access Tokens (PATs).”

Os PATs costumam ser excessivamente privilegiados e são um alvo atraente para invasores, mas, nesse caso, foram usados ​​como parte de outros fluxos de trabalho que não estavam em execução no executor auto-hospedado comprometido. No entanto, os pesquisadores encontraram maneiras de usar os tokens efêmeros do GitHub que conseguiram coletar para colocar código malicioso em fluxos de trabalho que estavam sendo executados em outros executores e continham esses PATs.

“Acontece que você não pode usar um GITHUB_TOKEN para modificar arquivos de fluxo de trabalho”, disse Stawinski. “No entanto, descobrimos várias…'soluções alternativas' criativas…que permitirão adicionar código malicioso a um fluxo de trabalho usando um GITHUB_TOKEN. Nesse cenário, Weekly.yml usou outro fluxo de trabalho, que usou um script fora do diretório .github/workflows. Poderíamos adicionar nosso código a este script em nosso branch. Então, poderíamos acionar esse fluxo de trabalho em nossa filial, que executaria nosso código malicioso. Se isso parece confuso, não se preocupe; também confunde a maioria dos programas de recompensa de bugs.”

Em outras palavras, mesmo que um invasor não consiga modificar um fluxo de trabalho diretamente, ele poderá modificar um script externo chamado por esse fluxo de trabalho e obter seu código malicioso dessa forma. Repositórios e fluxos de trabalho de CI/CD podem se tornar bastante complexos com muitas interdependências, portanto, esses pequenos descuidos não são incomuns.

Mesmo sem os PATs, o GITHUB_TOKEN sozinho com privilégios de gravação teria sido suficiente para envenenar os lançamentos do PyTorch no GitHub e as chaves AWS extraídas separadamente poderiam ter sido usadas para backdoor de lançamentos do PyTorch hospedados na conta AWS da organização. “Havia outros conjuntos de chaves AWS, PATs do GitHub e várias credenciais que poderíamos ter roubado, mas acreditávamos que tínhamos uma demonstração clara de impacto neste momento”, disseram os pesquisadores. “Dada a natureza crítica da vulnerabilidade, queríamos enviar o relatório o mais rápido possível, antes que um dos 3.500 colaboradores do PyTorch decidisse fazer um acordo com um adversário estrangeiro.”

Mitigação de riscos de fluxos de trabalho de CI/CD

Há muitas lições a aprender com esse ataque para organizações de desenvolvimento de software: desde os riscos associados à execução de executores GitHub Actions auto-hospedados em configurações padrão até os riscos de ter fluxos de trabalho que executam scripts de fora do diretório de fluxos de trabalho até os riscos associados a tokens de acesso com privilégios excessivos e aplicativos legítimos reaproveitados como trojans — outros pesquisadores fizeram isso antes com Amazoncom o agente AWS System Manager e com o SSO do Google e a solução de gerenciamento de dispositivos para Windows.

“Garantir e proteger os executores é responsabilidade dos usuários finais, não do GitHub, e é por isso que o GitHub não recomenda o uso de executores auto-hospedados em repositórios públicos”, disse Stawinski. “Aparentemente, nem todo mundo ouve o GitHub, incluindo o GitHub.”

No entanto, se forem necessários executores auto-hospedados, as organizações devem, no mínimo, considerar alterar a configuração padrão de “Exigir aprovação para colaboradores iniciantes” para “Exigir aprovação para todos os colaboradores externos”. Também é uma boa ideia tornar os executores auto-hospedados efêmeros e executar fluxos de trabalho de PRs de fork apenas em executores hospedados no GitHub.

Esta não é a primeira vez que o uso inseguro dos recursos do GitHub Actions gera riscos de segurança na cadeia de suprimentos de software. Outros serviços e plataformas de CI/CD também tiveram suas próprias vulnerabilidades e configurações padrão inseguras. “Os problemas que envolvem essas rotas de ataque não são exclusivos do PyTorch”, disseram os pesquisadores. “Eles não são exclusivos dos repositórios de ML ou mesmo do GitHub. Demonstramos repetidamente os pontos fracos da cadeia de suprimentos ao explorar vulnerabilidades de CI/CD nas organizações tecnológicas mais avançadas do mundo em diversas plataformas de CI/CD, e essas são apenas um pequeno subconjunto da maior superfície de ataque.”

Roberto Magalhães

O cérebro editor por trás do Tecnologico.online, é um entusiasta apaixonado por tecnologia. Canaliza sua fascinação para criar conteúdo envolvente e informativo. Sua dedicação à inovação reflete-se nos artigos que produz, abrangendo uma ampla gama de tópicos tecnológicos. Com um olhar atento para as últimas tendências e desenvolvimentos, busca tornar...

Voltar para o blog

Deixe um comentário

Os comentários precisam ser aprovados antes da publicação.