Plugin do Obsidian é explorado para distribuir trojan de acesso remoto

 (cyber.netsecops.io)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • A campanha REF6598 distribui o RAT PHANTOMPULSE por meio de cofres compartilhados do Obsidian
  • Os alvos são profissionais de finanças e criptomoedas em Windows e macOS, atraídos via LinkedIn e Telegram
  • A infecção começa quando a sincronização de plugins da comunidade é ativada manualmente no cofre compartilhado
  • Os plugins maliciosos Shell Commands e Hider executam scripts, e o PHANTOMPULL carrega o RAT
  • O PHANTOMPULSE consulta o endereço de C2 em transações de Ethereum, dificultando o bloqueio

Fluxo do ataque

  • Acesso inicial e execução

    • A campanha REF6598 explora o aplicativo de notas Obsidian para distribuir o trojan de acesso remoto (RAT) PHANTOMPULSE, até então não documentado
    • Os atacantes se passam por representantes de venture capital, entram em contato com os alvos em sites de networking profissional e depois transferem a conversa para grupos privados no Telegram
    • Sob o pretexto de colaboração, induzem a vítima a participar de um cofre compartilhado do Obsidian hospedado na nuvem
    • O acesso inicial se enquadra em T1566.002 Spearphishing Link do MITRE ATT&CK
    • A infecção começa quando a vítima ativa manualmente, dentro do Obsidian, o recurso de sincronização de “Installed community plugins”
    • O cofre compartilhado contém versões maliciosas dos plugins legítimos do Obsidian Shell Commands e Hider, e a ativação de plugins da comunidade leva à execução de código
    • O plugin comprometido Shell Commands executa um script malicioso
    • A etapa que induz a ação do usuário para executar um arquivo malicioso corresponde a T1204.002 Malicious File

  • Etapas de infecção em Windows e macOS

    • No Windows, o plugin malicioso executa um script PowerShell, que então solta o loader PHANTOMPULL
    • No macOS, um processo semelhante ocorre por meio de AppleScript
    • Em seguida, o PHANTOMPULL descriptografa e executa a carga final, o RAT PHANTOMPULSE
    • Para evitar detecção baseada em arquivos, o PHANTOMPULSE executa a carga final diretamente na memória, o que se relaciona a T1055 Process Injection

Capacidades do PHANTOMPULSE e método de C2

  • Depois de ativado, o PHANTOMPULSE pode capturar teclas digitadas, tirar screenshots, exfiltrar arquivos e executar comandos arbitrários
  • A comunicação C2 é estruturada de uma forma que se enquadra em T1102.002 Bidirectional Communication
  • O PHANTOMPULSE consulta as transações mais recentes de Ethereum de um endereço de carteira embutido no código
  • O endereço IP do servidor C2 está incluído nos dados dessa transação, e o malware usa isso para identificar o servidor do qual receberá comandos
  • Esse método fornece um mecanismo descentralizado e resistente à censura para descoberta do endereço de C2, dificultando a interrupção da infraestrutura da ameaça

Impacto

  • Se a infecção for bem-sucedida, os atacantes podem obter acesso total ao sistema da vítima
  • Profissionais dos setores financeiro e de criptomoedas podem ter dados corporativos sensíveis, propriedade intelectual, estratégias de negociação, chaves de carteiras de criptomoedas e credenciais de corretoras roubados
  • Como a estrutura mira tanto Windows quanto macOS, o alcance potencial de vítimas é maior
  • O uso de C2 baseado em blockchain demonstra alto grau de sofisticação e dificulta a desarticulação da infraestrutura da ameaça

Indicadores de detecção

  • Processos

    • Obsidian.exe
    • É necessário monitorar se o Obsidian gera processos filhos como powershell.exe, cmd.exe e osascript

  • Padrões de linha de comando

    • powershell -ExecutionPolicy Bypass
    • Execuções de PowerShell iniciadas por aplicativos não convencionais como o Obsidian são um sinal suspeito

  • Tráfego de rede

    • É necessário monitorar conexões de saída para nós ou gateways da blockchain Ethereum vindas de processos inesperados
    • Essas conexões podem indicar que o PHANTOMPULSE está tentando descobrir o endereço de C2

  • Caminhos de arquivo

    • [Vault]/.obsidian/plugins/
    • É preciso verificar se arquivos estão sendo criados ou modificados no diretório de plugins do Obsidian fora do marketplace oficial de plugins

Detecção e resposta

  • Monitoramento de processos: são necessárias regras de EDR para detectar e alertar quando o processo Obsidian executar interpretadores de linha de comando como powershell.exe, cmd.exe, bash e osascript
  • Treinamento de usuários: usuários de setores de alto risco devem estar cientes dos riscos de engenharia social e do abuso de recursos de ferramentas colaborativas, como cofres compartilhados e plugins
  • Controle de aplicações: quando possível, políticas de controle de aplicações devem restringir a instalação e execução de plugins da comunidade não aprovados em apps como o Obsidian
  • Monitoramento de rede: em endpoints onde essa atividade não é esperada, é necessário observar consultas DNS anômalas relacionadas a serviços de blockchain ou conexões diretas por IP

Medidas de mitigação

  • Validação de plugins da comunidade: é preciso ter extremo cuidado ao ativar plugins de terceiros ou da comunidade em qualquer aplicação, instalando apenas a partir de marketplaces oficiais confiáveis e revisando as permissões
  • Desativar sincronização automática em cofres não confiáveis: ao se conectar a cofres do Obsidian de origem desconhecida ou não confiável, não se deve ativar a sincronização de plugins
  • Princípio do menor privilégio: aplicações como o Obsidian devem ser executadas com privilégios de usuário padrão, e não de administrador, para limitar o impacto de uma invasão
  • Segurança de endpoint: implantar soluções atualizadas de EDR e antivírus para detectar e bloquear execução suspeita de scripts e técnicas de injeção em processos

Mapeamento de mitigação MITRE ATT&CK

  • User Training
    • Treinar usuários para reconhecer táticas de engenharia social e desconfiar de convites de colaboração não solicitados é a principal defesa contra esse vetor de ataque
  • Execution Prevention
    • Usar controle de aplicações para impedir que apps como o Obsidian executem scripts como PowerShell pode interromper a cadeia de ataque
    • Mapeamento D3FEND: D3-EAL
  • Software Configuration
    • Configurar a aplicação para desativar a instalação de plugins de terceiros ou exigir aprovação rigorosa reduz a superfície de ataque
    • Mapeamento D3FEND: D3-ACH

Referências

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Comentários do Hacker News

  • Sou o CEO do Obsidian. Uma grande atualização sobre segurança de plugins vai sair em breve, e acho que vai resolver muitas das preocupações levantadas neste tópico
    É um problema difícil, mas estamos trabalhando nisso. Dito isso, o título induz ao erro. Este post trata de um ataque de engenharia social no qual o usuário precisa rejeitar manualmente vários avisos de segurança do Obsidian e, até onde eu sei, está no nível de prova de conceito, sem relatos de vítimas reais

    • Eu digo há anos que os plugins não são seguros. Lembro vividamente de ter sido atacado no Discord por dizer que plugins têm acesso total ao disco. Já é tarde demais
    • Agora vai existir uma opção para, mesmo com plugins ativados, mover a pasta .obsidian para fora do vault e ignorar por padrão essa pasta dentro do vault?
    • Não sei o quão difícil seria, mas adicionar uma caixa de diálogo de permissões como no Android ajudaria muito. 99% dos plugins do Obsidian não precisam de acesso total ao disco, nem de acesso à internet
    • Abrir o código-fonte do cliente também resolveria muitas preocupações
    • Esse “rejeitar ativamente vários avisos de segurança” significa algo como pop-ups? A maioria das pessoas aprova esse tipo de coisa sem pensar muito
      Acho que plugins/extensões deveriam, por padrão, ser um pouco mais difíceis de executar. Entendo que uma barreira extra antes de usar plugins cria atrito para o usuário, mas realmente não acho que exista uma forma de executar com segurança código arbitrário não revisado sem sandbox ou outras restrições

  • Esse é um título enganoso. Faz parecer outro ataque de cadeia de suprimentos em que um plugin legítimo foi comprometido e passou a distribuir malware
    Na realidade, a vítima é convidada para colaborar em um vault sincronizado, e esse vault já contém um plugin não oficial preparado para entregar o RAT. É uma história completamente diferente

    • O que exatamente é enganoso?
      Está escrito: “Novel Campaign Abuses Obsidian Note-Taking App to Target Finance and Crypto Professionals with PHANTOMPULSE RAT”. É um novo ataque, abusa do Obsidian, mira um grupo específico, e o RAT está no vault, então parece uma formulação correta

  • Gosto muito do Obsidian e uso todo dia, mas não uso plugins da comunidade porque o sistema de permissões não é suficiente
    Espero o dia em que plugins vão declarar quais permissões precisam, e isso será mostrado ao usuário. Acho que a equipe do Obsidian vai tratar esse problema com seriedade e estou curioso para ver o que vão lançar. Eu confio neles, mas é surpreendente que tenha sido projetado assim desde o começo, sem um sistema melhor de permissões e sandbox

    • Comecei a usar o Obsidian porque fiquei cansado de usar o VS Code para ver arquivos Markdown. Ainda bem que não precisei instalar plugins. Pelo visto, essa parte parece um projeto bem ruim

  • “A vítima é instruída a ativar a função de sincronização ‘Installed community plugins’”
    O Obsidian tem mecanismos de proteção para impedir esse tipo de ataque, e a vítima foi convencida a ignorá-los. Foi apenas um caso bem-sucedido de engenharia social. Como esse ataque não explorou uma vulnerabilidade do Obsidian nem do sistema de plugins, não gosto de ver o Obsidian ser arrastado por títulos assim

    • Não concordo. https://obsidian.md/help/plugin-security#Plugin+capabilities
      “Por limitações técnicas, o Obsidian não consegue restringir de forma confiável plugins a permissões específicas ou níveis de acesso. Portanto, plugins herdam o mesmo nível de acesso do Obsidian.”
      Plugins da comunidade podem acessar os arquivos do computador, se conectar à internet e até instalar programas adicionais. O Obsidian não tem mecanismo de proteção nenhum; instalar um plugin equivale a conceder acesso total ao computador. Isso era só uma questão de tempo, e eu diria que, por volta de 2010, lançar um sistema de plugins assim já era indefensavelmente descuidado
    • Uso bastante e gosto do Obsidian, mas acho que o valor dessa divulgação está em espalhar consciência sobre plugins e mostrar o vetor de ataque
      Usuários menos experientes podem pensar: “É só um monte de arquivos Markdown. Provavelmente nem preciso me preocupar tanto com malware”

  • Por que quase todo sistema de plugins é projetado de forma tão frouxa? Fico me perguntando se é porque não existe um bom framework de desenvolvimento de plugins que ofereça isolamento/permissões de verdade, então dá trabalho demais, ou se é porque as pessoas simplesmente não conhecem amplamente o que é necessário e só aprendem depois que o próprio sistema é abusado. É os dois, ou há outro motivo?

    • No centro disso está o trade-off entre funcionalidade e segurança. Você pode dar ao usuário capacidades poderosas para fazer coisas incríveis, ou pode remover a maior parte das capacidades significativas e tornar tudo seguro. Em geral, as pessoas preferem funcionalidade a segurança
      Outro problema é que segurança é difícil, e dar acesso amplo com alguns guard-rails básicos é fácil
    • É preciso definir um framework e componentes de segurança que atendam ao que todos os plugins vão precisar, e isso leva tempo para projetar, implementar, verificar e manter
      É muito mais fácil simplesmente pular essa parte. Então sim, dá trabalho demais, e mais especificamente exige uma liderança orientada à segurança que entenda que esse trabalho é grande, mas é o trabalho certo a fazer
    • Eu apostaria que é por falta de recursos para projetar uma interface adequada e uma web stack decente. Esse tipo de software é escrito em frameworks JS de alto nível, então por padrão acaba tendo padrões ruins de fluxo de dados e muitas vezes segue apenas o que é viável na prática, e não um projeto intencional
      Para fazer de forma intencional, talvez fosse preciso descer camadas de abstração e manter forks customizados desses frameworks. Então provavelmente os plugins foram projetados como se você estivesse instanciando uma biblioteca e passando parte do contexto usado pelo app. No fim, é a forma mais simples que funciona. O hack divulgado não fala de uma “vulnerabilidade” específica; plugins do Obsidian sempre estiveram em modo deus, e o atacante só enganou as pessoas para usá-los assim. É ridículo culpar o usuário no fim quando há essencialmente execução remota de código esperando atrás de alguns pop-ups. Os desenvolvedores deveriam ter vergonha
    • Até plugins do navegador Chrome têm problemas de segurança parecidos. Mesmo com bilhões de dólares e muitos desenvolvedores brilhantes investidos nisso
      É parecido com criar uma app store dentro de um app. A Apple App Store reduz apps maliciosos impondo limites muito rígidos sobre quem pode publicar o quê e também colocando uma barreira paga
    • Por que um sistema de plugins teria que significar imediatamente sandbox?

  • Mesmo sendo engenharia social, se o sistema de plugins é projetado de um jeito que permite isso, então essa plataforma é completamente inadequada como ferramenta de compartilhamento
    É bom saber, mas para mim isso se aproxima mais de “nunca aceite um vault compartilhado do Obsidian e exija uma exportação em texto simples” do que de “você só precisa manter essa configuração correta para usar um vault compartilhado do Obsidian”

  • Quando comecei a usar o Obsidian, os vídeos no YouTube que vi recomendavam usar plugins da comunidade. Mesmo com esse tipo de aviso, eu provavelmente teria ativado plugins da comunidade
    Um desenvolvedor de plugin que começou com boas intenções pode se tornar malicioso depois, e o usuário não tem como saber. Mesmo sendo desenvolvedor e conhecendo esses riscos, acho que eu teria ativado a opção de plugins da comunidade, então talvez minha tolerância a risco seja alta. Espero ser minoria e que esse não seja o comportamento da maioria dos usuários

  • Esse tipo de coisa está se espalhando quase como uma epidemia. Nem todo ataque ou exploit, especialmente ataques de engenharia social, precisa de um nome estilo Metal Gear ou de um site

  • Lendo o conteúdo, o problema não começou com um plugin da loja do Obsidian, mas com um vault malicioso que a pessoa foi induzida a abrir

  • Eu executo o Obsidian com permissões restritas. Sem acesso à rede, sem acesso ao sistema de arquivos fora do próprio diretório
    Só habilito o acesso à rede ao atualizar plugins/temas. Faço o mesmo com outros aplicativos que podem executar código não confiável

    • Pode compartilhar como você faz esse sandbox?