Campanha ativa da Coreia do Norte contra pesquisadores de segurança

• O Threat Analysis Group (TAG), do Google, confirmou recentemente um ataque direcionado a pesquisadores de segurança, no qual foi explorada uma vulnerabilidade zero-day.
  • A vulnerabilidade zero-day foi reportada ao fornecedor afetado, e uma correção está em andamento.
• Os atacantes norte-coreanos interagiram ativamente com seus alvos por meio de redes sociais como o Twitter, construindo relacionamentos.
  • Em um caso real, mantiveram conversas durante meses com um pesquisador de segurança sobre temas de interesse mútuo, acumulando confiança.
  • Depois, migraram para um aplicativo de mensagens criptografadas e enviaram um arquivo malicioso contendo pelo menos uma vulnerabilidade zero-day em um pacote de software popular.
• Quando a exploração tinha sucesso, o shellcode verificava a presença de máquina virtual e enviava diversos dados ao servidor do atacante; isso foi implementado de forma semelhante a ataques anteriores da Coreia do Norte explorando vulnerabilidades.
• Além dos ataques direcionados por meio de vulnerabilidades zero-day, também desenvolveram uma ferramenta open source para engenharia reversa e a publicaram no Github.
  • O programa foi publicado pela primeira vez em 30 de setembro de 2022 e, desde então, foi desenvolvido ativamente, recebendo várias atualizações.
  • No entanto, a ferramenta continha um backdoor capaz de baixar e executar código arbitrário a partir do servidor do atacante.
  • O TAG recomenda que, caso essa ferramenta tenha sido usada, o sistema seja inspecionado e, se necessário, o sistema operacional seja reinstalado.
• Todos os sites e domínios maliciosos identificados foram adicionados ao Safe Browsing do Google, e alertas de ataque com apoio governamental foram enviados às contas do Google que podem ter sido afetadas.
  • Também foram divulgados todos os domínios, arquivos e contas maliciosos, como dbgsymbol, blgbeach e @Paul091_.

[kuroneko]

• Thread no HN

Ataques direcionados já são assustadores, mas acho que temos que tomar ainda mais cuidado com a parte em que colocaram código malicioso em um projeto open source.

Pelo visto, o código-fonte da ferramenta em si era normal, mas os arquivos incluídos no GitHub Release continham código malicioso.
Disseram que havia mais de 200 estrelas no GitHub...

De repente, estão surgindo várias notícias de segurança em sequência. Acho que todos precisamos prestar mais atenção à segurança.

[sixmen]

Achei que pelo menos o código-fonte ainda daria para verificar, mas não passou pela minha cabeça que ele poderia ser diferente do Release. Segurança realmente não tem fim...

[kunggom]

Isso também parece ser um tipo de ataque à cadeia de suprimentos.
Por coincidência, no caso do Go 1.21.0, lançado exatamente 1 mês atrás, eles publicaram no blog um post dizendo que, pela primeira vez, o resultado da build do próprio toolchain era totalmente reproduzível. Os dois primeiros parágrafos desse texto são os seguintes.

Perfectly Reproducible, Verified Go Toolchains

Um dos principais benefícios do software de código aberto é que qualquer pessoa pode ler o código-fonte e inspecionar o que ele faz. Mas, como a maioria dos softwares, inclusive os de código aberto, é baixada na forma de binários compilados, a inspeção se torna muito mais difícil. Para um invasor executar um ataque à cadeia de suprimentos contra um projeto de código aberto, a forma menos perceptível é substituir os binários distribuídos sem alterar o código-fonte.

A melhor maneira de se defender desse tipo de ataque é tornar as builds de software de código aberto reproduzíveis, ou seja, fazer com que toda build iniciada a partir do mesmo código-fonte gere sempre a mesma saída. Assim, qualquer pessoa pode compilar e recompilar a partir do código-fonte real e verificar se o binário recompilado é bit a bit idêntico ao binário publicado, confirmando que não há alterações ocultas no binário distribuído. Essa abordagem prova que o binário não contém backdoors nem outras modificações ausentes no código-fonte, sem precisar desmontá-lo ou inspecionar seu interior. Como qualquer pessoa pode verificar o binário, grupos independentes podem detectar e relatar ataques à cadeia de suprimentos com facilidade. (tradução do DeepL)

Eu me perguntava por que havia essa preocupação, mas parece que esse tipo de ataque já vinha sendo realizado em segredo desde cerca de 1 ano atrás. Ah, que mundo sombrio…

[kuroneko]

Eu também tendo a confiar um pouco mais quando algo é publicado no GitHub junto com o código... mas vou ter que tomar cuidado.
No fim, será que não tem outro jeito além de sempre revisar o código e fazer o build por conta própria...

[kuroneko]

Resumo por IA do tópico no HN

• 0xDEAFBEAD: Sugere ao Github adicionar banners de aviso em repositórios que contenham malware como esta ferramenta.
• zb3: Lembra que não se deve confiar cegamente em código no GitHub só porque o autor parece confiável.
• nneonneo: Acha que a fonte parece limpa, mas os binários podem estar com backdoor, então o malware provavelmente estava no release binário, não no código-fonte em si.
• bowmessage: Aponta uma função suspeita de atualização automática que pode baixar malware de um domínio controlado pelo atacante.
• gregsadetsky: Descobre que o repositório espelho da ferramenta ainda funciona e explica como o processo de atualização permite a infecção.
• codetrotter: Forneceu um arquivo do repositório original antes de ele ser removido.
• dantillberg: Descreve o código de atualização automática que baixa e executa arquivos a partir de uma URL.
• bdowling: No início entendeu o problema de forma errada, mas depois esclareceu que a questão era a URL de atualização controlada pelo atacante.
• saagarjha: Acha que o zero-day estava na funcionalidade do software que executava código do atacante por meio do recurso de atualização.
• rightbyte: Questiona se realmente há evidências para afirmar de forma conclusiva que foi obra da Coreia do Norte.