Os ataques da cadeia de suprimentos de software continuam sendo um vetor de ataque externo superior para atacantes violar empresas, agências governamentais e até carteiras pessoais de criptomoeda. Três ataques recentemente revelados são um lembrete de como os atacantes sondam para qualquer fraqueza em uma cadeia de suprimentos, incluindo entidades menores, para atingir empresas maiores. Aprenda com esses ataques para fortalecer suas cadeias de suprimentos ou se expor ao mesmo.
Salesloft-Salesforce
O Salesloft-Salesforce A violação é a mais sofisticada e teve o maior impacto. Nesse ataque, os atores de ameaças comprometeram os clientes Drift da Salesloft e as contas do Salesforce. Mais de 700 empresas foram afetadas.
- A fraqueza da cadeia de suprimentos de software. A violação se originou com atacantes acessando a conta do Salesloft Github e os repositórios de código. Os atacantes então acessaram o ambiente Drift AWS. Na AWS, os invasores obtiveram tokens de autorização para integrações tecnológicas dos clientes, incluindo o Salesforce, que por sua vez foram usados para exfiltrar os dados dos ambientes de clientes do Salesforce. Separadamente, os atacantes utilizaram outras integrações de deriva para comprometer outras empresas. O colapso mais abrangente de Forrester é aqui.
- O que os atacantes fizeram. Os atacantes acessaram dados confidenciais de inúmeras contas, incluindo bem respeitado Fornecedores de segurança cibernética como Cyberark, Proofpoint, Tenable e Zscaler. Os dados sensíveis ao cliente expostos incluíram endereços IP, informações da conta, tokens de acesso, dados de contato do cliente e registros comerciais, como o pipeline de vendas. Os invasores exploraram o armazenamento ClearText de informações confidenciais nas notas do caso de suporte do Salesforce, que pretendiam facilitar o suporte ao cliente, mas forneciam dados críticos para hackers.
- O impacto. O ataque mostrou que os invasores podem girar de um aplicativo (deriva) em outras integrações, como o Salesforce, acessar ambientes de clientes e fazendo disso um ataque da cadeia de suprimentos de terceiro e quarto nível.
Giz e depuração
““giz e depuraçãoFoi nomeado após dois dos 18 pacotes de gerenciador de pacotes de nó de código aberto (NPM) que foram comprometidos em 8 de setembro.
- A fraqueza da cadeia de suprimentos. Os atacantes começaram com uma campanha de phishing direcionada a mantenedores de código aberto de pacotes populares da NPM para roubar credenciais. Os atacantes usaram as credenciais roubadas para bloquear os desenvolvedores de suas contas da NPM e publicar novas versões dos pacotes populares com código malicioso incorporado. Josh Junon (nome da conta da NPM “QIX”), um dos mantenedores comprometidos, publicado em sites de mensagens sociais que ele havia sido invadido e procurou os mantenedores da NPM para ajudar na retificação do problema. O malware em si era um interceptador baseado em navegador que captura e altera o tráfego de rede e o aplicativo do navegador funciona injetando-se em processos-chave, como funções de busca de dados e interfaces de carteira, para manipular solicitações e respostas. Os atacantes fizeram um bom trabalho ao disfarçar os detalhes do pagamento, redirecionando para um destino controlado pelo atacante. Para o usuário, parece que a transação de criptografia foi concluída com sucesso até que o usuário perceba que a criptografia não atingiu o local pretendido.
- O que os atacantes fizeram. Os atacantes passaram pelo problema de ofuscar o código malicioso. Além disso, o aspecto de engenharia social do incidente foi convincente. O e-mail de “support@npmjs.help” pediu ao desenvolvedor que redefini suas credenciais de autenticação de dois fatores (2FA). O link no email é redirecionado para o que parecia ser um site legítimo da NPM. Inconscientemente, o desenvolvedor forneceu suas credenciais legítimas ao site de propriedade do atacante e não perceberia o compromisso até que eles tentaram voltar à sua conta do NPM. Os pesquisadores da JFrog, uma empresa de segurança, notaram que Outros mantenedores também foram vítimas para a mesma campanha de phishing e que pacotes adicionais de NPM foram comprometidos e começaram a notificar os mantenedores.
- O impacto. No geral, 2,5 milhões de versões de pacotes comprometidas foram baixadas. Pesquisadores de Arkham, uma plataforma de análise de blockchain, conseguiram rastrear as transações de criptografia na carteira dos atacantes, que, como de Na manhã de quinta -feira passada, estava apenas em US $ 1.048,36. A janela entre o compromisso da conta do NPM, o mantenedor percebendo que foi impactado e os relatórios on -line das equipes de pesquisa de segurança cibernética foi curta, o que ajudou a mitigar o ataque geral. Além disso, os atacantes comprometeram vários pacotes e mantenedores, o que é improvável que passasse despercebido. Além disso, felizmente, o malware exigia que uma transação de criptografia fosse iniciada no navegador do usuário em comparação com apenas coletando mais informações que poderiam ter sido usadas para se mover lateralmente dentro de uma organização para um dia de pagamento maior.
Campanha Ghostaction
No Campanha “Ghostaction”mais de 3.325 segredos foram roubados em 817 repositórios do GitHub, afetando 327 usuários.
- A fraqueza da cadeia de suprimentos de software. Os atacantes foram capazes de empurrar o que parecia ser um compromisso inócuo intitulado “Adicione o fluxo de trabalho de segurança de ações do GitHub” aos repositórios do GitHub, tanto públicos quanto privados. Quando a ação do Github foi acionada, os segredos foram exfiltrados e enviados para um domínio controlado pelo atacante.
- O que os atacantes fizeram. Os atacantes fizeram sua lição de casa. Eles revisaram os repositórios para ver quais segredos estavam em uso e apenas exfiltraram os mais impactantes para permanecer sob o radar. Como os invasores foram capazes de acessar as contas de usuário do GitHub não foram divulgadas. Possivelmente, os usuários foram vítimas de uma campanha de engenharia social, como foi o caso na campanha de giz e depuração, ou talvez credenciais ou tokens de usuário tenham sido roubados ou vazados online. Outro cenário possível é que a conta de usuário do GitHub pode não estar usando o 2FA e estava reutilizando uma senha ou sujeita a um recheio de credenciais. Isso é improvável, no entanto, como o Gihub aplica 2FA no github.com para a maioria dos usuários contribuintes.
- O impacto. Um potpourri de segredos foi exfiltrado, incluindo credenciais do Docker Hub, tokens de acesso pessoal do GitHub, chaves de acesso da AWS, tokens NPM e credenciais de banco de dados. De acordo com GitGurdianque inicialmente relatou o ataque, os segredos estavam sendo explorados ativamente. A boa notícia é que nenhum pacotes de código aberto parecia estar comprometido, mas vários projetos de NPM e PyPI foram considerados em risco.
Tome medidas agora para proteger sua cadeia de suprimentos de software
Esses ataques provam que todo o software utilizado pela sua organização, mesmo o software como serviço, é um risco de segurança. Manters de pacotes populares de código aberto, contas de usuário do GitHub comprometidas e código malicioso em pacotes de código aberto são apenas os exemplos mais recentes de fraquezas da cadeia de suprimentos de software. Não espere pelo próximo ataque. Em vez de:
- Obtenha visibilidade na sua cadeia de suprimentos de software. Antes de você pode Prenda a cadeia de suprimentos de softwarevocê primeiro precisa entender quais componentes compõem a cadeia de suprimentos. Os sistemas de gerenciamento de ativos de TI e gerenciamento de ativos são bons lugares para começar a entender o cenário do seu software. Isso inclui todo o software usado no processo de desenvolvimento, incluindo ferramentas e plug -ins, como IDEs, sistemas de gerenciamento de código -fonte, ferramentas de construção e pipelines de CI/CD. Para qualquer software que você compra, exige prospecção de práticas recomendadas, incluindo um Letra de materiais de software (SBOM). Monitore os SBOMs para rastrear relacionamentos de dependência, alterações de licença, bibliotecas de fim de vida e vulnerabilidades recém-divulgadas.
- Selecione dependências seguras de terceiros. Permite apenas componentes de código aberto e de terceira partida seguros e saudáveis aprovados a serem usados ou baixados utilizando um Análise de composição de software (SCA). Automatize o SCA para executar solicitações de puxar, compilações, repositórios de artefatos e no pipeline do CI e digitalizar o código -fonte e os artefatos. Além disso, defina as políticas para permanecer atualizadas nas bibliotecas, mas também permitir o tempo “Simmer”. Por exemplo, aguarde duas semanas a partir de quando o pacote mais recente for publicado antes de atualizar para essa versão. Utilize um firewall de dependência para bloquear ou colocar em quarentena pacotes suspeitos.
- Proteja os pipelines de desenvolvimento de software. Aplicar Zero Princípios de confiança para pipelines Com autenticação multifatorial resistente a phishing, digitalizações para configurações incorretas, proteção de ramificação que aplica revisões de código, criptografia para dados sensíveis e digitalizações para segredos e permissões regular de acesso ao repositório. Utilize um gerente de segredos que fornece credenciais just-in-time, políticas de acesso granular para credenciais de escopo por pouco e alertas sobre atividades suspeitas.
- Crie uma estratégia de software de código aberto corporativo. O Software de código aberto (OSS) é um ótimo acelerador para inovação e pode até ajudar na contratação e retenção de desenvolvedores, mas há considerações de segurança, operacional e legal. Portanto, verifique se sua organização tem um Estratégia OSS. Isso deve incluir o envolvimento de sua equipe jurídica para identificar as licenças OSS que atendem ao apetite por risco comercial. Crie um plano para suas equipes de desenvolvimento contribuírem com os projetos de código aberto, como executar testes de segurança e remediar vulnerabilidades. Isso aumenta a postura de segurança do projeto de código aberto e dá um aviso antecipado a quaisquer problemas.
As violações da cadeia de suprimentos de software podem ter consequências significativas, incluindo a perda de confiança do cliente, danos à reputação da marca, ação legal, diminuição da receita e aumento dos custos de seguro. Mas esses riscos são evitáveis. Tome medidas proativas definindo e agindo claramente sobre suas responsabilidades, insistindo na transparência e integrando medidas de segurança em todas as fases do ciclo de vida.
Deseja se aprofundar em proteger sua cadeia de suprimentos de software? Ler O futuro da segurança da cadeia de suprimentos de software e agendar uma sessão de orientação ou investigação comigo.