Dezenas de milhares de repositórios públicos do GitHub estão vulneráveis à injeção de código malicioso por meio dos chamados executores auto-hospedados do GitHub Actions, o que pode levar a ataques de alto impacto à cadeia de suprimentos de inúmeras empresas, alertam pesquisadores de segurança. O motivo é que muitos usuários/ desenvolvedores costumam hospedar seus próprios executores e personalizar o ambiente usado para executar trabalhos nos seus fluxos de trabalho no GitHub Actions.
Essa nova classe de ataques a fluxos de trabalhos CI/CD (integração contínua/entrega contínua) pode ser lançada se um repositório tiver executores auto-hospedados anexados. “Esses são agentes de construção hospedados por usuários finais que executam o agente executor Actions em sua própria infraestrutura”, explica o pesquisador de segurança da Praetorian, Adnan Khan.
Um executor auto-hospedado anexado a um repositório pode ser usado por qualquer fluxo de trabalho em execução no contexto desse repositório, e isso também se aplica a fluxos de trabalho de solicitações pull de fork, que podem executar código malicioso, representando assim um grande risco de segurança. “Ao alterar um arquivo de fluxo de trabalho em seu fork e, em seguida, criar uma solicitação pull, qualquer pessoa com uma conta no GitHub pode executar código arbitrário em um executor auto-hospedado”, observa Khan.
Além disso, alerta o pesquisador, os executores auto-hospedados configurados seguindo as etapas padrão são persistentes, o que significa que um processo pode ser executado em segundo plano mesmo após a conclusão do trabalho, abrindo assim a porta para a implantação de um mecanismo de persistência de acesso. Um invasor pode verificar a presença de uma ação específica do GitHub e de uma mensagem nos logs de execução e, se o nome do executor for repetido, determinar se um executor é persistente ou não.
De acordo com o pesquisador, um invasor que descobre um repositório de interesse pode então verificar se ele possui um executor auto-hospedado anexado e usar uma solicitação pull de fork para se tornar um contribuidor desse repositório, o que permitiria executar fluxos de trabalho no corredor sem exigir aprovação.
Para isso, o invasor pode encontrar um erro de digitação ou uma pequena alteração no código, criar uma solicitação pull de fork para ele e esperar até que a requisição seja mesclada, o que tornaria sua conta um contribuidor do repositório de destino.
Se o requisito padrão de aprovação da solicitação pull de fork estiver em vigor para o repositório, apenas a primeira solicitação do invasor exigiria aprovação, o que significa que o invasor seria capaz de executar o código no executor e configurar a persistência sem levantar suspeitas.
Usando esse fluxo de ataque, Khan conseguiu obter acesso persistente ao próprio repositório de ações/imagens de executores do GitHub, que contém fluxos de trabalho para construir imagens de executores do Windows e MacOS, permitindo ao pesquisador envenenar essas imagens.
O pesquisador diz que teve acesso ao repositório por cinco dias, a partir de 18 de julho de 2023. Ele relatou o problema ao GitHub em 22 de julho e as primeiras mitigações foram implantadas em 25 de julho. “Um invasor habilidoso poderia descartar uma carga útil que verificasse se a imagem estava processando um fluxo de trabalho para uma organização-alvo de alto valor e só então executar um segundo estágio para realizar um ataque de execução de pipeline envenenado no ambiente de construção do GitHub”, observa Khan.
Depois de relatar a vulnerabilidade ao GitHub, Khan começou a trabalhar com seu colega John Stawinski para identificar outros repositórios que poderiam ser vítimas do ataque e descobriu dezenas de milhares deles no GitHub.
Os pesquisadores limitaram a investigação a repositórios pertencentes a organizações que pagariam altas recompensas por meio de seus programas de recompensas por bugs e “enviaram mais de 20 relatórios de recompensas por bugs, arrecadando centenas de milhares de dólares em recompensas”, diz Stawinski.
No entanto, eles também investigaram vários outros meios de explorar GitHub Actions e expandiram a pesquisa para outras plataformas de integração contínua e entrega contínua (CI/CD), incluindo Buildkite, Jenkins e CircleCI.
“Nossos alvos incluíam as empresas de tecnologia mais avançadas do mundo, muitas vezes no espaço AI/ML ou Web3. Essas empresas investiram centenas de milhares de dólares em segurança e apresentam alguns dos programas de recompensa de bugs mais bem financiados. Mesmo assim, eles não sabiam desses novos ataques”, observa o pesquisador.
Os pesquisadores descobriram que poderiam comprometer as versões PyTorch e Microsoft Deepspeed, comprometer um aplicativo CloudFlare, fazer backdoor em vários blockchains, obter execução remota de código em uma máquina Microsoft associada ao domínio e fornecer etapas explícitas para comprometer as versões do TensorFlow.
Veja isso
Cryptojacker rouba credenciais da AWS no GitHub em 5 minutos
Repositórios do GitHub assolados por roubo de informações
“Quando operamos contra o PyTorch, poderíamos ter adicionado nosso próprio código malicioso aos seus lançamentos em quase todas as suas plataformas de lançamento. […] Nas mãos de um Estado-nação, este único ataque pode ser devastador. Na verdade, muitos desses ataques podem ter causado sua própria versão do SolarWinds ou o recente hack de criptografia do Ledger”, observa Stawinski.
Para mitigar esta classe de vulnerabilidade, as organizações são aconselhadas a alterar as configurações padrão do repositório para que todas as contribuições externas exijam aprovação. “É óbvio para qualquer repositório público que usa executores auto-hospedados garantir que eles estejam usando a configuração restritiva”, observa Khan.
Para ter acesso ao artigo completo, em inglês, sobre injeção de código malicioso por meio dos chamados executores auto-hospedados do GitHub basta acessar o blog do pesquisador de segurança Adnan Khan clicando aqui.
