Este é o primeiro episódio de uma série de artigos sobre o tipo mais comum de ataques à cadeia de fornecimento de software: aqueles que (ab)utilizam um registro público de componentes de software, destinados a projetos de código aberto para fazer upload de artefatos que podem ser compartilhados com outros usuários. Quando os bandidos publicam software malicioso lá, usando o registro como veículo para distribuição de malware, temos um ataque à cadeia de suprimentos quando as organizações vítimas instalam ou executam o componente de software infectado.
Para simplificar a discussão, falaremos sobre pacotes de software:, componentes embalados produzidos por terceiros. Isso inclui não apenas componentes usados por gerenciadores de pacotes como NPM ou Poetry, mas também componentes do sistema operacional incluindo bibliotecas e binários executáveis, imagens de contêiner, e máquinas virtuais, ou extensões de ferramentas para ferramentas de desenvolvimento, construção e implantação. Temos visto pacotes maliciosos em todos os lugares. Os cibercriminosos não se importam: eles ficam encantados com as alternativas fornecidas pelas infraestruturas de software modernas e usam o registro e a ferramenta que melhor se adaptam à sua intenção. Então, lembre-se de que pacotes de software são uma abreviação para imagens de contêiner, pacotes binários, repositórios de código aberto e extensões ou plug-ins de todos os tipos (IDEs, CI/CD sistemas, ferramentas de construção). Todos estão rotineiramente sob ataque.
A série terá 5 episódios:
- Qual é o problema dos pacotes de código aberto? Este é o tema deste post. Por que criminosos de todos os tipos estão publicando pacotes maliciosos? Por que eu deveria me preocupar?
- Anatomia dos pacotes maliciosos: quais são as tendências? Neste episódio, focamos na ameaça que monitoramos com nosso sistema MEW, dia após dia. Com um grande ruído de fundo devido a um grande número de pacotes maliciosos usando typosquatting ou confusão de dependência, uma porcentagem menor de ataques é muito mais insidiosa e representa um risco maior. Como o comportamento dos malfeitores em relação ao sistema operacional mudou no passado recente? Quais são os números? Quais são as táticas, técnicas e procedimentos utilizados e as ações prejudiciais observadas?
- Proteção contra pacotes maliciosos de código aberto: o que (não) funciona. A maioria dos profissionais conscientes da segurança tem ideias sobre como lidar com essa ameaça. Ouvimos gerentes de segurança dizendo sem hesitação que SCA as ferramentas já informam quando uma versão do pacote é malware. Ou que elas dependem de componentes de software bem conhecidos e altamente revisados, onde qualquer malware seria prontamente detectado e removido. Elas Que elas usam versões menores/patch abertas para obter automaticamente correções de vulnerabilidades, e essa é a maneira adequada e recomendada de reduzir o risco em dependências de código aberto, seguindo o princípio de “patch cedo, patch frequentemente”. Neste episódio, revisaremos por que essas ideias estão erradas e como tais equívocos estão contribuindo para a popularidade desse mecanismo de ataque e para um risco avassalador que as organizações estão enfrentando. Terminaremos com o que funciona e qual é o esforço e os recursos envolvidos.
- Pacotes maliciosos de código aberto: a abordagem Xygeni. Neste episódio apresentamos qual é a estratégia que seguimos na Xygeni para nosso sistema de Malware Early Warning (MEW). Como funciona este sistema de múltiplos estágios em tempo real quando uma nova versão do pacote é publicada, como as evidências são capturadas de diferentes fontes, como a triagem é feita, quais critérios de classificação estamos seguindo e por que ainda é necessária alguma análise manual para confirmar a natureza de um candidato a pacote malicioso? Como o feedback de nossas equipes internas e de registro ajuda o sistema a aprender com evidências anteriores coletadas para reduzir ao mínimo os falsos positivos. NósE explicaremos como estamos ajudando NPM, GitHub, PyPI e outras infraestruturas importantes nos ecossistemas de código aberto a reduzir o tempo de permanência.
- Explorando o código aberto: o que esperar dos bandidos. A série termina com foco nas ações mais recentes que os adversários estão adotando para tornar os ataques mais furtivos, mais difíceis de detectar, mais direcionados contra setores específicos e extrair mais benefícios dessa classe de ataques. Os ataques de ransomware serão realizados usando este veículo? Como os bandidos estão aproveitando as ferramentas de IA para entregar pacotes maliciosos mais sofisticados? Os principais projetos populares estão em perigo? Isto é para dar aos leitores uma ideia sobre esta corrida armamentista e o que esperar no curto prazo (segundo semestre de 2024) e no médio prazo (2025). Aprenderemos como ataques como o recente Porta dos fundos XZ-Utils, ou o ataque dos que vivem da terra construtor de elétrons em março de 2024 mostram que devemos manter-nos vigilantes sobre a forma como os adversários evoluem.
Vamos abrir o palco com o primeiro episódio: O que está acontecendo com os pacotes maliciosos de código aberto?
Qual é o problema dos pacotes de código aberto?
Nos últimos anos, transgressores de todos os tipos usaram registros de software de código aberto para fornecer comportamento malicioso. Estas atividades são tão antigas quanto o código aberto, mas a sua frequência explodiu nos últimos três anos.
Publicação de componentes maliciosos em registros públicos (ataques baseados em dependência) é uma guerra de guerrilha assimétrica que os agentes de ameaças usam para distribuir malware, aproveitando a confiança que as organizações depositam em componentes de código aberto provenientes de desenvolvedores desconhecidos (lembre-se do dependência xkcd quadrinhos?). Como você confia nos pacotes e não se importa em revisar manualmente o conteúdo dos pacotes e suas dependências, esses ataques são extraordinariamente eficazes. E a assimetria ocorre porque eles podem ser amplamente automatizados e os bandidos não precisam interagir diretamente com a vítima. Eles simplesmente carregam o pacote no registro público e o liberam.
Pacotes maliciosos aumentou por um fator de 6x em 2022, e continuou a crescer por um fator de 2.5x em 2023. No ano passado, foram vistos 245,000 pacotes maliciosos, um número que mais que duplica o número total dos anos anteriores combinados. Isso é um crescimento exponencial! Das remoções de pacotes como malware confirmado às centenas durante 2021 e aos milhares durante 2022, vimos muito mais “ruído” de fundo durante 2023, com um ritmo semelhante neste ano. E escondidos nesse contexto, causados por cibercriminosos pouco sofisticados que seguem o “caminho da menor resistência”, uma minoria de ataques de alto perfil chegaram às manchetes, mesmo nos meios de comunicação em geral.
Por que este é um problema de tal magnitude? Há um excesso de confiança por toda a cadeia. O software de código aberto é distribuído com seu código-fonte e lançado sob uma determinada licença. Sim, qualquer pessoa pode inspecionar o código-fonte; mas quem faz isso em geral? Quem, depois de inspecionar se o software não contém malware, constrói o software a partir das fontes? Quem, antes de passar o componente empacotado (também conhecido como pacote) downstream para o gerenciador de pacotes ou a ferramenta de compilação, garante que o pacote não esteja repleto de malware e corresponda ao suposto código-fonte de onde deveria vir?
Por que a infraestrutura permite ataques tão fáceis?
Registros de pacotes são abertos, muitas vezes exigindo verificação mínima da identidade do editor. “Qualquer pessoa é bem-vinda para publicar seu software aqui!” A barreira para os invasores é baixa: eles usam endereços de e-mail descartáveis e contas GitHubgithub descartáveis para criar centenas de pacotes maliciosos em campanhas curtas, semelhantes a phishing. Somente para os direcionados é necessária uma maior sofisticação: vimos até mesmo a criação de um repositório de fontes GitHub confiável com muitas estrelas e commits de vários contribuidores falsos e outras métricas de popularidade e manutenção. Recebendo observadores de estrelas e reputação de contribuições falsas não é difícil de automatizar. Vimos abusos em infraestruturas de software aberto de todos os tipos, não apenas malware, como o incidente do protocolo do chá.
Os gerenciadores de pacotes foram projetados para facilidade de uso e não para segurança. Eles podem executar scripts de pré e pós-instalação (às vezes é necessário compilar o código nativo para uma biblioteca). Também, Gerenciadores de pacotes instala pacotes de múltiplas fontes e, às vezes, o padrão é usar registros públicos. Eles não verificaram incompatibilidade entre os metadados na solicitação de publicação e os metadados no próprio pacote.
As dependências são aninhadas e formam um gráfico. Em certos ecossistemas como o Node (JavaScript), dependências de pequena granularidade se acumulam na casa das centenas ou milhares. Uma coisa é ter controle rigoroso sobre as dependências diretas declaradas pelos meus projetos de software, mas dependências transitivas são mais difíceis de controlar. O código aberto seguiu “os amigos dos meus amigos são meus amigos”. A fraternidade é a norma no Extremo Oriente selvagem! Os atores da ameaça sabem disso e escondem profundamente o comportamento malicioso em dependências obscuras que muitas vezes são desconhecidas. Este foi o caso com o fluxo de eventos incidente visando o Carteira Copay.
É assim que o software de código aberto funcionou desde o seu início. Não vai mudar muito. Alguns registros de pacotes exigem, na melhor das hipóteses, autenticação de dois fatores e, muitas vezes, apenas para os pacotes mais populares. Alguns registros fornecem escopos, um namespace de propriedade de uma organização controlada, mas tragicamente outros não o suportam (PyPI) ou o tornam opcional (NPM). É interessante notar que mesmo um esquema de triagem simples (com base no controle do repositório/organização DNS ou GitHub correspondente ao ID do grupo) e fazer Assinaturas PGP obrigatórias para todos os artefatos, exceto somas de verificação, remove a maior parte do “ruído”, pacotes maliciosos do tipo typosquatting e limita grande parte do confusão de dependência. Ataques sofisticados são possíveis, mas muito mais difíceis, com apenas alguns como o com.github.codingandcoding:maven-compiler-plugin conhecido por Maven Central. E nem todos os registros maven seguem as mesmas práticas!
Os controles de segurança nos gerenciadores de pacotes podem sobrecarregar, mas não impedir ataques de dependência. O problema com a autenticação multifator é que, para automação, credenciais derivadas, como tokens de acesso ou chaves APIapi, são geradas para contas a serem usadas em chamadas APIapi feitas a partir de scripts de automação, sem nenhum usuário interativo de apoio fornecendo um segundo fator. A MFA é boa para proteger contas de usuários contra vazamentos de senha, mas os tokens de acesso gerados ou chaves APIapi precisam ser protegidos enquanto ativos, ou seu proprietário será representado pelos adversários. Uma grande fração das campanhas da cadeia de suprimentos baseadas em pacotes começa com um vazamento de chave/token. Apenas lembre-se de incidentes como Ledger, 3CX, e muitos mais, onde credenciais não interativas foram exfiltradas pela primeira vez em uma intrusão preliminar para lançar o ataque à cadeia de suprimentos.
A resposta dada a essa ameaça não foi robusta o suficiente. No terceiro episódio, vamos nos concentrar no que funcionou e no que falhou miseravelmente. A indústria precisa trabalhar coletivamente no standards, processos, educação e ferramentas para mitigar riscos para cadeias de suprimentos globais. Este não é um problema que uma única organização pode resolver sozinha.
Para encerrar esta seção, o mal-entendido crucial: estamos falando de malicioso pacotes, não vulnerável uns. As vulnerabilidades vêm de erros de design ou de codificação, introduzidos acidentalmente, sem má intenção. As vulnerabilidades podem ser exploradas, mas muitas não. Pacotes maliciosos são sempre intencionais e há 100% de exploração se forem executados. Nenhum risco comparável! Por isso é paradoxal ver quantos esforços são feitos para detectar e mitigar vulnerabilidades e a falta de medidas equivalentes para componentes maliciosos.
“Levamos a segurança a sério”
Vamos imaginar o costume Acme Corporation. Acme, um importante fornecedor do WileCoyote.com, tem a maior parte de seu software proveniente de terceiros, com mais de 80% de projetos de código aberto. Eles produzem software para uso interno, mas também fornecem software para seus parceiros, fornecedores e clientes/usuários finais. A Acme possui software escrito em Go, JavaScript, Java, C# e Python e executa a maior parte de seu software na nuvem, em clusters Kuberneteskubernetes. A Acme constrói suas imagens personalizadas a partir de imagens base obtidas do Docker Hub e de outros registros. E eles também compartilham algumas bibliotecas, pacotes e imagens de contêineres em registros públicos.
A Acme leva a segurança a sério. Eles estão bastante conscientes do problema de open source securitye o risco que isso acarreta. Todos os desenvolvedores, gerentes de sistema e engenheiros de DevOpsdevops usam essas pequenas chaves criptográficas como autenticação de segundo fator. Todos commits para repositórios de código são assinados, a proteção de ramificação é habilitada com revisões de código obrigatórias, CI/CD bloqueados, segredos armazenados em um cofre secreto, e com um registro interno espelhando parcialmente registros externos onde apenas os componentes permitidos e na lista branca são armazenados. É necessário que o software construído pela Acme tome dependências de terceiros deste registro.
Provavelmente a maioria das organizações se enquadra nesse perfil. Caro leitor, o seu certamente cabe se você ainda está aqui, não é mesmo?
Então, em um dia infeliz, um importante desenvolvedor front-end na Acme correu npm instalar acme-cute-lib, esquecendo que @acme/cute-lib era a dependência com escopo correto. O erro exato não é importante, muitas coisas podem dar errado mesmo quando se assume o controle perfeito do ciclo de vida do software. Nosso desenvolvedor não sabia que um grupo APT tinha como alvo a Acme e publicou um componente malicioso com esse nome, de forma astuta para que o comportamento malicioso seja ativado apenas quando o software for instalado nos computadores da Acme. O pacote não foi detectado semanas após sua publicação.
É executado um script de instalação que procura credenciais (havia muitos tokens de acesso interessantes no laptop do nosso desenvolvedor), permitindo acesso a repositórios internos de software e ao repositório interno mencionado acima, que obviamente só é acessível via VPN. O código malicioso conseguiu usar a conexão VPN existente e publicar um componente malicioso de segundo estágio no registro interno, afetando uma biblioteca de utilitários comum compartilhada pela maioria dos softwares fornecidos pela Acme.
Semanas depois, outras organizações que usavam as ferramentas publicadas da Acme começaram a ver tráfego estranho em suas redes, com tráfego usando o protocolo da Acme, mas direcionado para hosts semelhantes ao domínio Acme. O tráfego foi criptografado, mas ferramentas de monitoramento do sistema encontraram acesso a arquivos inesperados e a execução de processos que parecem comandos do sistema, mas que acabam executando executáveis baixados.
O resto é história: a Acme primeiro negou que tal comportamento fosse imputável a eles e que todas as medidas de segurança estivessem em vigor. Somente depois que a mídia cibersec começou a perguntar por que a origem do comportamento detectado se originou nos componentes da Acme, e a análise de segurança postou o quão crivados estavam esses componentes com malware furtivo, a Acme teve que reconhecer o incidente e chamar uma empresa de resposta a incidentes. Uma campanha de marketing negativa que minou a confiança conquistada com dificuldade em um segundo. “Acme estava a uma instalação npm de distância de disaster”era uma manchete comum. Depois, ações judiciais e contratos cancelados seguiram o exemplo.
Você vê semelhanças com incidentes passados conhecidos? A Acme sofreu um incidente na cadeia de suprimentos em duas fases, usando uma combinação de confusão de dependência/typosquatting ataques que usaram uma estação de trabalho de desenvolvedor como base para infectar componentes que acabaram em software usado por terceiros. Como isso poderia ser evitado ou mitigado?
Por que os pacotes envenenados são tão populares
Este incidente hipotético mostra que mesmo com uma abordagem razoável à segurança de código aberto, as organizações precisam de medidas específicas para evitar serem vítimas de malware em componentes de código aberto. Esquematicamente, o ator da ameaça pode:
- Crie um novo pacote (seguindo os conhecidos caminhos de typosquatting ou confusão de dependências, este é o caminho mais percorrido pelos bandidos em volume);
- Tente infectar um existente, seja injetando-o no código-fonte, tentando disfarçá-lo como um contribuidor via pull request, ou usar engenharia social para se tornar um mantenedor (como “Jao Tan” fez no XZ Backdoor ou direita9ctrl O usuário do GitHub fez no fluxo de eventos incidente no outono de 2018), ou obtendo credenciais de repositório de código aberto e se fazendo passar pelo mantenedor;
- Injete malware durante a construção do pacote, executando um script de construção maliciosoou interferir nos downloads de pacotes com interceptações man-in-the-middle (felizmente, o TLS agora é sempre necessário na maioria dos registros).
- Injete o componente empacotado diretamente no registro, normalmente capturando as credenciais do registro (a alternativa preferida para muitos ataques sofisticados como o da Acme, onde a estação de trabalho comprometida no primeiro estágio tinha o token de acesso interno ao registro, por exemplo, no habitual .env or ~/.m2/settings.xml: os maus atores sabem onde procurar segredos). Vulnerabilidades nos registros também foram exploradas.
Envenenar registros com malware é a base para ataques de dependência. Nada de novo sob o sol: a sua prevalência explodiu, mas as mesmas técnicas funcionam agora como há cinco anos.
Fonte: Coleção de facas do Backstabber.
O pacote malicioso pode operar na instalação, durante a construção do software ou em tempo de execução. E o comportamento varia desde a exfiltração de informações, por exemplo, a extração de segredos para uma tentativa de segunda fase, até a extração de código-fonte, eliminando malware adicional. No próximo episódio, dissecaremos os pacotes maliciosos e como eles são publicados.
Outras leituras
o próximo episódio Anatomia dos pacotes maliciosos: quais são as tendências? focaremos em casos reais que estamos monitorando com nosso sistema de alerta precoce de malware, dia após dia. Analisaremos quais tipos de malware foram detectados e quais táticas, técnicas e procedimentos são os favoritos. Examinaremos o ofuscamento e como eles tentam se esconder de potenciais revisores, as técnicas de evasão para evitar a detecção e como estão evoluindo com a telemetria e o movimento lateral. Por favor fique atento!
Referências
- Coleção de facas do Backstabber: uma revisão dos ataques à cadeia de suprimentos de software de código aberto. M. Ohm et al., maio de 2020.
- Proteção contra malware de código aberto. Artigo da Xygeni.
- Software Supply Chain Security Retrospectiva: Moldando um 2024 mais seguro. Relatório de Xygeni.
