35 mil inserções de código malicioso no GitHub: ataque ou esforço de recompensa por bug?

Um hacker chamado “Pl0xP” clonou um grande número de repositórios GitHub e alterou ligeiramente os nomes dos repositórios clonados, em um esforço de typosquatting para se passar por projetos legítimos – potencialmente infectando qualquer software que importasse o código, disseram hoje especialistas em software.

A clonagem generalizada resultou em mais de 35,000 inserções de uma URL maliciosa em diferentes repositórios de código, embora o número exato de projetos de software afetados seja provavelmente muito menor, afirmou o engenheiro de software Stephen Lacy em uma postagem matinal no Twitter. O ataque, uma variante do confusão de dependência, poderia ter causado problemas para desenvolvedores que usam repositórios falsos do GitHub sem a verificação adequada da fonte do software, disse ele.

Se importado, o código malicioso executa código no sistema, segundo Lacy. “Este ataque enviará TODO o ENV do script, aplicativo, laptop (apps eletrônicos), para o servidor do invasor! ENVs incluem: Chaves de segurança; Chaves de acesso AWS; Chaves criptográficas… muito mais.” 

“ENVs” são variáveis ​​de ambiente, usadas para armazenar informações que os desenvolvedores desejam referenciar em seus fluxos de trabalho.

O engenheiro de software encontrou a funcionalidade maliciosa quando auditou uma biblioteca de software que considerou incorporar em seu próprio projeto, disse Lacy.

“Descobri a exploração enquanto revisava um projeto que encontrei em uma pesquisa no Google”, ele twittou. “É por isso que não instalamos pacotes aleatórios da Internet!”

A clonagem — ou “fork” — não é uma nova técnica maliciosa, mas é complicada.

“Atores mal-intencionados já eram conhecidos no passado por criar repositórios populares clonados/bifurcados com código malicioso”, diz Mor Weinberg, engenheiro de software da Aqua Security. “Isso pode ser bastante difícil de detectar, pois os repositórios clonados podem reter commits de código com nomes de usuário e endereços de e-mail dos autores originais, dando a impressão enganosa de que commits mais recentes também foram feitos pelos autores do projeto original. Os commits de código-fonte aberto assinados com chaves GPG de autores de projetos autênticos são uma forma de verificar a autenticidade do código.”

“Isso… era semelhante a alguém criando um site 'falso' ou enviando um e-mail de phishing”, acrescenta Mark Lambert, vice-presidente de produtos da ArmorCode. “Isso vai pegar pessoas que não estão prestando atenção.”

Um ataque ou pesquisa legítima?

Essa bifurcação em massa no GitHub pode não ter sido um ataque real. Uma pessoa que afirma ter conhecimento do assunto posicionou o typosquatting generalizado como um esforço de pesquisa legítimo.

“Este é um mero esforço de recompensa por bugs. Sem danos causados. O relatório será divulgado”, disse um Usuário do Twitter chamado “pl0x_plox_chiken_p0x” tuitou em 3 de agosto.

Embora um projeto de pesquisa mal concebido possa explicar o ataque, criar milhares de alterações de código para pesquisa parece irracionalmente arriscado. Além disso, o usuário do Twitter só registrou a conta nos três dias anteriores – a curta vida útil da conta costuma ser uma característica de personas online fraudulentas.

A alegação de que o ataque faz parte de uma recompensa por bugs “está esperando para ser comprovada, já que a atividade tem as características de alguém com intenções maliciosas”, disse Jossef Harush, chefe de engenharia de segurança da cadeia de suprimentos da empresa de segurança de software Checkmarx, ao Dark. Leitura.

De qualquer forma, Michael Skelton, diretor sênior de operações de segurança da plataforma de recompensas por bugs Bugcrowd, observa que pelo menos os repositórios de código originais permaneceram inalterados.

“Embora não esteja claro qual seria a natureza da descoberta de recompensas por bugs do Pl0xP (já que a engenharia social está fora do escopo de quase todos os programas de recompensas por bugs), parece que eles clonaram vários repositórios e fizeram alterações nesses clones. apenas – em nenhum caso essa mudança chegou aos repositórios originais que foram clonados”, diz ele. “Clonar um repositório é uma ação padrão que não afeta o repositório original, a menos que o proprietário mescle uma alteração (solicitada por meio de uma solicitação pull), o que não foi feito aqui.”

Abundam as dependências de software malicioso

O GitHub aparentemente limpou os commits de código malicioso e, na tarde de 3 de agosto, uma busca pelo URL incorreto incorporado não apresentou nenhum resultado. No entanto, o ataque não é a primeira vez que projetos de código aberto tiveram que lidar com invasores. O número de ataques contra a cadeia de fornecimento de software saltou 650% em 2021, impulsionados principalmente por ataques de confusão de dependência, em que o invasor usa uma versão com nome quase idêntico de um bloco de código-fonte aberto na esperança de que os desenvolvedores digitem incorretamente o nome de uma biblioteca ou componente desejado ou não percebam a ligeira diferença na nomenclatura. 

A propagação de repositórios com projetos maliciosos e mal nomeados exige que o invasor faça algum trabalho de base. Em julho, a empresa de segurança de software Checkmarx revelou uma maneira de criar contas falsas de desenvolvedor no GitHub, completo com um histórico ativo de commits de código para aumentar sua credibilidade. A técnica, juntamente com o ataque mais recente, ressalta que os mantenedores precisam tomar medidas para aceitar apenas commits de código assinados, diz Harush. Os desenvolvedores precisam “tomar cuidado com solicitações pull e contribuições com commits não verificados suspeitos, [e precisam] revisar… o conteúdo das contribuições em comparação com o aviso de isenção de responsabilidade na mensagem de commit e contribuições adicionando ou modificando dependências existentes para dependências nomeadas semelhantes como parte do contribuição”, acrescenta.

Não confie, verifique

Para evitar que seus projetos sejam envenenados, os mantenedores e desenvolvedores devem confiar apenas nos contribuidores que são conhecidos por eles e que possuem um histórico de commits extenso e verificável. Eles também devem usar as ferramentas disponíveis – como assinaturas digitais e autenticação multifatorial – para proteger suas contas, diz Harush.

“Como você não deve confiar em doces de estranhos – não confie em códigos de estranhos”, diz ele. “Os usuários podem ser enganados ao avaliar o projeto candidato e pensar que ele é legítimo, [então] eles o usam em seus computadores de desenvolvimento local, ambientes de construção, ambientes de produção e até mesmo construção de software, [até finalmente executar algo malicioso] nos clientes [ sistemas].”

No comunicado de julho da Checkmarx sobre falsificação de informações de identidade e confirmação de informações no git utilitário de linha de comando, a empresa ressaltou os riscos para projetos de software quando committers mal-intencionados se disfarçam como contribuidores conhecidos. Isso “faz com que o projeto pareça confiável” a empresa afirmou. “O que torna esse commit-spoofing ainda mais alarmante é o fato de que o usuário que está sendo falsificado não é notificado e não saberá que seu nome está sendo usado.”

O GitHub já adicionou assinaturas digitais para commits de código para verificar a identidade do contribuidor, mas os mantenedores do projeto devem habilitar o “modo vigilante”, um recurso do GitHub que exibe detalhes do status de verificação de cada commit e de seu contribuidor, afirmou Checkmarx.

No mínimo, os desenvolvedores e mantenedores de projetos devem ocasionalmente revisar seu log de commits e pedir aos outros mantenedores que habilitem commits assinados por GPG, diz Harush. “Acostumar-se a ter um log de commit assinado irá beneficiá-lo para prestar atenção às contribuições não verificadas.”

Não foi possível entrar em contato imediatamente com o GitHub para comentar.