Ataques à Cadeia de Fornecimento: O Que Perguntar ao Seu Programador

A maioria dos sites e aplicações de empresas é construída sobre centenas de pequenos pacotes open-source escritos por desconhecidos. No ano passado, um grupo de hackers chamado TeamPCP transformou este facto numa arma: infetou software open-source amplamente usado com malware, roubou contas de programadores e usou essas contas para infetar mais software, repetidamente. Segundo a Ars Technica, a equipa de informação sobre ameaças da Google teve um analista infiltrado no núcleo do grupo durante meses, e dois australianos, ambos na casa dos vinte anos, foram detidos e acusados no mês passado como alegados participantes-chave.

O que aconteceu, de facto

O grupo comprometeu uma cadeia de ferramentas de programação conhecidas, entre elas o scanner de segurança Trivy, a ferramenta de API de IA LiteLLM, a biblioteca web TanStack, infraestrutura da empresa de segurança Checkmarx e a plataforma de IA Mistral AI. Cada compromisso dava aos atacantes mais credenciais de programadores, que usavam para infetar a ferramenta seguinte. Em certos momentos, chegaram a correr um worm autopropagável, chamado Mini Shai-Hulud em homenagem aos vermes-de-areia de Duna, para automatizar o ciclo.

O resultado: mais de mil empresas violadas, incluindo o repositório de código GitHub, a empresa de contratação de dados Mercor, e dispositivos de funcionários da OpenAI e da Comissão Europeia. A polícia australiana estimou o saque em mais de meio milhão de credenciais de utilizadores. Curiosamente, o grupo teve dificuldade em rentabilizar tudo isto — o investigador da Google estima apenas dezenas de milhares de dólares em pagamentos de extorsão — pelo que se associou a outro grupo, ShinyHunters, que depois usou as credenciais roubadas por conta própria. O analista da Google teve acesso ao servidor que armazenava as credenciais roubadas, e a empresa contactou fornecedores como a Amazon Web Services e a Microsoft para as revogar antes de poderem ser usadas.

Há mais um pormenor a reter: alguém no grupo usou uma ferramenta de IA para construir um exploit de dia zero que contornava a autenticação de dois fatores num software de início de sessão amplamente utilizado. A Google obteve o código, confirmou que funcionava com pequenas alterações, e avisou o programador, que corrigiu a falha.

Porque é que isto chega ao seu negócio

Não é preciso ser uma empresa tecnológica para estar dentro do raio de impacto. Se o seu site, loja ou aplicação móvel é construído com ferramentas modernas, o seu programador importa pacotes de código de terceiros, e esses pacotes importam ainda mais. Um único pacote infetado nessa cadeia corre com as mesmas permissões que o resto do seu código. Pode ler discretamente tudo o que o seu servidor conseguir ler: registos de clientes, dados de encomendas, chaves de fornecedores de pagamento, tokens de CRM.

O segundo caminho é o das contas. Grande parte desta campanha assentou em credenciais e tokens de acesso roubados a programadores, não em exploits engenhosos contra as próprias vítimas. Se a pessoa ou agência que construiu o seu site guarda uma palavra-passe de alojamento, uma chave de base de dados e um token de fornecedor de pagamento numa conversa de chat ou num portátil pessoal, essa é a sua exposição, não a deles. E o pormenor da autenticação de dois fatores é importante: um segundo fator continua a valer a pena, mas não é uma garantia.

Perguntas a fazer ao seu programador este mês

• Temos uma lista do que o nosso projeto depende? Peça o ficheiro de dependências e o lockfile, e pergunte se os pacotes de terceiros estão fixados em versões específicas em vez de se atualizarem automaticamente para o que foi publicado na noite anterior.
• Quem detém que credenciais, e onde? Alojamento, domínio, base de dados, fornecedor de pagamento, CRM, APIs de mensagens. Peça uma lista escrita das contas, quem tem acesso, e onde os segredos são guardados. Uma conversa de chat partilhada não é armazenamento.
• As contas de programadores e administradores estão protegidas com autenticação de dois fatores, e conseguimos revogar o acesso numa hora? Inclua ex-colaboradores e qualquer pessoa que tenha saído do projeto.
• O que acontece quando um pacote que usamos é reportado como comprometido? Pergunte quem monitoriza esses avisos e com que rapidez sai uma correção. "Ninguém, atualmente" é uma resposta válida e útil.
• Os nossos segredos de produção estão separados dos de teste, e com que frequência são rodados? Tokens que nunca mudam são tokens que continuam úteis a quem os rouba.

A versão calma da lição

Esta campanha terminou com detenções, um infiltrado dentro do grupo, e um grupo parceiro a trair outro. É um bom desfecho, mas foi sorte sobreposta a trabalho competente, e isso não se repete facilmente com o próximo grupo. O que funciona sempre é a higiene aborrecida: saber de que código depende, saber quem detém as suas chaves, e conseguir revogar o acesso rapidamente. Faça as cinco perguntas acima. Se o seu programador responder com clareza, está em melhor posição do que a maioria das mais de mil empresas apanhadas neste caso.