Este é o quarto episódio da série série de posts sobre componentes maliciosos, onde apresentamos o Xygeni abordagem para lidar com esta ameaça, como parte de nossa cobertura para Open Source Security.
Vimos que o excesso de confiança em componentes de código aberto de origem incerta é aproveitado por criminosos de todos os tipos para gerar comportamento inesperado a ser executado em máquinas de desenvolvedores, CI/CD sistemas, ou incorporados no software da organização vítima, para que seja repassado aos clientes da organização. Dissecamos em Episódio 2 os ataques que usam registros públicos para distribuir malware e o que aprendemos depois de observar como os malfeitores operam, e no anterior Episódio 3 foram examinados os controles que funcionam (e aqueles que falham) contra esta ameaça.
Agora é a hora de examinar nossa abordagem do problema. Neste episódio apresentamos qual é a estratégia que seguimos na Xygeni para o nosso Alerta antecipado de malware (MEW). Como este sistema de vários estágios funciona em tempo real quando uma nova versão do pacote é lançada, 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. Também explicaremos como estamos ajudando NPM, GitHub, PyPI e outras infraestruturas importantes nos ecossistemas de código aberto a reduzir o tempo de permanência do malware.
O método da pipeline
O Xygeni Malware Early Warning (MEW) está processando continuamente componentes, sejam tarballs de pacotes para bibliotecas e estruturas para ecossistemas de programação suportados como JavaScript/Node ou Python, imagens de contêiner Docker/OCI ou extensões e plug-ins para ferramentas como IDEs ou CI/CD sistemas. Tais componentes são publicados em registros públicos com diferentes níveis de verificação de usuários.
A seguir está uma visão esquemática de como o sistema funciona:
O método da descobridor processo obtém o feed de eventos de publicação. Um evento de publicação é a criação de uma nova versão de um componente novo ou existente. Como os registos populares não fornecem um mecanismo pub-sub para os consumidores interessados, isto é muitas vezes feito através de uma pesquisa no registo relativamente a eventos recentes. Um excelente projeto da OSSF, feeds de pacotes, Apoio registros populares como PyPI ou Maven Central e fornecem uma interface unificada baseada em feed. No MEW adicionamos algumas implementações específicas que reduzem o tempo de espera, por exemplo com uma réplica do banco de dados CouchDB utilizado pelo NPM que está sincronizado com o banco de dados do registro público.
Na Xygeni, temos um inventário de todos os componentes (direta ou indiretamente) utilizados pelo software de nossos clientes. As coordenadas dos componentes dos clientes são enviadas regularmente ao MEW para priorizar as análises: os componentes usados pelos nossos clientes são processados mais cedo. A prioridade também se baseia na reputação do editor e na criticidade do componente, portanto, os componentes provenientes de editores com baixa reputação também são priorizados.
O método da analisadores em seguida, consuma os componentes pendentes na fila de prioridade. Quando uma versão de componente é selecionada para análise, seu tarball é baixado do registro. Observe que o componente binário empacotado é analisado: a maioria dos componentes de código aberto normalmente vem de um repositório de código aberto, geralmente em github.com, que é usado apenas para contexto, e o malware é sempre procurado no tarball do componente porque os atores da ameaça sistematicamente mentem sobre as fontes que afirmam ter usado para construir o tarball do componente que lançam.
Da perspectiva do usuário
Ouço você pensando: como posso me beneficiar sabendo antecipadamente sobre uma versão de pacote malicioso? No episódio “Anatomia dos pacotes maliciosos: quais são as tendências?” vimos que o tempo total de permanência está na faixa de dias, enquanto a primeira notificação do MEW aos clientes que utilizam o componente afetado está na faixa de minutos. Com um guarda-corpo simples você pode bloquear a compilação (existem dois níveis de alerta, um totalmente automatizado quando o mecanismo conclui que há malware em potencial e uma notificação posterior quando nossa equipe de segurança confirma por inspeção manual a presença de malware). Esperar até que o registro confirme o malware e o remova do registro normalmente é tarde demais devido à longa janela de exposição.
A organização pode utilizar um guardrail que verifica se existe algum componente com potencial malware (em qualquer um dos dois níveis de alerta) ou, via API, saber rapidamente se alguma das dependências diretas ou indiretas de um projeto de software está utilizando um componente malicioso.
Como funciona o MEW: detalhes internos
O núcleo: mecanismo de detecção de malware
O analisador usa diferentes detectores para capturar evidências de irregularidades. Os detectores combinam análise estática, análise de capacidades e análise de contexto , conforme descrito no post anterior desta série.
Na Xygeni contamos com uma equipe de engenharia com longa experiência em análise estática, sendo este o principal diferencial em relação a outras soluções anti-malware. Observe que, para alguns ecossistemas, o tarball empacotado contém código-fonte (por exemplo, código JavaScript ou TypeScript para pacotes NPM, fontes Python para pacotes PyPI) ou código compilado próximo o suficiente do código-fonte para análise estática (por exemplo, bytecode em arquivos JAR para Maven). . Para outros, como imagens de contêiner, executáveis binários são comuns, portanto, a inferência de capacidades é a técnica usada, juntamente com a detecção de malware convencional baseada em regras YARA e assinaturas de malware.
Observe que tecnologias simples, como expressões regulares ou assinaturas, não são apropriadas para detectar comportamento malicioso. Imagine detectar um dropper ou downloader: algum código ou binário está localizado no pacote ou baixado de um domínio externo, não relacionado ao componente (pode ser um de um grande lista de domínios adquiridos pelo ator da ameaça , Ou um domínio legítimo para evitar detecção). Esse código é então executado usando uma das funções para isso. O código pode ser transformado para ocultar o URL de download ou a função usada para executar o código baixado. É necessária uma análise completa do fluxo de dados para detectá-lo, usando todo o mecanismo de análise estática, ou uma execução em área restrita (se as condições para a execução de comportamento malicioso forem realmente atendidas) poderia detectar isso no caso geral.
Os atores da ameaça seguem as mesmas técnicas e os detectores para eles foram projetados e implementados. Existem também algumas etapas de pré-processamento, por exemplo, para remover ofuscação, muitas vezes necessárias para descobrir o comportamento oculto.
Adicionando Contexto
Alguns detectores usam informações de contexto. Por exemplo, uma incompatibilidade entre a versão no registro do componente e a tag/lançamento no repositório GitHub associado constitui forte evidência de que talvez um malfeitor tenha obtido credenciais de publicação para o registro, mas não para o repositório GitHub. Ataques como o que afetou o fornecedor de carteiras criptografadas Ledger poderia ser facilmente detectado por esta incompatibilidade.
A pontuação de maldade (MS) é calculado a partir das descobertas dos detectores, com base na força das evidências capturadas. Nem todas as conclusões são iguais e a ordem de execução é relevante.
Reputação de usuários e componentes
Nem todos os desenvolvedores de código aberto são criados iguais!
Um desenvolvedor respeitável pode ter sua conta NPM invadida (isso acontece mesmo com pessoas preocupadas com a segurança) e malware publicado usando essa conta. Obviamente, a reputação deve cair abruptamente e só recuperar a glória passada quando a conta sequestrada for recuperada e o desenvolvedor corrigir as condições que levaram à aquisição da conta. A reputação é difícil de ganhar, mas pode ser perdida em um instante.
Na MEW, implementámos um sistema abrangente de gestão de reputação para recompensar comportamentos positivos e penalizar atividades suspeitas. Este sistema começa com novos usuários em uma postura neutra e ajusta sua reputação com base em suas atividades contínuas.
A reputação de um usuário melhora por meio de ações positivas, como manter contas ativas nas redes sociais, permitir a autenticação multifatorial, contribuir regularmente para projetos e assinar commits com chaves verificáveis. Por outro lado, a reputação se deteriora devido a ações hostis, como publicação de malware, uso de endereços de e-mail descartáveis, não assinatura commits, ou exibindo padrões incomuns em contribuições.
O principal objetivo do nosso sistema é garantir um ambiente seguro e confiável. Isso é conseguido ajustando dinamicamente a reputação dos usuários com base em vários fatores, ao mesmo tempo que respeita as preocupações com a privacidade e as limitações dos diferentes registros.
Uma pontuação de reputação interna é computada para o usuário (ingressando no registro e na conta do github quando possível), e juntamente com a pontuação de malícia utilizada durante a classificação do componente em análise, e para melhor qualificar quem está sob a publicação do componente.
Foram encontradas evidências de comportamento malicioso. E daí? O processo de revisão manual
O classificador atual define a versão do componente analisada em uma das categorias “malicioso confirmado”, “provavelmente malicioso”, “alto risco”, “baixo risco” ou “não malicioso” com base em limites nas pontuações que condensam as descobertas e a reputação do usuário/componente. Uma classificação em categorias de “alto risco” ou “provavelmente maliciosa” aciona a revisão manual e a primeira notificação. A categoria “mal-intencionado confirmado” é definida após revisão manual ou quando a evidência corresponde à mesma evidência de uma versão anterior que foi confirmada como mal-intencionada.
Quando existem evidências suficientes de potencial comportamento malicioso, um primeiro alerta (alerta de quarentena) é emitido para as organizações afetadas. Conforme mencionado anteriormente, isso pode bloquear a instalação ou construção de software que depende do componente em quarentena.
Isso cria um problema no sistema interno do MEW dashboard para que os analistas de segurança possam iniciar o processo de revisão manual do componente. A equipe possui ferramentas especializadas (sandbox, desofuscadores, distribuição para pesquisa de malware, ferramentas de relatórios de malware) para avaliar rapidamente a natureza da versão do componente sob investigação. A maior parte do malware (“as anchovas” ou componentes maliciosos não sofisticados) é revisada
O resultado da revisão conclui em segura, então o mecanismo de análise automática encontrou um falso positivo que é usado como feedback para o classificador de aprendizado de máquina aprender o padrão; ou malicioso confirmado, portanto, o componente é divulgado de forma responsável como malicioso ao registro público, após o processo de relatório. Uma segunda notificação é enviada às organizações afetadas, que por sua vez podem retirar o componente da quarentena ou bloqueá-lo definitivamente do processo de atualização de versão ou do firewall do componente usado em seu registro interno.
Essa configuração nos permite analisar dezenas de milhares de novas versões diariamente e identificar as dezenas que provavelmente são maliciosas, que depois revisamos manualmente. Lembre-se do episódio anterior que uma em cada dez mil é a taxa de componentes maliciosos que vemos atualmente em circulação.
Reportando ao Registro
Descobrimos que a maioria dos registros públicos, um dos pilares da infraestrutura de código aberto, fornece mecanismos bastante limitados para relatar problemas de segurança e, em particular, componentes maliciosos. Estamos lutando para melhorar a organização subjacente do processo de elaboração de relatórios. Normalmente recebemos no máximo um e-mail de feedback da equipe de segurança do registro confirmando que o componente foi removido do registro.
Às vezes, o registro é abusado, violando seus termos de uso, mas não causando comportamento malicioso no software entregue. Isso também é informado ao registro, mas não é notificado às organizações para limitar o ruído.
Trabalho futuro
Muitas melhorias estão atualmente no roteiro. Em primeiro lugar, um portal público para integridade de componentes do sistema operacional, particularmente relacionado com as evidências encontradas de potencial maldade, está atualmente em desenvolvimento. Isto pretende ser uma contribuição modesta para a comunidade de código aberto. Fique atento.
Outro desenvolvimento contínuo é uma melhoria classificador de aprendizado de máquina. O MEW aprenderá com classificações anteriores. O vetor de descobertas de detectores de mecanismo, mais a pontuação de malícia derivada e a pontuação de reputação para o componente e o publicador (“a evidência encontrada”) é usada como entrada para um sistema de aprendizado de máquina que atualiza o modelo do classificador. A variável de saída é simplesmente se o registro confirmou se o componente era malicioso. Isso é codinome “the Oracle” e ajudará com uma precise qualificador, projetado para ser sólido (alta recuperação, ou seja, não perder componentes maliciosos), mas com menos falsos positivos (não relatar componentes seguros como maliciosos).
A pontuação de criticidade serão acrescentados critérios de priorização, além de pertencer ao conjunto de dependências dos clientes, e da baixa reputação do editor. É claro que projetos com maior influência e importância devem ser considerados mais cedo para análise. Não vamos reinventar a roda aqui e seguir o Pontuação de criticidade do projeto de código aberto.
O apoio a ecossistemas adicionais está em desenvolvimento. Tecnologias e ferramentas generalizadas como plug-ins PHP ou Jenkins estão no roteiro.
Também estamos explorando se o processo de revisão manual poderia ser ajudado pela IA para agilizar a análise dos poucos componentes maliciosos mais sofisticados.
Na próxima e última edição desta série, “Explorando o código aberto: o que esperar dos bandidos”, vamos nos concentrar nas formas mais recentes que os adversários estão adotando para tornar os ataques mais furtivos, mais difíceis de detectar, mais direcionados a setores específicos e mais lucrativos. Os ataques de ransomware serão realizados usando este veículo? Como os bandidos estão aproveitando as ferramentas de IA para fornecer malware mais sofisticado? Os principais projetos populares estão em risco? Isto é para dar aos leitores uma ideia desta corrida armamentista e o que esperar no curto prazo (segundo semestre de 2024) e no médio prazo (2025).
Concluiremos com algumas reflexões sobre quais passos a comunidade poderia dar sem mudar muito a abertura do mundo do código aberto. Por exemplo, um mecanismo mais eficiente para denunciar malware aos registos públicos e partilhar provas de componentes potencialmente maliciosos com os registos e a comunidade seria um pequeno passo na direcção certa em direcção ao objectivo de fechar as portas aos actores de ameaças.
O malware em componentes de código aberto não deve perturbar os enormes benefícios que a comunidade de código aberto trouxe à nossa sociedade.
- Nosso scanner detecta componentes de código aberto referenciados pelos projetos de software analisados, de modo que o gráfico de dependência completo e atualizado seja conhecido, pelo menos para projetos que são verificados regularmente. O Xygeni OSS expõe uma API que os clientes também podem usar durante a inclusão de um componente de interesse na lista de permissões, incluindo informações sobre vulnerabilidades e evidências maliciosas.
- Um guardrail pode interromper a construção se uma condição correspondente a problemas de segurança for detectada. Descobertas de segurança, como uma vulnerabilidade crítica e acessível ou o uso de um componente em quarentena, podem ser consideradas graves o suficiente para interromper a construção do software afetado.
- Nossos analistas de segurança executam o componente ou seus scripts de instalação em um ambiente de área restrita quando necessário. No entanto, o MEW não realiza análises dinâmicas, principalmente porque o comportamento malicioso nem sempre é executado em ataques direcionados e devido à lógica de evasão que os atores da ameaça usam para escapar da análise dinâmica.
- Essa técnica recebeu um nome, Registered Domain Generation Algorithms ou RDGA, e novos atores de ameaças, como os chamados Coelho Revólver investiu até 1 milhão de dólares em 500 mil domínios, mostrando o quão lucrativa é a indústria do crime cibernético.
