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

Views: 371
0 0
Read Time:6 Minute, 15 Second

Um hacker usando o nome “Pl0xP” clonou um grande número de repositórios do GitHub e alterou ligeiramente os nomes dos repositórios clonados, em um esforço de digitação para representar projetos legítimos – potencialmente infectando qualquer software que importou o código, disseram especialistas em software hoje.

A clonagem generalizada resultou em mais de 35.000 inserções de um URL malicioso 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 um post no Twitter no início da manhã. O ataque, uma variante da  confusão de dependências , pode ter causado problemas para os desenvolvedores que usam os 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, de acordo com Lacy. “Este ataque enviará todo o ENV do script, aplicativo, laptop (aplicativos eletrônicos) para o servidor do invasor! Os 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 o exploit 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 “bifurcação” – não é uma nova técnica maliciosa, mas é complicada.

“Os maus atores 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 se tornar 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 uma impressão enganosa de que commits mais recentes também foram feitos pelos autores do projeto original. Commits de código-fonte aberto assinados com As chaves GPG de autores de projetos autênticos são uma maneira de verificar a autenticidade do código.”

“Isso… foi semelhante a alguém levantando um site ‘falso’ ou enviando um e-mail de phishing”, acrescenta Mark Lambert, vice-presidente de produtos da ArmorCode. “Isso vai pegar as 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 problema posicionou o typosquatting generalizado como um esforço de pesquisa legítimo.

“Este é um mero esforço de recompensa por bugs. nenhum dano feito. O relatório será divulgado”, um  usuário do Twitter chamado “pl0x_plox_chiken_p0x” twittou 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 havia registrado a conta apenas nos três dias anteriores – tempos de vida curtos da conta geralmente são 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, pois a atividade tem as características de uma intenção maliciosa”, disse Jossef Harush, chefe de engenharia de segurança da cadeia de suprimentos da empresa de segurança de software Checkmarx, à Dark Leitura.

De qualquer forma, Michael Skelton, diretor sênior de operações de segurança da plataforma 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 de bugs do Pl0xP (como a engenharia social está fora do escopo de quase todos os programas de recompensas de bugs), parece que eles clonaram vários repositórios e fizeram suas alterações nesses clones apenas – em nenhum caso essa mudança chegou aos repositórios originais que haviam sido 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 de volta (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 pesquisa 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 suprimentos de software aumentou 650% em 2021 , principalmente devido a 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 desejada ou componente, ou não percebendo a pequena diferença de nomenclatura. 

A propagação de repositórios com projetos mal-intencionados e com nomes incorretos 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 de desenvolvedor falsas no GitHub,  completas 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 “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 da contribuição”, acrescenta.

Não confie, verifique

Para evitar que seus projetos sejam envenenados, mantenedores e desenvolvedores devem confiar apenas naqueles contribuidores que são conhecidos por eles e têm um histórico de commits extenso e verificável. Eles também devem usar as ferramentas disponíveis – como assinaturas digitais e autenticação multifator – 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 são legítimos, [então] eles o usam em seus computadores de desenvolvimento locais, ambientes de construção, ambientes de produção e até mesmo software de construção, [até finalmente executar algo malicioso] nos clientes [ sistemas].”

No comunicado de julho da Checkmarx sobre falsificação de informações de identidade e informações de commit no utilitário de linha de comando git , a empresa destacou os riscos para projetos de software quando committers maliciosos se disfarçam de contribuidores conhecidos. Isso “faz com que o projeto pareça confiável”, afirmou a empresa . “O que torna essa falsificação de confirmação ainda mais alarmante é o fato de que o usuário 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 seu contribuidor, afirmou a Checkmarx.

No mínimo, desenvolvedores e mantenedores de projetos devem ocasionalmente revisar seu log de commits e pedir a seus outros mantenedores para habilitar commits assinados por GPG, diz Harush. “Acostumar-se a ter um log de confirmação assinado beneficiará você a prestar atenção às contribuições não verificadas.”

O GitHub não pôde ser encontrado imediatamente para comentar.

FONTE: DARK READING

POSTS RELACIONADOS