Você tem milhões de componentes de software de código aberto para escolher… assim como os cibercriminosos

Views: 642
0 0
Read Time:8 Minute, 38 Second

Em novembro de 2020, o registro JavaScript npm exibiu um aviso de segurança de que uma biblioteca chamada twilio-npm abrigava código malicioso que poderia backdoor qualquer máquina para a qual fosse baixado. Talvez o aspecto mais preocupante deste conto seja que este foi o sétimo pacote malicioso encontrado no npm dentro de um mês, uma ilustração gritante do esforço que os cibercriminosos estão fazendo para se inserir na cadeia de suprimentos de software de código aberto.

Entre fevereiro de 2015 e junho de 2019, 216 desses Ataques à Cadeia de Suprimentos de Software de Próxima Geração foram registrados, de acordo com o Relatório Estadual da Cadeia de Suprimentos de Software da Sonatype, 2020. De julho de 2019 a maio de 2020, o número disparou para 929. Os ataques aumentaram 430 por cento entre 2019 e 2020.

Algumas das técnicas dos atacantes permanecem surpreendentemente de baixa tecnologia. A abordagem mais comum, de acordo com o relatório, é a digitação, como no ataque de 2019 à biblioteca de utilitário Javascript Lodash, que simplesmente dependia de desenvolvedores digitando acidentalmente Lodahs. Isso os expôs a um pacote malicioso contendo malware para exfiltrar carteiras de criptomoedas.

Ataques mais perniciosos vêm na forma de roubar credenciais de um mantenedor de projeto ou contribuir com versões maliciosas de um projeto para um repositório ou pull requests com código malicioso. O ataque do Octopus Scanner em maio de 2020 malware sequestrou o Apache Netbeans IDE para se propagar, ou, como o GitHub explicou, “o malware prosseguiria para as compilações do projeto NetBeans backdoor“.

Ataques à cadeia de suprimentos de software não são novos, é claro. A violação mais notória dos últimos anos – o ataque dos Struts, que poleaxou a gigante do crédito Equifax, entre outros, em 2017 – caiu diretamente na categoria de ataque à cadeia de suprimentos de software. O que tornou a vulnerabilidade tão fatal, no caso da Equifax, foi a falha da empresa em atualizar a biblioteca de software de código aberto em tempo hábil.

Para muitos, os benefícios da construção de aplicações a partir de componentes OSS superam claramente os riscos. No entanto, o incidente Equifax ilustra vividamente como o uso crescente de software de código aberto pelos desenvolvedores pode introduzir vulnerabilidades de segurança e a necessidade de resposta rápida. Apenas 10% do aplicativo corporativo médio é construído internamente atualmente, diz Derek Weeks, vice-presidente e defensor do DevOps da Sonatype, e isso equivale essencialmente à cola que mantém uma matriz de componentes OSS juntos.

De acordo com Weeks, de 10% a 40% dos componentes de software de código aberto que os desenvolvedores estão baixando têm vulnerabilidades conhecidas. Isso cria uma enorme superfície de ataque potencial para os adversários – tudo o que eles precisam fazer é identificar os componentes específicos que seus alvos estão executando.

Portanto, é preocupante que apenas 17% das organizações estivessem cientes de novas vulnerabilidades em componentes de código aberto dentro de um dia após a divulgação, revela uma pesquisa com 679 desenvolvedores realizada para o Relatório de Estado da Cadeia de Suprimentos de Software da Sonatype 2020. Cerca de 35% levaram entre um dia e uma semana, enquanto o restante (48%) permaneceu na ignorância por pelo menos uma semana.

Quando se trata de tempo médio para corrigir tais problemas, o atraso dá aos atacantes muito tempo para montar ataques a vulnerabilidades recém-divulgadas em sistemas não corrigidos em tais ataques “legados” da cadeia de suprimentos de software.

Ataques de última geração à cadeia de suprimentos de software

Mas os criminosos cibernéticos estão olhando para o futuro sem remorsos. E à medida que procuram maneiras de serem ainda mais eficientes, é inevitável que eles dêem o salto de pensar “que componentes falhos posso explorar” para “e se eu pudesse criar um componente falho que todos baixariam?” Como Weeks coloca, os atacantes – sejam indivíduos, sindicatos ou estados-nação – estão percebendo: “Posso criar meus próprios dias zero”.

É claro que os criminosos cibernéticos leram e digeriram completamente os DevOps e os manuais de código aberto para realizar esses ataques de cadeia de suprimentos de software de próxima geração destinados ao código de projeto de software de código aberto.

Muitos dos fatores que tornam os componentes de software aberto o padrão para desenvolvedores de software corporativo também são fatores que os maus atores podem aproveitar. Grandes projetos de código aberto às vezes dependem de contribuições de centenas, potencialmente milhares de voluntários. E os próprios projetos de código aberto têm inúmeras dependências, todas as quais podem ter vulnerabilidades. Passando por tudo isso é o modelo de confiança compartilhada que é necessário para unir comunidades globais que trabalham em direção a um objetivo comum.

É fácil ver como um ator ruim pode se misturar à multidão, secretando silenciosamente código malicioso dentro das milhares de contribuições que compõem um pacote ou componente popular. O efeito multiplicador dos downloads OSS dentro de projetos populares significa que eles podem potencialmente fazer um retorno muito maior sobre seu investimento do que através dos métodos tradicionais de ataque. Quanto mais downloads um projeto recebe após a inserção de código malicioso, mais superfície de ataque disponível para exploração imediata.

Afinal, de acordo com as projeções do Relatório de Cadeia de Suprimentos do Estado do Software 2020 da Sonatype, os desenvolvedores solicitaram mais de 1,5 trilhão de componentes e contêineres de software de código aberto em 2020.

Apenas olhando para os pacotes npm, um estudo de 2019 realizado por pesquisadores da Universidade de Darmstadt descobriu que um pacote típico continha uma média de 79 pacotes de terceiros de 39 mantenedores diferentes. Além disso, os pesquisadores descobriram que essas complexas cadeias de dependência significavam que 391 colaboradores altamente influentes afetaram mais de 10.000 componentes.

Se você fosse um ator ruim, procurando se passar por outra pessoa, esses seriam seus principais alvos. Se você tiver acesso às 20 contas de mantenedores mais populares, poderá implantar código malicioso atingindo mais da metade do ecossistema npm, concluíram os pesquisadores de Darmstadt. Da mesma forma, o “alcance de pacotes” dos cinco principais pacotes estava entre 134.774 e 166.086 outros pacotes.

Enquanto isso, a Iniciativa de Infraestrutura Principal da Linux Foundation descobriu que sete dos 10 pacotes de software mais usados estavam hospedados em contas de desenvolvedor individuais. Assume o controle de tais contas para distribuir ataques pode significar caos a jusante nas cadeias de suprimentos de software.

Como vimos, muitas organizações lutam até mesmo para lidar com os problemas que a Equifax ilustrou há quase meia década. Como se espera que eles se protejam quando cada pacote OSS poderia potencialmente conter código malicioso?

Mantendo controle

Para as empresas, o primeiro passo para usar com segurança o código aberto é simplesmente deixar claro quais pacotes de código aberto seus desenvolvedores estão usando, diz Weeks.

“Se uma vulnerabilidade for anunciada hoje, sua primeira pergunta como equipe de desenvolvimento ou empresa é ‘eu já baixei esse pacote e o usei?’ Se a resposta for sim, sua próxima pergunta é ‘Onde está?’ Se você não fizer um inventário do que está usando, a ação resultante parece mais uma caça ao tesouro de meses do que uma resposta rápida e precisa.’”

A segunda parte, diz ele, é garantir que a organização tenha um sistema para avaliar se o que você está usando é bom ou ruim. Fundamentalmente, isso tem que ser feito onde importa, e isso não está dentro da equipe de segurança ou governança. Em vez disso, ele tem que encontrar seu caminho para as ferramentas e ambientes que estão sendo usados pelos desenvolvedores. “As únicas pessoas em sua organização que estão baixando código-fonte aberto são desenvolvedores”, diz Weeks.

Então, são os desenvolvedores que precisam ser encorajados e capacitados a fazer a pergunta: “Os componentes que estou usando são bons ou ruins?” Mas onde eles encontram as respostas?

Pacote de Desenvolvimento Avançado

Como Weeks explica, os desenvolvedores historicamente compartilharam informações sobre quais pacotes usar de boca em boca. Mas essa não é uma maneira robusta de comparar as implicações de qualidade e segurança de diferentes pacotes – especialmente quando qualquer organização baixa mais de 300.000 componentes de código aberto anualmente.

Este é o problema que a Sonatype tem como alvo com seu Pacote de Desenvolvimento Avançado, que aproveita a inteligência artificial e o aprendizado de máquina para descobrir sinais de alerta sobre projetos de código aberto.

“O que realmente nos propomos a fazer há alguns anos foi pesquisar quem são os fornecedores de melhor qualidade”, diz Weeks, “Quantos downloads um projeto teve? Quantos desenvolvedores o projeto tem? Com que frequência esses projetos estão lançando novas versões, atualizando suas dependências para as versões mais recentes ou corrigindo vulnerabilidades conhecidas?”

O Sonatype avaliou mais de 20 atributos diferentes de comportamentos de projetos ao longo de cinco anos, para destacar as diferenças entre os projetos de OSS de maior e menor desempenho. Isso fornece a matéria-prima para fornecedores de componentes de classificação empírica, além de apenas boca a boca e quem oferece os melhores ganhos em conferências.

O próximo passo é usar essas informações brutas para adotar uma abordagem mais orientada por inteligência para identificar comportamentos que possam sugerir que os maus atores estão ativamente tentando introduzir vulnerabilidades em projetos de código aberto. Por exemplo, a adição repentina de desenvolvedores a um grupo e um aumento dramático na frequência de lançamento podem desencadear uma investigação mais aprofundada.

“Identificamos o que é um padrão tradicional em dezenas de milhares de projetos que estamos analisando e qual é o comportamento anômalo”, explica Weeks. “E treinamos nossa infraestrutura de inteligência artificial e aprendizado de máquina envolvida na Nexus Intelligence da Sonatype que alimenta o Pacote de Desenvolvimento Avançado.”

Qualquer anomalia notada fornecerá a dica para que os pesquisadores da Sonatype façam pesquisas mais aprofundadas sobre um determinado projeto ou componente. Ao mesmo tempo, através do Advanced Development Pack, ele sinalizará um comportamento anômalo diretamente aos desenvolvedores, permitindo que eles tomem decisões mais informadas sobre a integração de um determinado componente.

“Somente no espaço Java, há seis milhões de lançamentos de componentes de código aberto por aí, “Notas da Weeks. “Você não pode atribuir trabalho de revisão manual à comunidade de desenvolvimento de software ou segurança cibernética e dizer, ‘você pode ficar de olho em todos os seis milhões dessas coisas?’ Você tem que treinar máquinas para poder procurar e interpretar esse comportamento anômalo que, em seguida, o afasta para o potencial comportamento adversário.”

FONTE: THE REGISTER

POSTS RELACIONADOS