Mais de 100 mil repositórios infectados encontrados no GitHub

Mais de 100.000 repositórios infectados encontrados no GitHub

• Uma equipe de pesquisa em segurança e ciência de dados detectou o ressurgimento em grande escala de uma campanha maliciosa de confusão de repositórios que começou em meados do ano passado.
• Esse ataque afeta mais de 100.000 repositórios no GitHub (e, ao que tudo indica, milhões no total) quando desenvolvedores usam repositórios que parecem semelhantes a repositórios conhecidos e confiáveis, mas que na verdade contêm código malicioso.

Como acontece um ataque de confusão de repositórios?

• O ataque de confusão de repositórios é semelhante ao ataque de confusão de dependências, no qual agentes maliciosos fazem com que o alvo baixe uma versão maliciosa em vez da versão legítima.
• Enquanto o ataque de confusão de dependências explora o funcionamento do gerenciador de pacotes, o ataque de confusão de repositórios depende de as pessoas escolherem por engano a versão maliciosa no lugar da versão legítima e, às vezes, também usa técnicas de engenharia social.

O que acontece quando um repositório malicioso é usado

• Quando desenvolvedores usam sem suspeitar um repositório malicioso, um payload oculto desfaz sete etapas de ofuscação e busca código Python malicioso e, em seguida, executáveis binários.
• O código malicioso coleta credenciais de login de vários apps, senhas e cookies de navegadores, além de outros dados confidenciais, enviando tudo para o servidor de C&C do agente malicioso e realizando atividades maliciosas adicionais.

Impacto da automação no GitHub

• A maioria dos repositórios com fork é removida rapidamente pelo GitHub, mas a detecção automatizada deixa muitos passarem, e os repositórios enviados manualmente sobrevivem.
• Como toda a cadeia de ataque é em grande parte automatizada em escala, o 1% que sobrevive ainda representa milhares de repositórios maliciosos.

Quando a campanha começou

• Maio de 2023: segundo relatório inicial da Phylum, vários pacotes maliciosos contendo a parte inicial do payload atual foram enviados ao PyPI.
• Julho - agosto de 2023: depois que o PyPI removeu os pacotes maliciosos e a comunidade de segurança passou a prestar mais atenção nisso, vários repositórios maliciosos foram enviados ao GitHub, desta vez entregando o payload diretamente em vez de buscar pacotes do PyPI.
• Novembro de 2023 - atualmente: mais de 100.000 repositórios contendo payloads maliciosos semelhantes foram detectados, e esse número continua crescendo.

Mudança do malware de gerenciadores de pacotes para gerenciamento de código-fonte (SCM)

• A partir de muitos incidentes observados em gerenciadores de pacotes e plataformas de SCM, essa campanha parece refletir uma tendência mais ampla: a migração de pacotes maliciosos no PyPI para repositórios maliciosos no GitHub.

Como se proteger contra a confusão de repositórios

• O GitHub foi informado e a maior parte dos repositórios maliciosos foi excluída, mas a campanha continua, e ataques que tentam injetar código malicioso na cadeia de suprimentos estão se tornando cada vez mais comuns.
• A Apiiro criou um sistema de detecção de malware para monitorar codebases conectadas.
• Para detectar os ataques, ela usa várias técnicas avançadas, incluindo análise de código baseada em LLM, decomposição do código em um grafo completo de fluxo de execução, um mecanismo sofisticado de heurísticas, decodificação dinâmica, descriptografia e desofuscação.

Opinião do GN⁺

• Este artigo fornece informações importantes para alertar desenvolvedores sobre ameaças de segurança às quais devem estar atentos ao usar repositórios do GitHub.
• Ao entender como o código malicioso penetra na cadeia de suprimentos de software, desenvolvedores e profissionais de segurança podem construir mecanismos de defesa mais robustos.
• Esses ataques destacam não apenas a capacidade dos desenvolvedores de escolher repositórios confiáveis, mas também a dependência da precisão das configurações de CI/CD e da segurança de código de terceiros.
• Sob uma perspectiva crítica, esses ataques mostram que os sistemas automatizados de plataformas como o GitHub e a existência de repositórios em grande escala podem ser uma faca de dois gumes.
• Ferramentas de segurança com funções semelhantes incluem SonarQube, Snyk e WhiteSource, que podem ajudar a detectar vulnerabilidades no código e fortalecer a segurança.
• Antes de adotar essa tecnologia, é preciso considerar a compatibilidade com a política de segurança da organização, o custo de implementação e a capacidade técnica da equipe.
• Os benefícios de escolher essa tecnologia incluem o fortalecimento da segurança e a redução de riscos, mas possíveis desvantagens incluem a curva de aprendizado de um novo sistema e a complexidade de sua gestão.

[GN⁺]

Comentários do Hacker News

• É preciso ter cuidado ao obter código de repositórios públicos, e é importante verificar a árvore de dependências. Isso levanta a questão de como malwares em repositórios públicos podem afetar ferramentas automatizadas como modelos de linguagem grandes (Large Language Models, LLMs). Por exemplo, ferramentas como o GitHub Copilot podem acabar incluindo malware por engano em respostas a perguntas de programação.
• Aponta-se que o GitHub está falhando da mesma forma que a Usenet falhou. Qualquer pessoa pode criar um repositório no GitHub, e não há uma forma de distinguir entre repositórios oficiais e repositórios de spammers. Quando a Amazon busca ser a "loja que vende de tudo", ela enfrenta o problema de que a maior parte dos produtos é lixo. O GitHub precisa definir sua identidade: é um "repositório para todos" ou a pergunta central é "posso confiar neste código"?
• Há um desabafo sobre a gravidade do problema da cadeia de suprimentos. Embora não esteja focado em releases do npm, usa-se o socket.dev para monitorar projetos. O projeto BrowserBox usa cerca de 800 dependências, das quais 19 são dependências de topo. Está sendo considerada uma forma de fazer snapshot de todas as dependências no namespace @browserbox do npm para rastrear e corrigir vulnerabilidades.
• Enfatiza-se que desenvolvedores devem separar pelo menos três ambientes: trabalho, hobby e uso pessoal. Mesmo com repositórios e proprietários confiáveis, é sensato executar código em uma máquina virtual com sandbox.
• No caso de desenvolver um SDK em uma equipe pequena que recebe muitos downloads semanais, estão sendo avaliadas soluções baseadas em snyk, aikido.dev e renovate. Não está claro se essas ferramentas vão ajudar a resolver o problema, e lidar com muitos falsos positivos, como ocorreu com o snyk, é difícil.
• Expressa-se a dúvida se a forma de instalação por shell script usando curl e sudo está perto do fim. Esse método está intimamente relacionado ao software infectado mencionado no artigo.
• No npm, é possível usar a opção --ignore-scripts para evitar a execução de malware.
• Menciona-se que houve um repositório com vírus do tipo trojan há menos de um ano.
• Critica-se o fato de uma postagem recente sobre problemas de segurança levar a um anúncio para financiar startups de LLM. Essas startups só conseguem resolver parte das lacunas de segurança, e firmar contratos com muitas startups pode gerar problemas de custo e integração.
• A segurança do ambiente de desenvolvimento está sendo melhorada gradualmente em resposta a relatórios contínuos de segurança. Estão sendo testados contêineres de desenvolvimento do VSCode, GitHub Codespaces, leitura das diretrizes da OWASP e revisão de pacotes npm/python com o socket.dev.