A maior parte das ações maliciosas ocorreu durante um intervalo de 43 minutos no dia 1° de setembro. De acordo com o levantamento divulgado pelo veículo The Register nesta quinta-feira (29), 67 itens maliciosos foram publicados durante o período, e outros seis surgiram logo depois.

O método adotado pelos criminosos chamou a atenção dos pesquisadores pela novidade e pela automação. Os atacantes publicavam problemas, solicitações de extração ou comentários contendo comandos maliciosos escondidos em marcações de comentários em HTML, o que impedia que o conteúdo ficasse visível na página principal.

Assim, sempre que um repositório tinha uma brecha de segurança, o sistema do GitHub rodava o comando escondido sem que ninguém percebesse. Essa ação permitia roubar informações importantes de acesso e enviá-las para os computadores dos cibercriminosos.

O vice-presidente e pesquisador da Radware, Gabi Nakibly, explicou que “o fluxo de trabalho é acionado automaticamente em um segundo e, se o fluxo for realmente vulnerável, o ataque é executado com sucesso”.

O especialista acrescentou, em entrevista ao The Register, que o objetivo final consistia em obter credenciais para alterar o código dos repositórios : “Nosso palpite é que o objetivo final era um ataque à cadeia de suprimentos em que o invasor ganha credenciais para o repositório e, então, tem o poder de alterar o conteúdo, o código, como desejar”.

Entre os projetos afetados estão nomes conhecidos no mercado de tecnologia, como Google LangExtract, Trivy, navegador Brave, MLflow e a ferramenta Podman. Zvika Babo, outro pesquisador envolvido na instituição, destacou que qualquer pessoa com uma conta na plataforma conseguia tentar a investida. “Basicamente, qualquer usuário com uma conta no GitHub pode tentar executar este ataque, e é muito fácil iniciá-lo”, declarou.

As equipes de desenvolvimento precisam redobrar os cuidados com a segurança dos fluxos de automação. Para Babo, os desenvolvedores devem tratar conteúdos externos como fontes não confiáveis e restringir o acesso a segredos e variáveis sensíveis. Em contrapartida, Gabi Nakibly concluiu que a única forma de defesa consiste em garantir que o código dos fluxos de trabalho seja resistente e imune a esse tipo de falha.