Posture de sécurité de l’environnement DevOps

Effectué

Avec l’augmentation des cyberattaques contre les systèmes de gestion de code source et les pipelines d’intégration et de livraison continue, il est crucial de sécuriser les plateformes DevOps contre le large éventail de menaces identifiées dans la Matrice des menaces DevOps. De telles cyberattaques peuvent permettre l’injection de code, l’élévation de privilèges et l’exfiltration de données, ce qui peut avoir un impact considérable.

La gestion de la posture DevOps est une fonctionnalité de Microsoft Defender pour Cloud qui :

• Fournit des informations sur la situation de sécurité de l’ensemble du cycle de vie de la chaîne d’approvisionnement logicielle.
• Utilise des scanners avancés pour des évaluations approfondies.
• Couvre diverses ressources, provenant d'organisations, de pipelines et de référentiels.
• Permet aux clients de réduire leur surface d'attaque en découvrant et en agissant sur les recommandations fournies.

Scanners DevOps

Pour fournir des résultats, la gestion de la posture DevOps utilise des scanners DevOps pour identifier les faiblesses dans la gestion du code source et les pipelines d'intégration continue/de livraison continue en effectuant des vérifications par rapport aux configurations de sécurité et aux contrôles d'accès.

Les scanners Azure DevOps et GitHub sont utilisés en interne au sein de Microsoft pour identifier les risques associés aux ressources DevOps, réduisant ainsi la surface d'attaque et renforçant les systèmes DevOps d'entreprise.

Une fois qu’un environnement DevOps est connecté, Defender pour le cloud configure automatiquement ces analyseurs pour effectuer des analyses récurrentes toutes les 24 heures sur plusieurs ressources DevOps, notamment :

• Versions
  
• Fichiers sécurisés
• Groupes de variables
• Connexions de service
• Organisations
• Référentiels

Réduction des risques de la matrice des menaces DevOps

La gestion de la posture DevOps aide les organisations à découvrir et à corriger les erreurs de configuration nuisibles dans la plateforme DevOps. Cela conduit à un environnement DevOps résilient et sans confiance, renforcé contre une série de menaces définies dans la matrice des menaces DevOps. Les principaux contrôles de gestion de la posture comprennent :

• Accès secret limité : minimisez l'exposition des informations sensibles et réduisez le risque d'accès non autorisé, de fuites de données et de mouvements latéraux en garantissant que chaque pipeline n'a accès qu'aux secrets essentiels à sa fonction.
  
• Restriction des exécuteurs auto-hébergés et autorisations élevées : évitez les exécutions non autorisées et les escalades potentielles en évitant les exécuteurs auto-hébergés et en garantissant que les autorisations du pipeline sont par défaut en lecture seule.
  
• Protection améliorée des succursales : Maintenez l’intégrité du code en appliquant les règles de protection des branches et en empêchant les injections de code malveillant.
  
• Autorisations optimisées et référentiels sécurisés : Réduisez le risque d’accès non autorisé, les modifications par suivi des autorisations de base minimales et l’activation de la protection push de secret pour des référentiels.
  

Matrice de menace DevOps

Notre objectif pour développer la matrice de menace pour DevOps est la génération d’une base de connaissances complète que les défenseurs peuvent utiliser pour suivre et créer des défenses contre les techniques d’attaque pertinentes. L’utilisation de l’infrastructure MITRE ATT&CK comme base nous a permis de collecter des techniques et des vecteurs d’attaque associés aux environnements DevOps et de créer une matrice dédiée aux méthodes d’attaque DevOps.

Il convient de signaler que les tactiques dans cette matrice doivent être examinées du point de vue de DevOps. Par exemple, les techniques d’exécution dans une machine virtuelle exécutant un système d’exploitation Windows ou Linux sont différentes de l’exécution dans un pipeline DevOps. Dans le cas de Linux, l’exécution signifie l’exécution de code dans le système d’exploitation. Lorsque nous évoquons les environnements DevOps, il s’agit du code d’exécution dans les ressources DevOps ou de pipeline. Outre l’utilisation de cette matrice de menace pour catégoriser les attaques et les méthodes de défense correspondantes, les défenseurs peuvent fonctionner avec des équipes rouges pour effectuer des tests en permanence et trouver de nouvelles techniques d’attaque.

MITRE ATT&CK défini

La matrice MITRE ATT&CK est une base de connaissances accessible au public qui permet de comprendre les différentes tactiques et techniques utilisées par les attaquants lors d’une cyberattaque.

La base de connaissances est organisée en plusieurs catégories : pré-attaque, accès initial, exécution, persistance, élévation des privilèges, évasion défensive, accès aux informations d’identification, découverte, mouvement latéral, collecte, exfiltration et commande et contrôle.

Les tactiques (T) représentent le « pourquoi » d’une technique ou d’une sous-technique ATT&CK. C’est l’objectif tactique de l’adversaire : la raison d’effectuer une action. Par exemple, un adversaire peut vouloir obtenir l’accès aux informations d’identification.

Les techniques (T) représentent « comment » un adversaire atteint un objectif tactique en effectuant une action. Par exemple, un adversaire peut voler et copier des informations d’identification pour obtenir un accès aux informations d’identification.

Dans ATT&CK, le terme Common Knowledge (CK) désigne les connaissances communes, c’est-à-dire essentiellement le modus operandi documenté des tactiques et des techniques mises en œuvre par les adversaires.

Accès initial

La tactique d’accès initial fait référence aux techniques qu’un attaquant peut utiliser pour accéder aux ressources DevOps : référentiels, pipelines et dépendances. Les techniques suivantes peuvent être une condition préalable pour les prochaines étapes :

Authentification de gestion du code source (SCM) : accès en ayant une méthode d’authentification de gestion du code source de l’organisation. Il peut s’agit du jeton d’accès personnel (PAT), d’une clé SSH ou d’autres informations d’identification d’authentification autorisées. L’utilisation d’une attaque par hameçonnage contre une organisation constitue un exemple de méthode utilisée par un attaquant pour réaliser cette technique.

Authentification du service d’intégration continue (CI) et de livraison continue (CD) : semblable à l’authentification de gestion du code source (SCM), un attaquant peut tirer profit de l’authentification au service CI/CD pour attaquer le logiciel DevOps de l’organisation.

Référentiels publics de l’organisation : accès aux référentiels publics de l’organisation qui sont configurés avec des fonctionnalités CI/CD. Selon la configuration de l’organisation, ces référentiels peuvent avoir la possibilité de déclencher une exécution de pipeline après la création d’une demande de tirage (pull request).

Compromission du point de terminaison : l’attaquant utilise une compromission existante pour tirer profit de la station de travail compromise du développeur et accéder ainsi à la gestion du code source (SCM), au registre ou à toute autre ressource de l’organisation auxquels le développeur peut accéder.

Webhooks configurés : quand une organisation a un webhook configuré, un attaquant peut l’utiliser comme mécanisme d’accès initial au réseau de l’organisation en utilisant la gestion du code source elle-même pour déclencher des requêtes dans ce réseau. Cette opération peut octroyer à l’attaquant l’accès aux services non destinés à une exposition publique ou qui sont des exécutions de versions logicielles anciennes et vulnérables au sein du réseau privé.

Exécution

La tactique d’exécution fait référence aux techniques qu’une personne mal intentionnée et malveillante peut utiliser pour obtenir un accès d’exécution aux ressources de pipeline, à savoir le pipeline lui-même ou les ressources de déploiement. Certaines des techniques de cette section comportent des explications sur les différentes façons de les effectuer, ou ce que nous appelons les sous-techniques :

Exécution de pipeline empoisonné (PPE) : fait référence à une technique dans laquelle un attaquant peut injecter du code dans le référentiel d’une organisation, ce qui entraîne une exécution de code dans le système CI/CD du référentiel. Il existe diverses sous-techniques pour réaliser une exécution de code :

• PPE directe (ou d-PPE) : cas où l’attaquant peut directement modifier le fichier config à l’intérieur du référentiel. Du fait que le pipeline est déclenché par une nouvelle demande de tirage (pull request) et s’exécute en fonction du fichier config, l’attaquant peut injecter des commandes malveillantes dans le fichier config et elles sont exécutées dans le pipeline.
  
• PPE indirecte (i-PPE) : cas où l’attaquant ne peut pas directement modifier les fichiers config ou lorsque ces modifications ne sont pas prises en compte une fois déclenchées. Dans ces situations, l’attaquant peut infecter des scripts utilisés par le pipeline afin d’exécuter du code comme des fichiers makefile, des scripts de test, des scripts de build, etc.
• Exécution publique de pipelines empoisonnés : cas où le pipeline est déclenché par un projet open source. Dans ces situations, l’attaquant peut utiliser une d-PPE ou une i-PPE sur le référentiel public pour infecter le pipeline.

Falsification de dépendance : fait référence à une technique où un attaquant peut exécuter du code dans l’environnement DevOps ou l’environnement de production en injectant du code malveillant dans les dépendances d’un référentiel. Par conséquent, le code malveillant est exécuté lors du téléchargement de la dépendance. Certaines sous-techniques pouvant être utilisées pour effectuer une exécution de code incluent :

• Confusion de dépendance publique : une technique où la personne mal intentionnée publie des packages publics malveillants portant le même nom que des packages privés. Dans cette situation, du fait que la recherche de packages dans des mécanismes de contrôle de packages effectue généralement une recherche dans des registres publics en premier, le package malveillant est téléchargé.
• Détournement de package public (« repo-jacking ») : le détournement de package public via la prise de contrôle du compte du mainteneur, par exemple, via l’exploitation de la fonctionnalité de renommage de l’utilisateur de GitHub.
• Typosquatting (typosquattage) : publication de packages malveillants portant des noms similaires à ceux de packages publics connus. De cette manière, un attaquant induire des utilisateurs en erreur pour qu’ils téléchargent le package malveillant au lieu de celui souhaité.

Compromission de ressources DevOps : les pipelines constituent essentiellement un ensemble de ressources de calcul exécutant les agents CI/CD avec d’autres logiciels. Un attaquant peut cibler ces ressources en exploitant une vulnérabilité dans le système d’exploitation, le code de l’agent, d’autres logiciels installés dans les machines virtuelles ou d’autres appareils dans le réseau pour accéder au pipeline.

Contrôle du registre courant : un attaquant peut contrôler un registre utilisé par l’organisation, ce qui entraîne l’exécution des images ou des packages malveillants par les machines virtuelles de pipeline ou les machines virtuelles de production.

Persistance

La tactique de persistance se compose de différentes techniques qu’un attaquant peut utiliser pour conserver l’accès à l’environnement de la victime :

Modifications dans un référentiel : les personnes mal intentionnées peuvent utiliser les jetons automatiques à l’intérieur du pipeline pour accéder et envoyer (push) du code au référentiel (en supposant que le jeton automatique ait les autorisations suffisantes pour le faire). Ils peuvent ainsi atteindre une persistance en utilisant plusieurs sous-techniques :

• Modification/ajout de scripts dans du code : nous avons la possibilité de modifier certains des scripts d’initialisation/ajouter de nouveaux scripts. Ils téléchargent donc une porte dérobée/un démarrage pour l’attaquant afin que, lors de chaque exécution de ces scripts par le pipeline, le code de l’attaquant est également exécuté.
  
• Modification d la configuration du pipeline : nous avons la possibilité d’ajouter de nouvelles étapes au pipeline qui téléchargent un script contrôlé par un attaquant dans le pipeline avant de poursuivre le processus de génération.
• Modification de la configuration des emplacements des dépendances : dans le but d’utiliser des packages contrôlés par l’attaquant.

Injection dans artefacts : certains environnements CI disposent de la fonctionnalité permettant de créer des artefacts à partager entre différentes exécutions de pipeline. Par exemple, dans GitHub, nous avons la possibilité de stocker des artefacts et de les télécharger en utilisant une action GitHub à partir de la configuration du pipeline.

Modification d’images dans un registre : dans les situations où les pipelines disposent d’autorisations pour accéder au registre d’une image (par exemple, pour l’écriture différée d’images dans le registre une fois la génération effectuée), l’attaquant peut modifier et déposer des images malveillantes dans le registre que les conteneurs de l’utilisateur vont continuer d’exécuter.

Création d’informations d’identification de service : une personne mal intentionnée et malveillante peut tirer profit de l’accès dont elle dispose déjà sur l’environnement et créer des informations d’identification à utiliser en cas de perte du mécanisme d’accès initial. Il est possible d’effectuer cette opération en créant un jeton d’accès dans le Gestionnaire de contrôle des services (GCL) dans l’application elle-même, dans les ressources cloud et bien plus encore.

Élévation des privilèges

Un attaquant utilise les techniques d’élévation des privilèges dans l’environnement de la victime et obtenir ainsi des privilèges plus élevés pour les ressources déjà compromises :

Secrets dans des référentiels privés : un attaquant peut rechercher des secrets cachés dans des référentiels privés en tirant profit d’un mécanisme d’accès initial auquel il a déjà accès. Les chances de détecter des secrets cachés dans un référentiel privé sont plus importantes que dans un référentiel public car, du point de vue du développeur, ce dernier est inaccessible en dehors de l’organisation.

Validation/envoi (push) vers des branches protégées : le pipeline a accès au référentiel qu’il est possible de configurer avec un accès permissif, ce qui permet d’envoyer (push) du code vers des branches protégées et à la personne mal intentionnée d’injecter du code directement dans des branches importantes sans qu’une équipe puisse intervenir.

Certificats et identités des services de métadonnées : une fois que l’attaquant s’exécute sur des pipelines hébergés sur le cloud, il peut accéder aux services de métadonnées à partir du pipeline et extraire des certificats (privilèges élevés nécessaires) et des identités depuis ces services.

Accès aux informations d’identification

Les techniques d’accès aux informations d’identification sont utilisées par un attaquant dans le but de voler des informations d’identification :

Informations d’identification de l’utilisateur : dans les situations où le client exige l’accès à des services externes depuis le pipeline CI (par exemple, une base de données externe), ces informations d’identification résident dans le pipeline (pouvant faire l’objet d’une définition par des secrets CI, des variables d’environnement, etc.) et la personne mal intentionnée peut y accéder.

Informations d’identification du service : il existe des cas où l’attaquant peut trouver des informations d’identification, telles que les noms de principal du service (SPN), les jetons de signature d’accès partagé (SAS) et d’autres qui peuvent autoriser l’accès à d’autres services directement depuis le pipeline.

Mouvement latéral

La tactique de mouvement latéral fait référence aux techniques utilisées par des attaquants pour se déplacer dans différentes ressources. Dans les environnements CI/CD, cette action peut faire référence à un déplacement dans des ressources de déploiement, dans des artefacts de build et des registres ou vers de nouvelles cibles.

Artefacts de build compromis : comme dans d’autres attaques de la chaîne logistique, l’attaquant peut interférer avec les artefacts de build une fois qu’il dispose du contrôle des pipelines CI. Le code malveillant peut de cette manière être injecté dans le matériel de génération avant l’achèvement de cette dernière, ce qui injecte ainsi la fonctionnalité malveillante dans les artefacts de build.

Injection du registre : si la configuration du pipeline comprend un registre pour les artefacts de build, l’attaquant peut infecter le registre avec des images malveillantes pouvant par la suite être téléchargées et exécutées par des conteneurs en utilisant ce registre.

Propagation aux ressources de déploiement : si le pipeline est configuré avec un accès aux ressources de déploiement, l’attaquant peut également accéder à ces dernières, ce qui lui permet de s’étendre. Cela peut entraîner une exécution de code, une exfiltration de données et bien plus encore, en fonction des autorisations accordées aux pipelines.

Évasion de défense

Les attaquants peuvent utiliser des techniques de contournement des défenses pour contourner les défenses utilisées dans un environnement DevOps et permettre aux attaques de se poursuivre discrètement :

Manipulation des journaux de service : les journaux de service permettent aux défenseurs de détecter des attaques au sein de leur environnement. Un attaquant effectuant une exécution au sein d’un environnement (par exemple, dans les pipelines de build) peut modifier les journaux pour empêcher les défenseurs de voir l’attaque. Cette action est similaire à un attaquant qui modifie les journaux d’historique sur une machine Linux, ce qui empêche les observateurs de voir les commandes exécutées par l’attaquant.

Manipulation de la compilation : si un attaquant souhaite ne laisser aucune trace dans le service de gestion du code source, il peut modifier le processus de compilation afin d’injecter le code malveillant. Il peut effectuer cette opération de différentes manières :

• Modification du code à la volée : une modification du code juste avant le début du processus de génération sans le changer dans le référentiel et y laisser des traces.
  
• Compilateur falsifié : une modification du compilateur dans l’environnement de génération pour introduire du code malveillant avant le début de ce processus sans laisser de traces.

Reconfigurer les protections de branche : les outils de protection des branches permettent à une organisation de configurer des étapes avant l’approbation d’une demande de tirage (pull request)/validation dans une branche. Une fois que l’attaquant dispose des autorisations d’administrateur, il peut modifier ces configurations et introduire du code dans la branche sans aucune intervention de la part de l’utilisateur.

Impact

La tactique d’impact fait référence aux techniques qu’un attaquant peut utiliser afin d’exploiter l’accès aux ressources CI/CD à des fins malveillantes. Il ne peut pas l’employer comme étape supplémentaire dans l’attaque, car ces techniques peuvent être bruyantes et faciles à détecter :

Attaque DDoS : une personne mal intentionnée peut utiliser les ressources de calcul auxquelles elle accède pour exécuter des attaques DDoS (par déni de service distribué) sur des cibles externes.

Exploration de crypto : les ressources de calcul peuvent être utilisées pour l’exploration de crypto contrôlée par une personne mal intentionnée.

Attaque Dos locale : une fois que l’attaquant s’exécute sur les pipelines CI, il peut réaliser une attaque par déni de service de ces pipelines vers des clients en arrêtant les agents, en redémarrant ou en surchargeant les machines virtuelles.

Suppression de ressources : un attaquant ayant accès aux ressources (ressources cloud, référentiels, etc.) peut supprimer définitivement les ressources pour accomplir le déni de service.

Exfiltration

La tactique d’exfiltration fait référence aux différentes techniques qu’un attaquant peut utiliser pour exfiltrer des données sensibles à partir de l’environnement de la victime :

Clonage de référentiels privés : une fois que les attaquants ont accès aux pipelines CI, ils ont également accès aux référentiels privés (par exemple, le GITHUB_TOKEN peut être utilisé dans GitHub) et peuvent par conséquent cloner et accéder au code et avoir ainsi accès à une adresse IP privée.

Journaux de pipeline : une personne mal intentionnée peut accéder aux journaux d’exécution du pipeline, afficher l’historique des accès, les étapes de génération, etc. Ces journaux peuvent contenir des informations sensibles sur la génération, le déploiement et parfois les informations de connexion aux services, aux comptes d’utilisateur et bien d’autres.

Exfiltration de données à partir de ressources de production : dans les cas où les pipelines peuvent accéder aux ressources de production, les attaquants y ont également accès. Par conséquent, ils peuvent abuser de cet accès pour exfiltrer des données de production.

Suggestions de gestion de la posture DevOps

Lorsque les scanners DevOps découvrent des écarts par rapport aux meilleures pratiques de sécurité au sein des systèmes de gestion de code source et des pipelines d'intégration et de livraison continue, Defender for Cloud émet des recommandations précises et exploitables. Ces suggestions présentent les avantages suivants :

• Visibilité améliorée : Obtenez des informations complètes sur la posture de sécurité des environnements DevOps, garantissant une compréhension complète de toutes les vulnérabilités existantes. Identifiez les règles de protection des succursales manquantes, les risques d’élévation de privilèges et les connexions non sécurisées pour prévenir les attaques.
  
• Action prioritaire : Filtrez les résultats par gravité pour dépenser vos ressources et vos efforts plus efficacement en traitant d'abord les vulnérabilités les plus critiques.
• Réduction de la surface d'attaque : Corrigez les failles de sécurité mises en évidence pour minimiser considérablement les surfaces d’attaque vulnérables, renforçant ainsi les défenses contre les menaces potentielles.
• Notifications en temps réel : Possibilité d'intégration aux automatisations de flux de travail pour recevoir des alertes immédiates lorsque les configurations sécurisées sont modifiées, permettant une action rapide et garantissant une conformité durable avec les protocoles de sécurité.