Ataque à cadeia de suprimentos 3CX: lições aprendidas

Os malfeitores primeiro comprometeram um pacote de software, X_TRADER, de uma empresa chamada Tecnologias de Negociação sediada em Chicago, IL. O software continha malware ( VEILEDSIGNAL backdoor) injetado. O instalador foi assinado digitalmente com um certificado de assinatura de código válido. Maus atores possivelmente invadiram a construção pipeline até 2021 e modificou o software antes de ser empacotado e assinado. Este foi o primeiro salto no ataque à cadeia de abastecimento. Em março de 2022, isso era relatado no contexto das operações DreamJob também conhecido como BLINDINGCAN e Apple Jeus, visando organizações sediadas nos EUA nos setores de mídia de notícias, TI, criptomoeda e fintech.

Este software foi retirado em 2020 (!), mas estava disponível para download a partir de 2022. Um funcionário da 3CX o instalou em um computador pessoal. Os bandidos roubaram as credenciais corporativas do funcionário do computador comprometido. Curiosamente, o VEILEDSIGNAL usou uma URL no site da Trading Technologies para comando e controle (uma tática frequentemente usada para evitar a detecção).

Dois dias depois do comprometimento inicial, os malfeitores usaram a VPN corporativa para acessar os sistemas internos da 3CX. Eles usaram o proxy reverso FRP, uma ferramenta pública que poderia ser usada para o bem e para o mal, para se mover lateralmente. Eles sabiam o que fazer com a posição conquistada: comprometeram os sistemas de compilação do Windows e do macOS. Cada ambiente com ferramentas diferentes. Por exemplo, eles usaram a ferramenta SigFlip para injetar o shellcode criptografado RC4 no apêndice de assinatura do d3dcompiler_47.dll.

As atualizações de software para o aplicativo 3CX Desktop para Windows e macOS foram infectadas. Este foi o segundo salto neste (primeiro?) ataque à cadeia de suprimentos em várias etapas. A atualização de software para Windows, também devidamente assinada com um certificado de assinatura de código 3CX, descarta dois arquivos maliciosos, ffmpeg.dll e d3dcompiler_47.dll (com equivalente .dylib bibliotecas para macOS), que foram carregadas e executadas pelo benigno 3CXDesktopApp executável (por meio da técnica de carregamento de DLL lateral). O shellcode criptografado na segunda DLL carrega outra DLL que faz download de Armazenamento de ícones Repositório GitHub, um arquivo .ico contendo o servidor de Comando e Controle (C2) criptografado.

Havia mais de 20 domínios provisionados para isso, o que nos diz como o ataque à cadeia de suprimentos de software foi cuidadosamente planejado.

As conexões dos PCs das vítimas aos domínios C2 começaram em 06 de março de 2023 e terminaram em 29 de março.

Observe que (1) nenhum código-fonte em um repositório de código foi modificado, mas em vez disso, a carga útil do malware foi injetada durante a construção, (2) um código legítimo ffmpeg O DDL foi substituído por um malicioso e carregado por meio de carregamento de DLL lateral, e (3) um aplicativo VoIP popular foi transformado em uma arma com malware de vários estágios.

Como o incidente foi tratado

Parece que em 29 de março a 3CX recebeu relatórios de terceiros sobre um ator malicioso “explorando uma vulnerabilidade em seu produto”. As plataformas antimalware fizeram (parcialmente) seu trabalho.

Em 30 de março de 2023, o 3CX CISO, Pierre Jourdan, publicou uma alerta de segurança informando aos clientes e parceiros que seu aplicativo Electron (cliente de desktop) foi enviado após uma atualização com malware. A postagem lista as versões afetadas (para Windows e Mac), uma breve declaração sobre as medidas iniciais de contenção tomadas e uma recomendação rápida para continuar trabalhando com o cliente web em vez do cliente desktop contaminado.

Na IMO, a comunicação inicial, embora um pouco concisa, foi direta ao ponto. Não é fácil para nenhum fornecedor reconhecer que existe um sério problema de segurança que pode afetar muitos clientes. A empresa reconheceu o problema e imediatamente apontou um potencial culpado:

“Vale a pena mencionar – este parece ter sido um ataque direcionado de uma Ameaça Persistente Avançada, talvez até patrocinada pelo Estado, que executou um ataque complexo à cadeia de suprimentos e escolheu quem baixaria os próximos estágios de seu malware.”

A empresa ofereceu uma alternativa para manter o produto funcionando: utilizar o Aplicativo da Web progressivo ou PWA, em vez do aplicativo de desktop, com base no Elétron estrutura.

“Sugerimos fortemente que você use nosso aplicativo PWA. O aplicativo PWA é totalmente baseado na web e faz 95% do que o aplicativo Electron faz. A vantagem é que não requer instalação ou atualização e a segurança da web do Chrome é aplicada automaticamente.

A razão de termos dois aplicativos é que quando iniciamos o Electron App, a tecnologia PWA ainda não estava disponível. Agora está maduro e funcionando muito bem.”

Bem, o aplicativo da web também pode estar infectado e um PWA, por definição, pode executar código em service workers (código JavaScript) com acesso (restrito) a recursos locais. A postagem alegou que o PWA não estava infectado naquele momento. Podemos entender por que, em muitos dos mais de 277 comentários à postagem, alguns perguntaram se a alternativa PWA mencionada ou o próprio software do servidor PBX estava comprometido.

O mesmo dia, 3CX nomeou Mandiant para investigação, com mais instruções. Basicamente, ele instala atualização para

Aplicativo Win/Mac Desktop na instalação local, desinstale o aplicativo Electron para as versões afetadas e vá para a alternativa PWA. Isso não é necessariamente suficiente, pois o malware pode ter acesso aos sistemas afetados, persistir no malware ou até mesmo mover-se lateralmente. A remoção completa de malware não é tão fácil. Podemos compreender que, dada a urgência, nem sempre se encontra a melhor forma de lidar com um incidente… a menos que o cenário tenha sido previamente imaginado e identificadas medidas de remediação adequadas.

O processo de seguinte postagem, agora pelo CEO da empresa, tenta tranquilizar os clientes com o anúncio de uma atualização apenas de segurança para o DesktopApp. Algumas técnicas básicas de proteção, como hashing de senha, foram implementadas (“Pois é melhor do que nunca é tarde; nunca ter sucesso seria um período muito longo.”, Chaucer dixit em 1386.) Proteções específicas implementadas são melhores do que boas intenções e planos projetados… Mas como as senhas eram armazenadas anteriormente?

De qualquer forma, o Google invalidou o certificado de assinatura de código 3CX existente e os fornecedores de antivírus também bloquearam qualquer software assinado com esse certificado. Os instaladores MSI para a atualização do DesktopApp precisaram ser regenerados com um novo certificado de assinatura de código, o que levou algumas horas. Isso poderia ser esperado!

A 3CX implantou preventivamente um novo servidor de compilação. Isso é razoável: sem análise, não se sabia como o malware foi injetado.

No mesmo dia 1º de abril, o CEO postou um Atualização de incidentes de segurança. A postagem conta o que a empresa estava fazendo (conduzindo uma investigação completa e validando todo o código-fonte do software do lado do cliente). A segurança não pode esperar nem aos sábados.

Quando o incidente foi analisado e a infraestrutura do invasor conhecida, o repositório GitHub e os domínios dos servidores C2 usados ​​pelo APT foram removidos, eliminando efetivamente o malware.

Em abril 11th, o CISO postou o resultados iniciais da análise de incidentes. O APT UNC4736 ligado à Coreia do Norte foi citado pela primeira vez.

Na sexta-feira, 20 de abril, Mandiant postou o análise inicial do incidente. As regras de detecção YARA e Snort foram publicadas.

No mesmo dia, o CEO da 3CX publicou uma nova postagem, com o nome sugestivo “Ações, não palavras – Nosso Plano de Ação de Segurança em 7 Passos!”. O subtítulo é bastante interessante: “Garantindo o Futuro da 3CX após a primeira experiência em cascata ataque à cadeia de suprimentos de software em software.” As etapas da carta de segurança elaborada são:

• Fortalecendo múltiplas camadas de segurança de rede.

• Renovar cria segurança.

• Revisão contínua de segurança do produto.

• Aprimorando os recursos de segurança do produto.

• Realização de testes de penetração contínuos.

• Refinando o gerenciamento de crises e o plano de tratamento de alertas.

• Estabelecendo um novo departamento para operações e segurança de rede.

Os analistas estarão de olho neste programa louvável, de fato…

Consequências: como a indústria reagiu

Apenas algumas semanas se passaram desde que o incidente foi publicado. Mas a indústria está reagindo.

CVE-2023-29059 foi atribuído. Atualmente, possui uma pontuação de risco CVSSv7.8 de 3 (ALTO). A 3CX Produtos possui apenas 16 CVEs listados, o que parece bom quando comparado a fornecedores com níveis de implementação semelhantes. Mas este incidente não é a vulnerabilidade habitual de fato. Este é um ataque ativo direcionado por uma Ameaça Persistente Ativa (APT), como o CISO mais reconhecido.

O processo de CWE-506 “Código Malicioso Incorporado” que categoriza esse incidente não nos ajuda muito a entender como prevenir tais ataques à cadeia de suprimentos de software. Infelizmente, os bandidos têm muitas avenidas para entregar malware, com ataques à cadeia de suprimentos sendo a nova joia da coroa em seu arsenal. O CWE-506 deve ser melhorado para refletir os cenários atuais, incluindo aqueles baseados na violação do sistema de construção.

O APT, denominado UNC4736 pela Mandiant, usa táticas e técnicas semelhantes ao amplamente conhecido Lazarus Group (APT38), criado pelo Estado norte-coreano e pelos perpetradores da campanha de ransomware WannaCry de 2017. Tais laços entre maus atores nos estados stalinistas com horários de trabalho regulares são difíceis de estabelecer, mas pesquisadores de CrowdStrike e ESET constataram que as táticas, técnicas e procedimentos (TTPs) utilizados se assemelham aos de uso comum por Lazarus APT38. Compreender como eles operam é essencial para detecção, prevenção e erradicação.

Conhecer seus objetivos, envoltos em mistério, é ainda mais difícil.

Este ataque é importante o suficiente para que CISA Agência de Segurança Cibernética dos EUA emitiu uma consultivo com as postagens do fornecedor e links para múltiplas análises sobre o ataque à cadeia de suprimentos. Ler isso é relevante para profissionais de segurança cibernética.

O incidente nos lembra o ataque da SolarWinds. Dado o enorme impacto, muitos fornecedores correram para analisar os instaladores de produtos de desktop VoIP infectados. Mas este é o último passo. Mais detalhes são necessários para entender o que falhou na segurança dos sistemas de compilação das duas organizações afetadas e quais etapas os malfeitores tomaram para afetar esses sistemas de compilação e conseguiram inserir o malware durante a compilação. Caso contrário, este incidente se repetirá continuamente.

E agora, lições aprendidas!

Praticar um esporte coletivo ouvindo alguém de sua equipe explicando cada minuto de falha no jogo abala o espírito mais temperado. Mas aqui na Espanha todo mundo é técnico de futebol nacional! Então deixe-me atuar como Pep Guardiola, José Mourinho, Alex Ferguson e Arrigo Sacchi, todos juntos.

Aja como se seu sistema de construção estivesse sob fogo de artilharia pesada. Talvez você não consiga impedir que um funcionário instale software não autorizado em PCs de trabalho. Provavelmente, as equipes de engenharia poderão exigir políticas mais rígidas. Mas esteja atento ao construir e implantar pipeline. Se você entrega software aos clientes, a segurança na forma como você constrói o software deve ser tão importante quanto a segurança do produto de software.

Preparação para incidentes. É difícil, talvez estéril, antecipar os cenários mais prováveis ​​para incidentes de segurança. Devo aprender a usar um desfibrilador? Não, a menos que eu viva com uma propensão a usar cartõesiac prisão. Mas pelo amor de Deus! Esteja preparado para “reconstruir sua construção” do zero, com revogação + renovação de chaves, tokens de acesso, pares de chaves públicas e certificados.

Os sistemas de construção devem ter certas características: A tendência atual para construções em ambientes efêmeros, e com ambientes isolados/sem parâmetros/herméticos e até reproduzíveis poderia ser a estrutura para evitar ataques como o do 3CX Supply Chain Attack quando complementados com requisitos adicionais em outros sistemas na construção e implantação pipeline. Ver Requisitos de compilação do Google SLSA para referência.

A comunicação adequada é fundamental. A transparência é obrigatória. Minimizar o problema ou escondê-lo debaixo do tapete é a pior coisa que qualquer organização pode fazer. Os incidentes de segurança muitas vezes afetam mais a reputação do que outros ativos, e a má comunicação após a violação pode ser catastrófica.

Transforme problemas em oportunidades. Um bom incidente pode desencadear melhorias nos controles de segurança que nunca foram incluídas no rígido plano do produto. Até mesmo coisas essenciais, como hash de senha adequado e documentação de configuração/reforço de segurança, podem ser agendadas para o curto prazo. Mas para ataques à cadeia de suprimentos, fortalecendo os sistemas de construção e adicionando atestados e verificações de integridade em cada etapa da construção e implantação pipelinesão essenciais. Não deveria ser tão fácil para um invasor implantar tais mudanças no sistema de compilação.

Esteja preparado. Caso contrário, sua organização pode enfrentar uma ameaça existencial, como o ataque à cadeia de suprimentos de software 3cx.