Vulnerabilidades versus componentes de software intencionalmente maliciosos

À medida que o software de código aberto potencializa cada vez mais os aplicativos modernos, as vulnerabilidades e o malware se destacam como desafios formidáveis ​​à segurança e à integridade da cadeia de fornecimento de software de uma organização.

Vulnerabilidades e malware, frequentemente usados ​​de forma intercambiável, são tópicos fundamentalmente diferentes em segurança cibernética. O uso moderno de cada termo muitas vezes surge como excessivamente simplista ou abertamente incorreto.

“Vulnerabilidades” não são ameaças, mas podem ser exploradas por agentes de ameaças. “Malware” não é sinônimo de “vírus”, mas envolve a intenção de causar danos.

No contexto de componentes de software, usaremos estas definições:

• Vulnerabilidades como componentes vulneráveis ​​que podem ser explorados.
• Malware como componentes intencionalmente maliciosos que podem inserir códigos prejudiciais em projetos e ecossistemas.

Componentes Vulneráveis: Falhas no Código

Componentes vulneráveis ​​não são criados com intenções maliciosas, mas são pontos fracos inerentes às cadeias de fornecimento de software.

Um componente vulnerável é semelhante a uma falha no código, muito parecido com uma fechadura defeituosa de uma porta. Assim como uma fechadura defeituosa compromete a segurança de um edifício, um componente vulnerável cria um ponto de entrada para exploração pelos invasores, levando potencialmente ao acesso não autorizado a um sistema, aplicativo ou componente.

Semelhante à maneira como um invasor pode contornar uma fechadura defeituosa para entrar em um prédio sem chave, os agentes de ameaças exploram componentes vulneráveis ​​para comprometer o software.

Esta exploração pode resultar em consequências graves, tais como:

• Acesso sub-reptício a dados
• Injeção de código malicioso
• Interrupção da funcionalidade pretendida do software

Uma vez identificado, um componente vulnerável normalmente recebe um número de identificação especial do programa Common Vulnerabilities and Exposures (CVE). Este número CVE serve como referência abreviada para rastrear e discutir a vulnerabilidade.

Identificar e abordar com eficiência os componentes vulneráveis ​​é crucial para garantir a segurança e a confiabilidade de uma cadeia de fornecimento de software e proteger contra possíveis violações.

Exemplos de componentes vulneráveis

Abaixo estão alguns exemplos do mundo real originados de componentes vulneráveis.

Sangramento cardíaco

Heartbleed foi uma vulnerabilidade crítica descoberta na biblioteca de software criptográfico OpenSSL em abril de 2014. Os agentes da ameaça exploraram um componente vulnerável na implementação da extensão Heartbeat do Transport Layer Security (TLS), expondo potencialmente informações confidenciais como nomes de usuário, senhas e chaves de criptografia privadas.

A vulnerabilidade Heartbleed afetou um grande número de servidores web e exigiu correção imediata para mitigação.

Log4Shell

A vulnerabilidade Log4Shell afetou uma biblioteca de log de código aberto amplamente usada chamada Log4j. Os agentes da ameaça aproveitaram-se de um componente vulnerável enviando mensagens de log especialmente criadas, o que lhes permitiu executar remotamente código malicioso.

Esta vulnerabilidade afetou enormemente e continua a afetar muitas organizações em todo o mundo. Destacou a necessidade de ação rápida e vigilância constante para resolver vulnerabilidades, mesmo em bibliotecas confiáveis.

Spring4Shell

Outra vulnerabilidade notável teve como alvo o popular Spring Framework usado em aplicativos Java. Spring4Shell era uma vulnerabilidade de dia zero, o que significa que os agentes da ameaça exploraram um componente vulnerável antes mesmo que uma correção estivesse disponível.

Este incidente ilustrou a importância de se manter atualizado com os patches de segurança mais recentes e estar ciente da evolução das ameaças em componentes de código aberto.

Componentes intencionalmente maliciosos: projetados para causar danos

Componentes intencionalmente maliciosos representam uma ameaça significativa às cadeias de fornecimento de software e aos ecossistemas de código aberto. Estes elementos nocivos, incluindo vírus, worms, trojans, ransomware, spyware e adware, são concebidos para aceder ilegalmente ou danificar informações e sistemas.

Esses componentes são frequentemente disfarçados como software legítimo, enganando os desenvolvedores para que baixem inadvertidamente códigos nocivos, levando ao roubo de dados, instalações não autorizadas de software, controle de rede ou comprometimento de software e hardware.

A gestão destes componentes é um desafio devido à sua distribuição secreta através de repositórios de pacotes públicos e à falta de números CVE. Esta ausência de marcadores identificáveis ​​dificulta a detecção, rastreio e mitigação eficazes, complicando a avaliação da extensão da ameaça e a implementação das protecções necessárias.

Exemplos de componentes intencionalmente maliciosos

Abaixo, cobrimos alguns exemplos de explorações da cadeia de fornecimento de software que utilizam componentes intencionalmente maliciosos para causar danos.

Confusão de namespace

A confusão de namespace explora gerenciadores de pacotes enviando pacotes maliciosos com os mesmos nomes dos legítimos, mas com números de versão mais altos, para repositórios públicos. Essa estratégia pode enganar os gerentes de pacotes, fazendo-os recuperar a versão mais recente do pacote do repositório público, em vez do repositório interno seguro.

Em dezembro de 2022, o PyTorch sofreu um ataque de confusão de namespace que teve como alvo os usuários da versão noturna do PyTorch, levando ao roubo de dados. PyTorch respondeu reservando o nome do componente para evitar incidentes futuros.

Typosquatting

Typosquatting é uma tática de engenharia social em que os agentes de ameaças criam pacotes de software maliciosos com nomes que imitam componentes populares, explorando erros tipográficos dos desenvolvedores durante a inclusão do pacote. Uma variação, “brandjacking”, envolve imitar marcas conhecidas para enganar os desenvolvedores.

Isso é exemplificado por um incidente no PyPI em agosto de 2022, onde pacotes infectados por ransomware com nomes semelhantes aos da biblioteca legítima “Requests” tinham como alvo os desenvolvedores. O ransomware criptografou arquivos e forneceu chaves de descriptografia sem exigir resgate, demonstrando uma intenção maliciosa única.

Injeção de código malicioso

A injeção de código malicioso é uma ameaça significativa quando os agentes da ameaça comprometem pacotes de código aberto inserindo componentes prejudiciais. Isso geralmente envolve se passar por um committer confiável ou explorar vulnerabilidades para introduzir alterações enganosas.

Um exemplo notável foi o incidente Codecov em abril de 2021, onde os agentes da ameaça exploraram um erro de imagem do Docker para modificar o script Bash Uploader. Eles obtiveram acesso não autorizado e redirecionaram dados confidenciais, incluindo chaves de API, para seus servidores a partir de ambientes de integração contínua e permaneceram sem serem detectados por mais de dois meses.

Defesa contra vulnerabilidades e componentes intencionalmente maliciosos

A distinção entre componentes vulneráveis ​​e componentes intencionalmente maliciosos orienta as estratégias para proteger as cadeias de fornecimento de software.

Para melhorar a segurança destes sistemas, as organizações devem considerar as seguintes abordagens:

• Gerenciamento de patches: Empregue atualizações e patches regulares para resolver rapidamente as vulnerabilidades assim que forem descobertas, minimizando possíveis explorações.
• Sistemas de detecção robustos: Desenvolva e use ferramentas e práticas de detecção avançadas que impeçam a infiltração de componentes intencionalmente maliciosos em ambientes de desenvolvimento.
• Melhores práticas de segurança: Estabeleça e aplique políticas que promovam uma cultura consciente da segurança nas equipes de desenvolvimento, garantindo que todos os membros entendam e sigam as melhores práticas de segurança.

Ao compreender os desafios de segurança únicos, mas inter-relacionados, colocados por componentes vulneráveis ​​e componentes intencionalmente maliciosos, as organizações podem proteger melhor as suas cadeias de fornecimento de software. Isto não só mantém a confiança e a fiabilidade das suas aplicações, mas também protege contra potenciais violações e interrupções.

A postagem Vulnerabilidades versus componentes de software intencionalmente maliciosos apareceu pela primeira vez em The New Stack.