Comment et pourquoi les attaquants ciblent les comptes des développeurs

La plupart des entreprises font aujourd’hui du développement logiciel. Peu importe que vous soyez un fournisseur de services de cloud computing ou que vous fabriquiez de la peinture, il est fort probable que vous ayez une équipe de développeurs qui construisent des systèmes propriétaires et, à tout le moins, vous dépendez fortement des logiciels du marché pour votre activité.

Et, cela signifie que si vous pouvez contrôler le code source d’une organisation, vous pouvez contrôler et perturber de nombreux éléments de ses opérations.

Cette année, lors des conférences DefCon et BlackHat – les deux plus grandes conférences mondiales sur la sécurité et le piratage informatique – de nombreuses discussions ont porté sur la façon dont les attaquants ciblent ces systèmes.

L’une des tendances observées depuis de nombreuses années : les développeurs sont de plus en plus ciblés par les attaquants comme moyen d’accéder à la chaîne logiciels et de prendre le contrôle d’une organisation.

Cet article va compiler les leçons et les outils tirés des briefings de BlackHat et de Defcon afin de souligner certaines des tendances clés sur la façon dont les adversaires compromettent les développeurs et s’attaquent au code source.

Plus précisément, nous allons examiner comment ils peuvent accéder aux systèmes de gestion du code source (SCM) comme git et aux pipelines de CI/CD. Nous examinerons le chemin qu’empruntent les attaquants pour y parvenir, à savoir :

● Compromettre un compte de développeur

● Compromettre un gestionnaire de code source (SCM)

● Compromettre les pipelines CI/CD

Compromettre un compte de développeur

« Vous devez supposer que chaque développeur est malveillant ou compromis » Iain Smart

La première étape pour compromettre des outils de développement est de compromettre un compte de développeur. Alors que les comptes d’administration peuvent être hautement protégés, nous avons vu de nombreux exemples où les comptes de développeurs étaient des cibles beaucoup plus faciles.

Il y a quelques raisons à cela : ils ne sont pas suffisamment protégés par l’organisation, les mêmes comptes sont utilisés à des fins personnelles et professionnelles (notamment dans le cas de GitHub), les dépôts git sont souvent mal configurés et, surtout, les comptes de développeurs ne sont pas considérés comme essentiels à la sécurité par les organisations.

Si les comptes de développeurs n’ont pas forcément par défaut les autorisations nécessaires pour manipuler le code de production ou déployer des applications, la nature des outils avec lesquels ils travaillent leur permet d’interagir avec différents systèmes et souvent de contourner les contrôles de sécurité. C’est pourquoi ils sont une cible si importante pour les attaquants.

Passons en revue quelques exemples récents de comptes de développeurs compromis :

1>  Menace interne / Utilisateur compromis
Au début de l’année 2022, le groupe Lapsus$ a réussi à accéder au code source privé d’un certain nombre de grandes organisations. Parmi elles, Microsoft, Nvidia, Samsung et d’autres.

Comment ? L’une des méthodes consistait à payer des employés pour qu’ils donnent ‘accès à des systèmes internes tels que des dépôts de code. Il y a des milliers de développeurs dans les grandes entreprises, feriez-vous confiance à chacun d’entre eux pour ne pas donner accès à un attaquant?

2 > Dépôt git mal configuré
Twitch est une autre entreprise dont le code source a été divulgué publiquement. Cette fois, c’est un dépôt git mal configuré qui a permis l’accès à distance. L’attaquant a découvert que l’ensemble du dépôt de code était accessible à distance sur un réseau privé en fuzzant différents end points.

3 > Mauvaise hygiène des mots de passe
Uber a connu un incident au cours duquel des attaquants ont pu accéder à des dépôts de code source privés, car les développeurs réutilisaient les mêmes mots de passe sur plusieurs sites et les attaquants ont pu utiliser les données récupérées lors d’une attaque concernant un autre site pour y accéder.

4 > Fuite des informations d’identification git
Les développeurs utilisent souvent des tokens de connexion et des clés SHH pour s’authentifier auprès de systèmes tels que git. Ces clés se retrouvent souvent par erreur dans des dépôts publics liés à des projets personnels.

Dans le cadre de recherches menées par GitGuardian, nous avons découvert plus de 60 000 tokens d’accès à des dépôts privés ont été divulgués dans des dépôts git publics. Les adversaires fouillent souvent les dépôts publics pour essayer d’accéder à ces comptes.

Il existe d’autres exemples, mais l’idée ici est que les comptes de développeurs ne sont pas si sûrs que cela et qu’un attaquant motivé pourra trouver une faille pour accéder à vos dépôts de code, d’où il pourra ensuite poursuivre une attaque sur les systèmes de gestion du code source ou les pipelines CI/CD.

Compromettre le système de gestion du code source

Une fois qu’un adversaire a obtenu l’accès à un compte de développeur avec accès au système de code source interne, tel qu’un serveur git, il se peut qu’il n’ait accès qu’à des dépôts limités avec un accès insuffisant pour pouvoir injecter du code malveillant ou affecter la production. L’acteur malveillant doit donc à ce moment-là utiliser son accès développeur pour obtenir des droits supplémentaires.

De nombreuses méthodes et outils existent pour aider l’attaquant dans cette tâche. Brett Hawkins est un chercheur en sécurité chez IBM X-Force red et est le créateur de SCM-kit.

Le travail de M. Hawkins chez IBM est axé sur la simulation d’adversaires, afin de démontrer aux clients l’impact potentiel des failles de sécurité et des vulnérabilités.

Au cours d’une présentation très intéressante, M. Hawkins a présenté des recherches sur la façon dont vous pouvez exploiter les systèmes de gestion du code source en tant qu’attaquant ou membre de d’une red team.

Il a exposé quatre scénarios d’attaque qui peuvent être utilisés sur les systèmes de gestion du code source (SCM) : La reconnaissance, l’usurpation d’identité, l’escalade de droit administrateur et la prise de contrôle du dépôt de code.

Un attaquant disposant d’un accès développeur exécutera probablement toutes ces activités pour tenter d’obtenir des privilèges élevés ou d’accéder à des ressources sensibles. Chacune d’entre elles nécessite généralement un temps considérable et plus un attaquant passe de temps dans un système, plus l’activité suspecte apparaîtra dans les logs et les outils de sécurité.

Tous les outils SCM courants comme GitHub, GitLab, BitBucket, etc., disposent d’API REST auxquelles l’attaquant peut accéder et qu’il peut manipuler, ce qui signifie qu’il peut automatiser ces tâches. Aucun de ces scénarios d’attaque n’est axé sur les vulnérabilités des systèmes, mais plutôt sur les fonctionnalités des applications auxquelles les développeurs ont accès (et doivent avoir accès).

« Il s’agit d’abuser des fonctions disponibles dans le système », explique Brett Hawkins.

Ils n’ont même pas besoin de créer leurs propres outils d’automatisation puisqu’il en existe déjà. Le kit SCM peut être utilisé pour exécuter de multiples scénarios d’attaque (bien au-delà de ce qui est énuméré ci-dessus) automatiquement à partir de l’accès développeur.

Voici certains de ces scénarios :

Reconnaissance

Au début de l’attaque, l’attaquant découvre toutes les vulnérabilités qu’il peut exploiter. Il peut s’agir de gains rapides comme la recherche de secrets codés en dur ou la découverte d’erreurs de logique dans une application à laquelle il a accès. Mais l’attaquant va aussi essayer de découvrir la structure du SCM et toutes les différentes ressources auxquelles il a, ou n’a pas, accès.

C’est important car, avec ces informations, il peut commencer à essayer d’identifier les vulnérabilités de configuration dans les ressources privées où il peut élever ses privilèges. Le SCM-kit se connectera à n’importe quel compte de développeur et peut être utilisé pour découvrir toutes sortes d’informations dans un système.

Usurpation d’identité et maintien d’accès persistant

La plupart des outils SCM permettent aux administrateurs de prendre l’identité des utilisateurs, ce qui peut impliquer la génération d’un token d’identité (un token d’accès pour un autre utilisateur). Une autre façon de maintenir l’accès est de générer d’autres méthodes d’authentification telles qu’une clé SSH pour permettre à l’attaquant un accès direct.

Ceci est très important lors d’une attaque, car il est alors beaucoup plus difficile de détecter si un attaquant se trouve dans le système. Comme il contrôle désormais sa propre authentification, même si un utilisateur compromis modifie ses informations d’accès, l’attaquant peut conserver son accès.

Élévation des privilèges jusqu’à l’accès administrateur

Tout attaquant essaiera d’obtenir l’accès à un compte administrateur. Il peut y parvenir après avoir accédé à un SSH ordinaire ou à des tokens d’utilisateur lors de la phase de reconnaissance de l’attaque. Pour maintenir sa présence, l’attaquant voudra promouvoir ou créer de nouveaux comptes avec un accès administrateur pour éviter d’être bloqué.

En utilisant le kit SCM, un attaquant pourrait très rapidement trouver un accès administrateur et promouvoir un nouvel utilisateur avec un accès API via l’outil du kit SCM. Ainsi, même si l’accès administrateur original est révoqué, l’attaquant maintiendra son authentification.

Prise de contrôle de référentiels

Restreindre l’accès des utilisateurs aux référentiels est un moyen de faire perdurer une attaque et de réduire la capacité d’une entreprise à détecter et à prévenir un attaquant.

Avec un accès administrateur, les utilisateurs malveillants peuvent prendre le contrôle et bloquer l’accès à ces référentiels directement depuis le kit SCM via l’API. Si un attaquant a un accès exclusif à un référentiel, il peut facilement déployer des applications malveillantes dans les environnements de production sans interruption.

Compromettre le pipeline CI/CD

Outre la compromission des systèmes de gestion du code source, les pipelines CI/CD sont devenus une autre cible majeure. Les pipelines CI/CD sont des outils utilisés par les développeurs pour automatiser les tâches déclenchées par des événements tels que le merge de code.

Si un attaquant peut contrôler le pipeline CI/CD, il peut alors prendre le contrôle de l’intégrité des tests et du déploiement d’une application.

Lors d’une des présentations, les conférenciers Viktor Gazdag et Iain Smart du NCC ont présenté des scénarios d’attaque qu’ils ont réalisés pour compromettre des pipelines CI/CD à partir de comptes de développeurs limités.

Ils ont été en mesure de montrer de multiples exemples réels où ils ont mené des attaques à partir d’un compte de développeur en élevant leurs privilèges et en profitant des mauvaises configurations courantes pour effectuer des tâches de niveau administrateur et finalement prendre le contrôle de l’environnement CI/CD.

Iain Smart a décrit une attaque où le client a accordé aux chercheurs de NCC Group un ensemble d’identifiants de développeur, dépourvus de privilèges d’administrateur, pour voir s’ils pouvaient casser le pipeline. Bien qu’ils n’aient eu accès qu’à un seul dépôt Bitbucket, ils ont pu modifier les dépendances nécessaires à la construction d’une application par le pipeline.

Iain Smart a injecté un paquet malveillant personnalisé de sorte que lorsque le pipeline CI/CD s’y connectait, il avait accès à un runner Jenkins. Bien que l’environnement de ce runner soit limité, les chercheurs ont pu aller plus loin dans le système grâce à une clé SSH privée qui était exposée dans l’environnement.

Avec cette clé, les chercheurs ont pu accéder à tous les nœuds de contrôle Jenkins de l’organisation et obtenir tous les secrets, y compris les informations d’identification et les clés API de plusieurs projets.

Bien qu’il s’agisse d’une méthode assez complexe pour obtenir des privilèges élevés, I. Smart a donné de nombreux exemples où la méthode était beaucoup plus simple. Dans un cas, les développeurs n’étaient pas censés avoir accès aux informations d’identification de la production.

Mais Iain Smart a écrit un code simple pour imprimer à l’écran les informations d’identification utilisées par le pipeline CI/CD, et en remplaçant le texte DEV par PROD, ils ont soudainement eu accès à toutes les informations d’identification de production.

Conclusion

Vous pensez peut-être que tous ces exemples ne nécessitent qu’une seule chose, que l’attaquant ait accès aux comptes des développeurs. Oui, c’est vrai, mais ce que nous pouvons constater à travers ces présentations DefCon et BlackHat, combinés à toutes les attaques dont nous avons été témoins cette année, c’est que les comptes de développeurs sont l’un des maillons les plus faibles de la supply chain.

Le développement rapide d’outils pour y parvenir facilite grandement la vie des attaquants qui peuvent commencer par un compte de développeur et se frayer un chemin à travers de multiples systèmes pour en prendre le contrôle, rendre des applications malveillantes et perturber leur fonctionnement.

Pour éviter cela, il ne suffit pas de dire que nous avons besoin d’un MFA sur les comptes de développeurs (bien que ce soit le cas), mais il faut un changement d’état d’esprit qui mette les adversaires à la place des développeurs. Les organisations doivent mettre en place des scénarios d’attaque dans lesquels un attaquant dispose d’un accès développeur, afin de voir où une confiance excessive est accordée.