Descobertas de configurações de integração contínua e entrega contínua (CI/CD) no framework de aprendizado de máquina de código aberto TensorFlow poderiam ter sido exploradas para orquestrar ataques à cadeia de suprimentos.
As configurações poderiam ser abusadas por um invasor para "realizar um comprometimento da cadeia de suprimentos dos lançamentos do TensorFlow no GitHub e no PyPi, comprometendo os agentes de construção do TensorFlow via um pull request malicioso", disseram os pesquisadores da Praetorian, Adnan Khan e John Stawinski, em um relatório publicado esta semana.
A exploração bem-sucedida dessas questões poderia permitir a um invasor externo carregar lançamentos maliciosos no repositório do GitHub, obter execução remota de código no próprio corredor do GitHub e até mesmo recuperar um Token de Acesso Pessoal (PAT) do GitHub para o usuário tensorflow-jenkins.
O TensorFlow usa o GitHub Actions para automatizar a construção do software, teste e pipeline de implantação.
Runners, que se referem a máquinas que executam trabalhos em um fluxo de trabalho do GitHub Actions, podem ser auto-hospedados ou hospedados pelo GitHub.
"Recomendamos que você use apenas runners auto-hospedados com repositórios privados", observa o GitHub em sua documentação.
"Isso ocorre porque os forks do seu repositório público podem potencialmente executar código perigoso na sua máquina runner auto-hospedada, criando um pull request que executa o código em um fluxo de trabalho."
Em outras palavras, isso permite que qualquer contribuidor execute código arbitrário no runner auto-hospedado, enviando um pull request malicioso.
No entanto, isso não representa nenhuma preocupação de segurança com runners hospedados no GitHub, pois cada runner é efêmero e é uma máquina virtual limpa e isolada que é destruída no final da execução do trabalho.
A Praetorian disse que foi capaz de identificar fluxos de trabalho do TensorFlow que foram executados em runners auto-hospedados, encontrando posteriormente fork pull requests de colaboradores anteriores que acionaram automaticamente os fluxos de trabalho CI/CD apropriados sem necessidade de aprovação.
Um adversário procurando trojanizar um repositório alvo poderia, portanto, corrigir um erro de digitação ou fazer uma pequena mudança de código legítimo, criar um pull request para isso e, em seguida, esperar até que o pull request seja mesclado para se tornar um colaborador.
Isso permitiria que eles executassem código no runner sem levantar qualquer bandeira vermelha, criando um pull request fraudulento.
Um exame adicional dos logs de fluxo de trabalho revelou que o runner auto-hospedado não era apenas não efêmero (abrindo assim a porta para persistência), mas também que as permissões do GITHUB_TOKEN associadas ao fluxo de trabalho possuíam extensas permissões de gravação.
"Porque o GITHUB_TOKEN tinha a permissão de conteúdo: gravação, ele poderia carregar lançamentos para https://github[.]com/tensorflow/tensorflow/releases/," apontaram os pesquisadores.
"Um invasor que comprometeu um desses GITHUB_TOKEN's poderia adicionar seus próprios arquivos aos Ativos de Lançamento."
Além disso, as permissões de conteúdo: gravação poderiam ser armadas para empurrar o código diretamente para o repositório TensorFlow, injetando secretamente o código malicioso em um branch de recurso e mesclando-o no branch principal.
Mas não é só isso.
Um ator de ameaça poderia roubar o AWS_PYPI_ACCOUNT_TOKEN usado no fluxo de trabalho de lançamento para autenticar-se no registro do Python Package Index (PyPI) e carregar um arquivo .whl Python malicioso, envenenando efetivamente o pacote.
"Um invasor também poderia usar as permissões do GITHUB_TOKEN para comprometer o segredo do repositório JENKINS_TOKEN, mesmo que este segredo não fosse usado nos fluxos de trabalho que rodam nos runners auto-hospedados," disseram os pesquisadores.
Após a divulgação responsável em 1º de agosto de 2023, as deficiências foram tratadas pelos mantenedores do projeto em 20 de dezembro de 2023, exigindo aprovação para fluxos de trabalho enviados de todos os fork pull requests, contando aqueles de colaboradores anteriores, e mudando as permissões do GITHUB_TOKEN para leitura apenas para fluxos de trabalho que rodam em runners auto-hospedados.
"Ataques de CI/CD similares estão em alta à medida que mais organizações automatizam seus processos CI/CD", disseram os pesquisadores.
"As empresas de AI/ML são particularmente vulneráveis, pois muitos de seus fluxos de trabalho requerem poder de computação significativo que não está disponível nos runners hospedados pelo GitHub, daí a prevalência de runners auto-hospedados."
A divulgação vem como ambos os pesquisadores revelaram que vários repositórios públicos do GitHub, incluindo aqueles associados à Chia Networks, Microsoft DeepSpeed e PyTorch, são suscetíveis à injeção de código malicioso por meio de runners de ações do GitHub auto-hospedados.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...