Como prevenir pacotes maliciosos e ataques à cadeia de suprimentos de software com a Snyk

Os pacotes de código aberto desempenham um papel fundamental no desenvolvimento de software moderno, impulsionando o ritmo acelerado que vemos por toda parte. Para quem desenvolve e quer adicionar uma nova funcionalidade a uma aplicação, reinventar a roda simplesmente não faz sentido. Por que não instalar um pacote que alguém já dedicou tempo para criar e que oferece exatamente a mesma funcionalidade?

Mas a realidade é que os pacotes de código aberto também são um meio ideal para distribuir código malicioso em aplicações e comprometer a segurança da cadeia de suprimentos. O motivo é simples: eles são alvos fáceis e atraentes para os invasores. Pacotes são publicados em registros sem supervisão de segurança e baixados — milhões de vezes por semana, no caso de projetos populares — para bases de código com quase o mesmo nível de análise.

Registros como npm, PyPI e RubyGems já tiveram sua parcela de pacotes maliciosos nos últimos anos. Portanto, não se trata de um ecossistema ser mais vulnerável que outro. Essa é uma fragilidade de segurança inerente à forma como o software moderno é desenvolvido, que precisa ser reconhecida e enfrentada pelas equipes de segurança — e, ainda mais importante, por quem desenvolve.

Neste artigo, vamos ver rapidamente como pacotes maliciosos são usados em ataques à cadeia de suprimentos de software e como a Snyk pode ajudar a preveni-los.

Pacotes maliciosos em ataques à cadeia de suprimentos de software

Os ataques à cadeia de suprimentos de software buscam inserir código malicioso em um produto de software para comprometer sistemas dependentes em etapas posteriores da cadeia. Mas esses ataques assumem diferentes formas e proporções, variando conforme o alvo e o método usado.

No ataque à SolarWinds, por exemplo, os alvos foram os processos de compilação de software e o código-fonte. No ataque recente à Kaseya, o alvo foi um software já existente. E, cada vez mais, os pacotes de código aberto também são atacados. Nesse tipo de ataque à cadeia de suprimentos de software, o código malicioso é inserido em um pacote publicado em um repositório (por exemplo, npm, PyPI, RubyGems). Ao confiar cegamente na autenticidade e na integridade desses pacotes, quem desenvolve acaba baixando e instalando pacotes maliciosos sem saber, manualmente ou como parte de um processo automatizado de compilação.

Do ponto de vista do invasor, esse método pode ser muito eficaz. Pacotes de código aberto são baixados milhões de vezes por dia, o que faz deles um mecanismo de distribuição perfeito. O conhecido ataque ao event-stream em 2018 mostra o alcance potencial de um ataque à cadeia de suprimentos de software que usa pacotes maliciosos. Nesse caso, o invasor primeiro assumiu o controle do pacote muito popular event-stream e depois o modificou para depender de um pacote malicioso, flatmap-stream. Na época, 1.600 pacotes usavam o event-stream, que era baixado 1,5 milhão de vezes por semana.

Como o código malicioso é inserido nos pacotes?

Um método de ataque é criar um pacote totalmente novo que contenha código malicioso. Esses pacotes podem usar um nome parecido com o de um pacote existente (typosquatting) ou reutilizar o nome ou identificador de um pacote existente que foi retirado de circulação pelo mantenedor original (exploração “use after free”). O segundo método é infectar um pacote existente, inserindo código malicioso no código-fonte, durante a compilação ou no repositório do pacote. Basta que o mantenedor do projeto aceite uma pull request aparentemente inofensiva que contenha o código malicioso. Um terceiro método consiste em publicar pacotes maliciosos em repositórios alternativos ou espelhos de repositórios.

Quando um pacote malicioso entra na árvore de dependências de um projeto, há várias maneiras de executar o código malicioso. Em muitos casos, scripts de instalação são executados durante a instalação do pacote. Em outros, o código malicioso precisa ser acionado durante a execução.

Como mitigar pacotes maliciosos com a Snyk

Então, como você pode se proteger de pacotes maliciosos?

Cada ecossistema tem estratégias específicas para impedir que pacotes maliciosos se infiltrem na sua base de código. Para JavaScript, por exemplo, reunimos algumas práticas recomendadas neste guia rápido. Como solução de segurança de aplicações, a Snyk também oferece várias formas integradas de identificar pacotes maliciosos no início do processo de desenvolvimento e nas etapas posteriores.

Antecipe as verificações de segurança

Trazer a segurança de aplicações para o início do ciclo de desenvolvimento já se tornou uma prática padrão. As equipes mais eficazes automatizam os testes de segurança o mais cedo possível, inclusive nos ambientes locais de desenvolvimento, dentro dos IDEs. Mas a segurança e a identificação de pacotes maliciosos podem começar antes mesmo de você escrever a primeira linha de código — durante o planejamento e a pesquisa.

Fazer uma análise criteriosa é sempre uma boa prática ao pesquisar qual software incluir no seu projeto, mas nem sempre é fácil avaliar um pacote específico. Em um mundo ideal, os registros de pacotes forneceriam todas as informações necessárias para decidir se um pacote deve ser instalado, inclusive se ele é seguro. Na realidade, porém, faltam muitos dados importantes sobre a integridade e a segurança dos pacotes.

O Snyk Advisor é uma ferramenta de pesquisa online e gratuita que ajuda você a decidir quais pacotes usar nos seus projetos. O Snyk Advisor exibe uma pontuação de integridade baseada em vários fatores importantes que devem ser considerados na escolha de um pacote. Por exemplo, o Snyk Advisor analisa a frequência de lançamento de novas versões e a atividade do repositório para avaliar o nível de manutenção do pacote. Também analisa a popularidade do pacote e a força da comunidade que apoia o projeto.

E, claro, o Snyk Advisor também considera o status de segurança do pacote. Os dados de segurança vêm do banco de dados de vulnerabilidades Snyk Intel e incluem informações sobre se o pacote é malicioso. No exemplo abaixo, o pacote npm lyft-dataset-sdk é identificado pelo Snyk Advisor como malicioso e potencialmente usado em um ataque de confusão de dependências — o pacote tem o mesmo nome de um pacote Python criado pela Lyft e, por isso, pode facilmente se infiltrar em uma base de código que defina essa dependência.

O Snyk Vulnerability Database também sinaliza pacotes maliciosos e pode ser usado como parte do seu processo de pesquisa.

No exemplo de typosquatting abaixo, uma gem chamada auth-client é identificada como maliciosa. Quem criou essa gem usou intencionalmente um nome muito parecido com os de pacotes Ruby existentes e seguros (por exemplo, auth_client e authclient), na esperança de que alguém digite o nome da dependência errado e baixe o pacote trojanizado.

Como lidar com pacotes maliciosos em todo o ciclo de vida de desenvolvimento de software

Mesmo com uma pesquisa minuciosa, pacotes maliciosos ainda podem passar despercebidos. Os testes de segurança da Snyk são aplicados em várias etapas do ciclo de vida de desenvolvimento de software para garantir que esses pacotes sejam identificados o mais rápido possível.

Em projetos Git monitorados pela Snyk, toda nova pull request enviada por uma pessoa desenvolvedora que contribui com o projeto é verificada em relação ao Snyk Vulnerability Database. Se um pacote malicioso for identificado, o teste de segurança falhará e informará qual é o pacote e por que o teste falhou.

E quanto aos pacotes maliciosos que já estão na sua lista de pendências? Diante de centenas ou até milhares de vulnerabilidades, encontrar um problema causado pela introdução de um pacote malicioso pode ser uma tarefa desafiadora até para a equipe mais experiente.

A Snyk também sinaliza pacotes maliciosos na interface da Snyk. Nos projetos monitorados pela Snyk, essa informação é considerada no Priority Score de uma vulnerabilidade, junto com outros fatores, como a pontuação CVSS, a disponibilidade de uma correção, se a vulnerabilidade está em alta nas redes sociais, a existência de explorações conhecidas, há quanto tempo a vulnerabilidade foi divulgada e se ela pode ser alcançada. Assim, você encontra, prioriza e corrige esses problemas com rapidez:

Aja desde o início

Do ponto de vista do invasor, a facilidade de publicar pacotes em registros sem qualquer análise de segurança, somada à dependência cada vez maior desses pacotes para manter o ritmo acelerado de desenvolvimento, torna esse ataque extremamente atraente.

Essa é uma fragilidade de segurança inerente à forma como as aplicações são desenvolvidas hoje. Por isso, profissionais de desenvolvimento e segurança precisam conseguir identificar pacotes maliciosos desde as primeiras etapas de pesquisa, tanto ao escolher quais pacotes usar quanto nas fases posteriores do desenvolvimento.

Para saber mais sobre segurança da cadeia de suprimentos de software, clique aqui.