Dans un monde DevOps où l’automatisation règne au sein des chaînes d’intégration continue (pipelines CI), de nouveaux risques cyber émergent qu’il est essentiel d’adresser au plus tôt.

Alors que le monde du développement informatique continue de créer de nouveaux processus de création de logiciels, les criminels continuent d’élaborer leurs propres techniques pour exploiter les failles de ces processus. Le DevOps est la dernière tendance en matière de développement logiciels et se caractérise par des niveaux élevés d’automatisation. De plus en plus de parties du processus de développement de logiciels peuvent se dérouler sans intervention humaine, ce qui accélère le développement. Toutefois, cela n’est pas sans inconvénients.

Moins d’intervention humaine signifie moins de surveillance du début à la fin, et cela signifie également plus de technologies à exploiter ou à abuser potentiellement. La plupart des risques sont liés à l’utilisation d’informations sensibles dans l’automatisation, ce qui permet de voler des secrets de plusieurs façons. Il faut également se préoccuper de choses comme l’altération du code. Pour assurer la sécurité du code et des secrets* associés, il faut ajouter les pratiques de sécurité suivantes au pipeline de CI.

Workflows tiers

L’attaque Codecov démontre l’impact que peut avoir un seul workflow sur la sécurité de l’ensemble du pipeline d’infrastructures critiques. Les attaques de type supply chain sont en augmentation, et le risque associé à ces attaques est un sujet entier en soi.

En ce moment, il est plus important que jamais d’accorder une attention particulière aux éléments auxquels sont exposés le code et l’infrastructure.

Il est courant d’utiliser des workflows tiers dans un pipeline de CI, mais il faut comprendre que cela suppose de confier le code et potentiellement les secrets associés à ce tiers. Il faut, si possible, examiner le code source des images et des workflows qui sont envisagés dans le pipeline de CI. Si le workflow est suivi à l’aide d’un contrôle de version, il est possible également d’examiner périodiquement les modifications pour s’assurer que rien de suspect ne s’est glissé.

Pour des raisons de temps ou de disponibilité du code source, cela n’est pas toujours possible. Cependant, il faut peser le pour et le contre en acceptant le risque de faire aveuglément confiance au workflow d’une tierce partie. À tout le moins, il faudrait rechercher des workflow qui sont soit publiés par une partie de confiance, soit populaires et auxquels d’autres font confiance. Il y aura toujours un certain risque à faire confiance à une tierce partie, ce qui réaffirme l’importance de prendre des mesures qui limitent les dommages qui peuvent être causés.

Contrôle d’accès

L’élément suivant à prendre en compte pour sécuriser le pipeline de CI est le contrôle d’accès. Grâce aux systèmes de gestion des clés, il est possible d’utiliser des fonctions telles que le contrôle d’accès basé sur les rôles pour déterminer qui peut utiliser quels secrets. Il faut toujours suivre le principe du moindre privilège pour déterminer qui doit avoir accès aux secrets. Le réglage fin de l’accès au niveau du système de gestion des clés est très important ; toutefois, ce n’est pas le seul point de risque dans le cycle de vie d’un secret.

Prenons le scénario suivant : un développeur gère un dépôt de logiciels libres très populaire sur GitHub et reçoit régulièrement des demandes de modification. Pour gagner du temps dans l’évaluation du code soumis, il lance des tests automatiques lorsque quelqu’un soumet une nouvelle pull request.

Si un jour, quelqu’un soumettait un code malveillant dans une pull request qui saisissait des variables d’environnement et les envoyait au serveur de l’auteur. Il a également ajouté un test pour s’assurer que son code s’exécuterait lors de l’exécution du pipeline de CI. Dès qu’il soumet la pull request, le pipeline démarre et toutes les variables d’environnement de votre environnement de CI sont volées…

L’exemple ci-dessus n’est même pas le pire des scénarios. Il existe des scénarios similaires comme celui décrit par ce blog. Dans ce cas, l’attaquant a pu sortir de l’environnement de test et voler des informations encore plus précieuses.

La dernière chose que l’on souhaite c’est qu’une partie non fiable puisse exécuter un code arbitraire dans l’environnement de build. Il ne suffit pas que les secrets soient protégés par un système de gestion des clés. Il faut également s’assurer que l’on fait confiance au code qui utilisera ces secrets. En particulier pour les mainteneurs de logiciels libres, pour qui il ne faut exécuter aucun workflow sur les pull request avant d’avoir lu le code.

Hachage/signature des builds

Le hachage des builds est plus important pour la sécurité des utilisateurs que pour celle du code, mais aller un peu plus loin dans le concept peut également être bénéfique à certains égards. À titre d’exemple, examinons l’une des plus grandes cyberattaques de 2020 : l’attaque de la supply chain de SolarWinds.

SolarWinds est l’un des principaux fournisseurs d’outils de surveillance et de gestion de réseau, utilisés par de nombreuses organisations. Dans le cadre d’une campagne de long terme, un adversaire a infecté les serveurs de build de SolarWinds avec un malware personnalisé appelé Sunspot. Sunspot est un logiciel malveillant très avancé qui surveille les processus en cours d’exécution sur les serveurs de développement, et qui recherche spécifiquement les processus impliqués dans la compilation du produit Orion de SolarWinds.

Lorsque Sunspot voyait qu’Orion était en cours de compilation sur le serveur de compilation, il injectait un code supplémentaire, baptisé plus tard « Sunburst », dans le logiciel compilé. Sunburst était une porte dérobée que les attaquants utilisaient pour accéder à toutes les organisations qui utilisaient Orion.

Alors, que faut-il retenir de tout cela ? Parce que le build lui-même était infecté, il était signé par SolarWinds et faisait en fait partie du produit qu’ils lançaient. Afin de détecter une telle attaque à l’avenir, SolarWinds a déclaré qu’elle étudiait les moyens de valider les builds simultanés les uns par rapport aux autres. Cela pourrait être un défi étant donné la sensibilité des algorithmes de hachage, mais il s’agit tout de même d’une piste à explorer pour pouvoir détecter les injections de build.

Protection de votre environnement de build

L’attaque de SolarWinds montre clairement que l’environnement de développement n’est pas seulement un bac à sable pour les développeurs, c’est un actif extrêmement sensible qui doit être protégé. Sunspot a pu rester longtemps sur les serveurs de développement de SolarWinds, mais certains IOC (indicateurs de compromission) auraient pu révéler la présence des attaquants.

Sans entrer trop profondément dans le sujet de la défense des ordinateurs et des réseaux, il existe quelques bonnes pratiques générales pour sécuriser les serveurs de build. Il faut tout d’abord s’assurer qu’une une journalisation appropriée a été activée sur les serveurs de build et qu’ils sont transmis à un SIEM ou à un agrégateur de journaux. Deuxièmement, on doit envisager de déployer un agent EDR sur les serveurs de build pour obtenir une télémétrie et des alertes supplémentaires lorsque quelque chose de suspect se produit. Troisièmement, il faut utiliser des outils de prévention et de détection des réseaux et traiter les serveurs de développement avec attention.

Il y a trop de couches potentielles pour protéger les ordinateurs pour toutes les énumérer, nous nous arrêterons donc là. Si vous n’avez pas beaucoup d’expérience dans le domaine de la sécurité informatique et de la défense des réseaux, adressez-vous à des experts qui pourront vous apporter un soutien ou des conseils supplémentaires.

Gestion des secrets

Les développeurs expérimentés ou professionnels de la sécurité ont probablement entendu parler de fuites de clés d’API dans des dépôts de code publics. Ils ont déjà peut-être même vu leurs propres secrets être divulgués après les avoir accidentellement transmis à un projet open-source. Selon le type de secret qui a été divulgué, l’erreur peut s’avérer coûteuse. Pour rappel, les « secrets », dans le contexte du développement de logiciels, font généralement référence aux systèmes d’authentification numérique qui permettent d’accéder à des systèmes ou à des données. Il s’agit le plus souvent de clés API, de noms d’utilisateurs et de mots de passe, ou de certificats de sécurité.

La meilleure façon de protéger les secrets est de pratiquer une bonne gestion des secrets. Il faut utiliser des outils de gestion des secrets comme Azure Key Vault ou Amazon KWS qui fournissent un stockage sécurisé et un accès basé sur l’identité. L’utilisation du gestionnaire de secrets intégré à GitHub fonctionne également bien selon le cas d’utilisation, mais il n’est pas aussi riche en fonctionnalités qu’un véritable service de gestion des clés.

Un autre élément indispensable pour la gestion des secrets est un outil qui peut indiquer immédiatement si un secret est accidentellement publié dans la base de code. Savoir à quel moment les secrets sont exposés accidentellement est crucial, le cas Codecov récent en est l’illustration. L’image Docker de Codecov a été discrètement modifiée pour divulguer les secrets de tous ceux qui l’utilisaient dans leur pipeline de CI pour les tests. Cela a eu un impact sur des dizaines de milliers de leurs clients/utilisateurs.

Même s’il est très difficile de prévenir une attaque comme celle de Codecov, son impact sur une organisation peut-être limité. Il faut si possible utiliser en production des secrets différents de ceux qui sont utilisés dans le pipeline de CI. De cette façon, si quelque chose comme le workflow compromis de Codecov donne accès à des clés, cela n’affectera pas l’environnement de production.

Malheureusement, les cyberattaquants ne cessent de faire évoluer leurs techniques, et la protection contre les nouvelles attaques sera toujours un défi. Le pipeline de CI fait partie des actifs les plus récemment ciblés, et les opportunités sont nombreuses en raison de l’absence d’implication humaine. Le respect de toutes ces pratiques de sécurité améliorerait grandement la sécurité du pipeline de CI, mais il faut s’assurer également de toujours se tenir au courant des nouvelles tendances des techniques des attaquants.
___________________

Par C.J. May, Professionnel de la sécurité et développeur passionné et expert chez GitGuardian

 


À lire également :

Sécurité applicative : le nouveau segment de la détection de secrets.

Comment sécuriser les accès des développeurs et le code ?

Protéger les applications contre des attaques modernes et complexes

DevOps : un virage culturel à bien préparer.