OVHcloud CLI releases compromised by secret stealing malware

OVHcloud CLI releases compromised by secret stealing malware

Um atacante sequestrou uma conta de contribuidor do GitHub e substituiu os arquivos baixáveis de cinco lançamentos existentes da ferramenta de linha de comando OVHcloud em 19 de outubro. O código malicioso era uma compilação em Go projetada para roubar segredos armazenados no disco de qualquer máquina que a executasse, segundo o provedor de nuvem.

Os arquivos alterados estiveram disponíveis no GitHub por até 94 minutos, das 12:47 às 14:21 UTC, e afetaram apenas usuários que instalaram ou atualizaram o OVHcloud CLI durante esse intervalo, em sistemas macOS, Linux x86_64 ou arm64, ou Windows x86_64, sem verificação de hash.

A OVHcloud removeu os arquivos alterados e publicou uma versão limpa v0.16.0 naquela noite como um lançamento imutável, que o GitHub impede que seja modificado no futuro. O código-fonte, a tag de lançamento e o pipeline de compilação da empresa permaneceram intactos. O build malicioso era uma simples compilação Go de um commit posterior, enviada diretamente para os lançamentos publicados entre abril e setembro.

No v0.15.0, o invasor substituiu seis arquivos: os arquivos macOS x86_64 e arm64, os arquivos Linux x86_64 e arm64, o arquivo Windows x86_64 e o checksums.txt, de modo que os hashes publicados correspondiam aos novos binários. Os mesmos seis arquivos desapareceram também das versões v0.11.0 a v0.14.0. As compilações para Linux i386, Windows i386, Windows arm64 e WebAssembly permaneceram inalteradas em todos os lançamentos.

A OVHcloud listou as versões v0.11.0 a v0.15.0 como comprometidas e a v0.10.0 como limpa. Esses cinco lançamentos foram publicados entre 14 de abril e 16 de setembro, portanto uma cópia instalada antes das 12:47 UTC na segunda-feira e não atualizada desde então permanece como a versão original.

Um cliente que detectou a substituição extraiu informações de compilação do binário v0.15.0 Linux arm64 com o comando go version -m, que lê o arquivo sem executá-lo, e publicou os detalhes em um problema do GitHub. Três características marcaram o build malicioso: a presença de um sufixo +dirty, a flag vcs.modified=true e o commit de origem.

Conselhos circulando de que qualquer compilação marcada como +dirty ou contendo linhas vcs é a versão maliciosa apontariam para o próprio lançamento da OVHcloud. The Hacker News executou o mesmo comando no binário limpo v0.16.0 Linux x86_64: ele relatou v0.16.0+dirty, vcs.modified=true e o commit de origem.

Somente o hash publicado de um arquivo trocado corresponde ao arquivo Linux arm64 v0.15.0. Uma compilação sem a flag de versão relataria sua versão como indefinida, mas executar um binário suspeito para descobrir isso não é aconselhável.

Octave Klaba, fundador da OVHcloud, postou na plataforma X na noite de segunda-feira que qualquer pessoa afetada deveria alterar todas as credenciais armazenadas no disco. A CLI OVHcloud armazena credenciais da API em ~/.ovh.conf e as lê a partir de variáveis de ambiente, segundo a documentação, e o alerta cobriu tudo mais no disco, não apenas esses arquivos.

A OVHcloud não divulgou quais arquivos o binário lê, para onde os envia ou quantas cópias foram baixadas, e nenhuma cópia do arquivo trocado foi analisada publicamente. A empresa prometeu um relatório detalhado nos próximos dias.

Qualquer pessoa com direitos de escrita em um repositório do GitHub pode deletar os arquivos anexados a um lançamento e carregar novos arquivos com os mesmos nomes, e a URL de download não muda a menos que a imutabilidade do lançamento esteja ativada. A configuração, geralmente disponível desde outubro de 2025, bloqueia os arquivos e a tag de um lançamento, mas protege apenas lançamentos criados após a ativação.

A OVHcloud não havia ativado essa configuração. Em uma segunda postagem na noite de segunda-feira, citada pela Next, Klaba escreveu que o problema surgiu porque a opção de imutabilidade não estava ativada, permitindo que um usuário com permissões adequadas modificasse lançamentos existentes diretamente no GitHub sem verificações do pipeline CI/CD da empresa. A opção agora foi ativada e os próprios pipelines não foram afetados.

Os cinco lançamentos antigos agora oferecem apenas os quatro arquivos que o invasor não tocou.

Com informações de: The Hacker News (THN)