Un plugin Obsidian exploité pour déployer un cheval de Troie d’accès à distance

 (cyber.netsecops.io)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • La campagne REF6598 déploie le RAT PHANTOMPULSE via des coffres partagés Obsidian
  • Les cibles sont des professionnels de la finance et des cryptomonnaies sous Windows et macOS, attirés via LinkedIn et Telegram
  • L’infection commence lorsque la synchronisation des plugins communautaires est activée manuellement depuis un coffre partagé
  • Les plugins malveillants Shell Commands et Hider exécutent des scripts, puis PHANTOMPULL charge le RAT
  • PHANTOMPULSE vérifie l’adresse C2 via des transactions Ethereum, ce qui complique son blocage

Chaîne d’attaque

  • Accès initial et exécution

    • La campagne REF6598 exploite l’application de prise de notes Obsidian pour distribuer PHANTOMPULSE, un cheval de Troie d’accès à distance (RAT) jusque-là non documenté
    • Les attaquants se font passer pour des contacts liés au capital-risque sur des plateformes de réseautage professionnel, puis déplacent la conversation vers un groupe Telegram privé
    • Sous prétexte de collaboration, ils incitent les cibles à rejoindre un coffre Obsidian partagé et hébergé dans le cloud
    • L’accès initial correspond à T1566.002 Spearphishing Link dans MITRE ATT&CK
    • L’infection démarre lorsque la victime active manuellement la fonction de synchronisation « Installed community plugins » dans Obsidian
    • Le coffre partagé contient des versions malveillantes des plugins Obsidian légitimes Shell Commands et Hider, et l’activation des plugins communautaires entraîne l’exécution de code
    • Le plugin Shell Commands compromis exécute un script malveillant
    • L’étape qui pousse l’utilisateur à lancer un fichier malveillant correspond à T1204.002 Malicious File

  • Étapes d’infection sous Windows et macOS

    • Sous Windows, le plugin malveillant exécute un script PowerShell, qui dépose ensuite le loader PHANTOMPULL
    • Sous macOS, une procédure similaire est réalisée via AppleScript
    • PHANTOMPULL déchiffre ensuite et exécute PHANTOMPULSE, la charge utile finale du RAT
    • Pour éviter la détection basée sur les fichiers, PHANTOMPULSE exécute directement la charge utile finale en mémoire, ce qui est lié à T1055 Process Injection

Capacités de PHANTOMPULSE et mécanisme C2

  • Une fois activé, PHANTOMPULSE peut capturer les frappes clavier, prendre des captures d’écran, exfiltrer des fichiers et exécuter des commandes arbitraires
  • La communication C2 est mise en place selon une méthode relevant de T1102.002 Bidirectional Communication
  • PHANTOMPULSE consulte les dernières transactions Ethereum d’une adresse de portefeuille codée en dur
  • L’adresse IP du serveur C2 est incluse dans les données de cette transaction, ce qui permet au malware d’identifier le serveur auprès duquel recevoir ses commandes
  • Cette méthode fournit un mécanisme de découverte d’adresse C2 décentralisé et résistant à la censure, rendant plus difficile la neutralisation de l’infrastructure malveillante

Impact

  • En cas d’infection réussie, les attaquants peuvent obtenir un accès complet au système de la victime
  • Les professionnels de la finance et des cryptomonnaies risquent le vol de données d’entreprise sensibles, de propriété intellectuelle, de stratégies de trading, de clés de portefeuille crypto et d’identifiants d’exchange
  • L’architecture visant à la fois Windows et macOS élargit le périmètre potentiel des victimes
  • L’usage d’un C2 basé sur la blockchain témoigne d’un haut niveau de sophistication et complique la perturbation de l’infrastructure de menace

Indicateurs de détection

  • Processus

    • Obsidian.exe
    • Il faut surveiller si Obsidian crée des processus fils comme powershell.exe, cmd.exe ou osascript

  • Motifs de ligne de commande

    • powershell -ExecutionPolicy Bypass
    • Une exécution de PowerShell lancée depuis une application non standard comme Obsidian constitue un signal suspect

  • Trafic réseau

    • Il faut surveiller les connexions sortantes vers des nœuds ou passerelles de blockchain Ethereum depuis des processus inattendus
    • De telles connexions peuvent indiquer que PHANTOMPULSE tente de vérifier l’adresse C2

  • Chemins de fichiers

    • [Vault]/.obsidian/plugins/
    • Il faut vérifier si des fichiers sont créés ou modifiés dans le répertoire des plugins Obsidian en dehors de la marketplace officielle des plugins

Détection et réponse

  • Surveillance des processus : des règles EDR sont nécessaires pour détecter et alerter lorsque le processus Obsidian exécute des interpréteurs de ligne de commande comme powershell.exe, cmd.exe, bash ou osascript
  • Sensibilisation des utilisateurs : les utilisateurs des secteurs à haut risque doivent être conscients des risques de social engineering et de l’abus des fonctions des outils collaboratifs, comme les coffres partagés et les plugins
  • Contrôle des applications : lorsque c’est possible, des politiques de contrôle des applications doivent limiter l’installation et l’exécution de plugins communautaires non approuvés dans des applications comme Obsidian
  • Supervision réseau : il faut surveiller les requêtes DNS anormales ou les connexions IP directes liées à des services blockchain depuis des terminaux où cette activité n’est pas attendue

Mesures d’atténuation

  • Vérification des plugins communautaires : il faut faire preuve d’une grande prudence lors de l’activation de plugins développés par des tiers ou par la communauté dans toute application, n’installer que depuis une marketplace officielle de confiance et examiner les autorisations demandées
  • Désactiver la synchronisation automatique pour les coffres non fiables : il ne faut pas activer la synchronisation des plugins lors de la connexion à des coffres Obsidian provenant de sources inconnues ou non fiables
  • Principe du moindre privilège : les applications comme Obsidian doivent être exécutées avec des droits d’utilisateur standard et non des privilèges administrateur afin de limiter l’impact d’une compromission
  • Sécurité des terminaux : il faut déployer des solutions EDR et antivirus à jour pour détecter et bloquer les exécutions de scripts suspectes et les techniques d’injection de processus

Correspondance des mesures d’atténuation MITRE ATT&CK

  • User Training
    • Former les utilisateurs à reconnaître les tactiques de social engineering et à se méfier des invitations à collaborer non sollicitées constitue une défense majeure contre ce vecteur d’attaque
  • Execution Prevention
    • L’usage du contrôle des applications pour empêcher des applications comme Obsidian d’exécuter des scripts tels que PowerShell peut rompre la chaîne d’attaque
    • Correspondance D3FEND : D3-EAL
  • Software Configuration
    • Configurer les applications pour désactiver l’installation de plugins tiers ou exiger une validation stricte réduit la surface d’attaque
    • Correspondance D3FEND : D3-ACH

Références

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Hacker News

  • Je suis le CEO d’Obsidian. Une grosse mise à jour concernant la sécurité des plugins arrive bientôt, et je pense qu’elle pourra répondre à une grande partie des inquiétudes exprimées dans ce fil
    C’est un problème difficile, mais nous y travaillons. Cela dit, le titre est trompeur. Cet article parle d’une attaque d’ingénierie sociale dans laquelle l’utilisateur doit lui-même refuser plusieurs avertissements de sécurité d’Obsidian, et à ma connaissance cela reste au niveau de la preuve de concept, sans signalement de dommages réels

    • Je dis depuis des années que les plugins ne sont pas sûrs. Je me souviens très bien m’être fait attaquer sur Discord après avoir dit que les plugins avaient un accès complet au disque. C’est trop tard
    • Est-ce que cela signifie qu’à l’avenir, même si les plugins sont activés, il y aura une option pour déplacer le dossier .obsidian hors du vault et ignorer par défaut ce dossier à l’intérieur du vault ?
    • Je ne sais pas à quel point ce serait difficile, mais ajouter des boîtes de dialogue de permissions comme sur Android aiderait énormément. 99 % des plugins Obsidian n’ont besoin ni d’un accès complet au disque, ni d’un accès à Internet
    • Rendre le code source du client public aiderait aussi à dissiper beaucoup d’inquiétudes
    • Que signifie exactement « refuser activement plusieurs avertissements de sécurité » ? Des pop-ups, par exemple ? La plupart des gens les valident sans trop réfléchir
      À mon avis, il faudrait rendre l’exécution des plugins/extensions un peu plus difficile par défaut. Je comprends que des barrières supplémentaires avant d’utiliser un plugin créent de la friction, mais je ne pense pas qu’il existe en pratique de moyen sûr d’exécuter du code arbitraire non vérifié sans sandbox ni autres restrictions

  • C’est un titre trompeur. Il donne l’impression qu’un plugin légitime a été compromis pour distribuer un malware, comme dans une nouvelle attaque de supply chain
    En réalité, la victime est invitée à collaborer sur un vault synchronisé, dans lequel se trouve déjà un plugin non officiel servant à livrer le RAT. Ce n’est pas du tout la même histoire

    • En quoi est-ce trompeur ?
      Le titre dit : « Novel Campaign Abuses Obsidian Note-Taking App to Target Finance and Crypto Professionals with PHANTOMPULSE RAT ». Il s’agit bien d’une nouvelle attaque, qui détourne Obsidian, cible un groupe précis, et où le RAT se trouve dans le vault ; la formulation me semble donc correcte

  • J’aime beaucoup Obsidian et je l’utilise tous les jours, mais je n’utilise pas les plugins communautaires parce que le système de permissions n’est pas suffisant
    J’espère qu’un jour les plugins devront déclarer les permissions dont ils ont besoin et que cela sera affiché à l’utilisateur. Je pense que l’équipe d’Obsidian prend ce problème au sérieux et j’ai hâte de voir ce qu’elle va proposer. J’ai confiance, mais il est surprenant que le produit ait été conçu dès le départ sans meilleur modèle de permissions ni sandbox

    • J’ai commencé à utiliser Obsidian parce que j’en avais assez d’utiliser VS Code pour consulter des fichiers Markdown. Heureusement, je n’ai jamais eu besoin d’installer de plugin. À première vue, cette partie du design semble vraiment mauvaise

  • « Il est demandé à la victime d’activer la synchronisation des “Installed community plugins” »
    Obsidian dispose déjà de garde-fous pour empêcher ce type d’attaque, et la victime a été persuadée de les ignorer. Ce n’est rien d’autre qu’un cas réussi d’ingénierie sociale. Cette attaque n’exploite ni une faille d’Obsidian ni une faille du système de plugins, donc je n’aime pas voir Obsidian traîné dans la boue à cause de ce titre

    • Je ne suis pas d’accord. https://obsidian.md/help/plugin-security#Plugin+capabilities
      « En raison de limitations techniques, Obsidian ne peut pas restreindre de manière fiable les plugins à des permissions ou niveaux d’accès spécifiques. Les plugins héritent donc du niveau d’accès d’Obsidian. »
      Les plugins communautaires peuvent accéder aux fichiers de l’ordinateur, se connecter à Internet et même installer des programmes supplémentaires. Obsidian n’a absolument aucun garde-fou, et installer un plugin revient à lui accorder un accès total à l’ordinateur. Ce genre de chose devait arriver tôt ou tard, et à partir d’environ 2010, sortir un système de plugins de ce type relevait déjà d’une négligence injustifiable
    • J’utilise beaucoup Obsidian et je l’apprécie, mais je pense que l’intérêt de cette divulgation est de sensibiliser les gens aux plugins et de montrer le vecteur d’attaque
      Les utilisateurs moins expérimentés peuvent se dire : « Ce ne sont que des fichiers Markdown, je n’ai probablement pas trop à m’inquiéter des malwares. »

  • Pourquoi presque tous les systèmes de plugins sont-ils conçus de manière aussi laxiste ? Je me demande s’il n’existe pas de bon framework de développement de plugins offrant une isolation et des permissions correctes, ce qui rendrait le travail trop lourd, ou si c’est simplement que les gens ne savent pas vraiment ce qu’il faudrait faire et n’apprennent qu’après que leur système a été détourné. Ou les deux, ou autre chose ?

    • Au fond, c’est un compromis entre fonctionnalités et sécurité. Soit on donne aux utilisateurs des capacités puissantes pour faire des choses impressionnantes, soit on retire l’essentiel de ces capacités pour rendre le système sûr. En général, les gens préfèrent les fonctionnalités à la sécurité
      L’autre problème, c’est que la sécurité est difficile, alors qu’accorder un accès générique et ajouter quelques garde-fous basiques est facile
    • Il faut définir le framework de sécurité et les composants dont tous les plugins auront besoin, puis passer du temps à les concevoir, les implémenter, les vérifier et les maintenir
      Il est beaucoup plus simple de sauter cette étape. Donc oui, cela représente trop de travail — et plus précisément, cela demande un leadership centré sur la sécurité qui comprenne qu’il s’agit d’un travail important, mais nécessaire
    • Je suppose que c’est à cause d’un manque de ressources pour concevoir une interface correcte avec une web stack. Ce type de logiciel est écrit avec des frameworks JS de haut niveau, ce qui conduit souvent à de mauvais schémas de circulation des données, et l’on finit par suivre ce qui est simplement possible en pratique plutôt qu’un design intentionnel
      Pour concevoir les choses de manière volontaire, il faudrait peut-être descendre d’un niveau d’abstraction et maintenir un fork personnalisé du framework concerné. Ils ont donc probablement conçu les plugins comme on instancie une bibliothèque en lui passant une partie du contexte utilisé par l’application. Au final, c’est la méthode la plus simple qui fonctionne. Le piratage publié ici ne décrit pas une « vulnérabilité » précise ; les plugins Obsidian ont toujours été en mode dieu, et les attaquants se sont contentés de tromper les gens pour qu’ils les utilisent. C’est risible de rejeter au final la faute sur l’utilisateur alors qu’après quelques pop-ups, on se retrouve en pratique avec de l’exécution de code à distance. Les développeurs devraient avoir honte
    • Même les plugins du navigateur Chrome ont des problèmes de sécurité comparables. Et pourtant, il y a des milliards de dollars et beaucoup de développeurs très intelligents derrière
      C’est un peu comme créer un App Store dans une application. L’Apple App Store réduit les applications malveillantes en imposant des restrictions très strictes sur qui peut publier quoi, ainsi qu’une barrière payante
    • Pourquoi un système de plugins devrait-il impliquer automatiquement un sandboxing ?

  • Même si c’est de l’ingénierie sociale, si le système de plugins est conçu de manière à permettre cela, alors cette plateforme est totalement inadaptée comme outil de partage
    C’est bon à savoir, mais pour moi on n’est pas dans « pour utiliser un vault Obsidian partagé, il faut conserver correctement ce réglage », mais plutôt dans « il ne faut jamais accepter de vault Obsidian partagé et il faut exiger une exportation en texte brut »

  • Quand j’ai commencé à utiliser Obsidian, les vidéos YouTube que j’ai vues recommandaient d’utiliser les plugins communautaires. Même avec ce genre d’avertissements, je pense que j’aurais probablement activé les plugins communautaires
    Un développeur de plugin peut être de bonne foi au départ puis devenir malveillant plus tard, et l’utilisateur n’a aucun moyen de le savoir. Même en étant développeur et en connaissant ces risques, je pense que j’aurais activé l’option des plugins communautaires ; c’est peut-être simplement que ma tolérance au risque est élevée. J’espère être un cas minoritaire et que ce ne soit pas le comportement de la majorité des utilisateurs

  • Ce genre de chose est un peu en train de devenir une épidémie. Toutes les attaques ou tous les exploits, en particulier les attaques d’ingénierie sociale, n’ont pas besoin d’un nom façon Metal Gear ou d’un site web

  • À lire le contenu, le problème ne vient pas d’un plugin de la boutique Obsidian, mais d’un vault malveillant que l’on a incité la cible à ouvrir

  • J’exécute Obsidian avec des permissions restreintes. Pas d’accès réseau, pas d’accès au système de fichiers en dehors de son propre répertoire
    Je n’active l’accès réseau que pour mettre à jour les plugins/thèmes. J’exécute de la même façon d’autres applications capables d’exécuter du code non fiable

    • Peux-tu expliquer comment tu le sandboxes ?