Un chercheur en sécurité a décrit comment l’abus d’autorisations dans les référentiels de gestion de code source (SCM) peut entraîner un empoisonnement CI ou des «attaques de pipeline empoisonné».

Les environnements de développement, y compris les plates-formes d’intégration continue (CI) et de livraison continue (CD), sont des éléments de base fondamentaux pour la fusion de code, l’automatisation des versions de logiciels, les tests et la livraison de code aux projets DevOps.

Omer Gil, responsable de la recherche chez Cider Security, a déclaré dans un article de blog technique datée du 8 février qu’en raison des fonctions critiques jouées par les environnements CI et CD, ils constituent également une «partie majeure de la surface d’attaque actuelle» et contiennent souvent les secrets et les informations d’identification d’une organisation.

Les attaquants capables de compromettre les environnements CI/CD peuvent être en mesure d’accéder aux zones de production ou aux mécanismes de livraison pour des attaques plus larges de la chaîne d’approvisionnement. Des exemples récents incluent des mises à jour logicielles empoisonnées fournies par SolarWinds et Codecov, ainsi qu’une intrusion chez Kaseya.

Exécution de pipeline empoisonnée

En juillet 2021, l’Agence de l’Union européenne pour la cybersécurité (ENISA) a examiné les incidents de la chaîne d’approvisionnement entre 2020 et 2021 et a déclaré dans un rapport qu’environ 50 % des cyberattaques étaient attribuées à un groupe de menaces persistantes avancées (APT), mais que des attaques inconnues étaient responsables de 42 % des incidents signalés.

L’ENISA a ajouté que plus de 60 % des attaques de la chaîne d’approvisionnement « profitaient » de la confiance des clients dans leur fournisseur, et 66 % des cyberattaques ciblaient le code du fournisseur pour compromettre davantage les clients ciblés.

Le moyen le plus simple d’accéder au CI et d’effectuer une attaque de la chaîne d’approvisionnement est d’avoir un accès direct. Selon Gil, cependant, une technique locale pourrait également être utilisée pour altérer les pipelines de production sans avoir un accès direct aux environnements CI.

Surnommée Poisoned Pipeline Execution (PPE), Gil dit que la technique se concentre sur une manière commune de définir les pipelines, en utilisant des fichiers de configuration CI hébergés dans des référentiels de pipeline.

Ces fichiers – généralement trouvés avec des formats standard, y compris Fichier Jenkins, .gitlab-ci.yml, .circleci/config.ymlet GitHub Actions YAML – contiennent des commandes qui sont déclenchées lorsque les travaux de pipeline extraient du code à partir de sources de développement.

Si les attaquants peuvent altérer les listes de commandes, ils peuvent être en mesure d’exécuter du code dans le CI.

C’est là qu’intervient l’EPI.

Attaquer le pipeline CI

Le vecteur d’attaque de pipeline empoisonné nécessite qu’un acteur malveillant dispose d’autorisations SCM, telles que des informations d’identification d’utilisateur ou des jetons d’accès, pour manipuler des fichiers de configuration CI ou un contenu similaire, et exécuter une activité de pipeline.

Les attaquants doivent également pouvoir altérer ces fichiers sans déclencher d’examens. Gil dit que les pipelines qui exécutent du code non révisé sont plus sensibles aux attaques PPE.

Les EPI ont été séparés en différentes catégories :

  • Directe (D-PPE) – Les attaquants modifient les fichiers de configuration CI situés avec les projets cibles
  • Indirect (I-PPE) – Un code malveillant est injecté dans des fichiers invoqués indirectement par les fichiers de configuration du pipeline
  • Publique (P-PPE/3PE) – Les attaquants doivent pouvoir accéder aux référentiels hébergeant les fichiers de configuration du pipeline, en obtenant des informations d’identification et/ou une autorisation. Il peut également être possible de compromettre des projets publics par le biais de demandes d’extraction lorsque du code non révisé est accepté et exécuté.

Une fois l’exécution du code établie, les attaquants peuvent accéder aux secrets liés au CI, envoyer des travaux malveillants, expédier du code malveillant, accéder aux actifs externes pour lesquels les nœuds de travail ont des autorisations, et ils peuvent également être en mesure d’accéder à des hôtes ou des actifs supplémentaires.

« L’accès aux organisations et aux référentiels SCM est obtenu en permanence par des attaquants », a commenté Gil.

« Les informations d’identification, les jetons d’accès et les clés SSH sont volés par l’une des méthodes d’attaque classiques telles que le phishing, le credential stuffing ou le mouvement latéral dans le réseau interne d’une entreprise. »

Il a ajouté : « L’EPI est un vecteur permettant aux attaquants d’exploiter cet accès pour exécuter du code malveillant dans les pipelines CI, ouvrant la voie à l’accès aux environnements de production en quelques minutes, voire quelques secondes.

VOUS POURRIEZ AUSSI AIMER Un nouvel outil peut découvrir du texte expurgé et pixélisé pour révéler des données sensibles

Sur Reddit, certains ont demandé s’il y avait quelque chose de nouveau à propos de ce vecteur d’attaque et si la condition préalable aux autorisations annulait le risque global d’EPI. Travis Biehn, consultant principal en sécurité chez Synopsys Software Integrity Group, a déclaré La gorgée quotidienne:

Omer Gil fournit une vision non alarmiste d’un vecteur d’attaque mal compris. C’est exagéré ? Peut-être, mais pas par Omer. C’est un choix peu probable pour un attaquant, et les scénarios où c’est pratique ou nécessaire sont peu nombreux.

« Il a été dit que chaque entreprise est une entreprise de logiciels », a ajouté Theresa Lanowitz, responsable de l’évangélisation de la cybersécurité chez AT&T Business. « Si les applications qui composent l’expérience numérique ne sont pas construites avec une approche axée sur la sécurité, les vulnérabilités arriveront en production et finiront par poser des problèmes pour l’entreprise du point de vue des revenus, de la confiance ou de la sécurité générale.

« Par conséquent, les applications ou applet – nous n’écrivons plus d’applications de back-office monolithiques – créées aujourd’hui et dans le futur doivent non seulement être plus compactes et axées sur les objectifs, mais également conçues dans un souci de sécurité. »

CONSEILLÉ La vulnérabilité de sécurité Web Grafana a ouvert une pléthore de possibilités d’attaque