Qu'est-ce qui peut mal se passer avec CI/CD pipelines?

Intégration continue et livraison continue (CI/CD) pipelineLes s constituent le fondement de toute organisation logicielle qui crée des logiciels de manière « moderne ». L’automatisation offre un grand pouvoir, mais la plupart des développeurs négligent la responsabilité qu’elle implique.

Développeur : Ouais, nous prenons CI/CD Sécurité sérieusement et avoir un contrôle strict sur les responsables du code, réviser commits avant les fusions ; des emplois et pipelines sont entretenus par des cadres supérieurs, ils veillent à ne pas divulguer de secrets dans le pipelines. Et l’outil a été installé par du personnel qui connaît le sujet. Qu'est-ce qui peut mal se passer ?

Cher développeur, CI/CD Les systèmes sont complexes. Leur large surface d'attaque attire les acteurs malveillants. Mieux vaut se méfier et ne jamais se laisser aller à l'excès de confiance.

La configuration par défaut est parfois conservée et devient le meilleur allié des pirates informatiques. Des failles critiques peuvent être présentes dans CI/CD pipeline sources, dans la configuration du système, ou autour du processus et du contexte du pipeline et comment il est déclenché.

Dans cet article, nous nous mettrons à la place des mauvais acteurs. Imaginez que nous lisions les réflexions de M3M3N70 (Memento Mori ?) et Rage des marais quelque part sur le dark web, probablement dans une langue non occidentale, mais ne manquez jamais que le mal se propage dans le monde entier.

 

Au bon vieux temps, c’était si simple…

M3M3N70: Au bon vieux temps, notre activité était tellement simple… Les Zero Days étaient des fruits à portée de main, les applications étaient grandes ouvertes avec des vulnérabilités faciles à exploiter, et nous pouvions évoluer latéralement en un clin d'œil.

Rage des marais: Fu#@Enfer ! Certains ont encore eu des idées farfelues, mais les choses ont changé. Les grands ont mis beaucoup d'argent sur cette merde d'AppSec.

M3M3N70: Oui. Mais les nouveaux imbéciles, ce sont les développeurs. Pour nous, il a été plus facile d'opter pour leurs outils. L'intégration continue, en particulier, est une mine d'or ! Jetons d'accès au cloud, SCM identifiants, mots de passe de la base de données de production, clés privées SSH, identifiants des autres utilisateurs de CI… Passer des choses ennuyeuses du développement à la vraie viande était plutôt trivial.

Automatisation pour la création, le test et le déploiement de logiciels avec un CI/CD L'outil nécessite souvent de transmettre des secrets aux commandes par étapes. Ces secrets sont souvent divulgués, avec des conséquences désastreuses.

PipelineJ'ai besoin de secrets qui sont parfois divulgués

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

Peut-être que le bon vieux temps consistait à trouver dans l'histoire de Git un .env fichier (le développeur a oublié de l'ajouter à .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

qui a été utilisé dans un workflow GitHub .github/deploy.yaml qui contenait quelque chose comme ceci :

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70 : wow ! Ces clés AWS fonctionnaient ! Nous avons d’abord testé un changement inocuos dans l’application, puis avons ajouté la piqûre car ces gars ne semblaient pas le savoir. Bingo ! Quelle campagne…

Le méchant a simplement utilisé les clés AWS pour télécharger une application modifiée avec un logiciel malveillant, puis a exécuté la commande de déploiement avec ces informations d'identification. Les secrets divulgués, ainsi que les informations contenues dans le pipeline. « Quelle campagne ! » Cela signifie probablement que Memento a fait des ravages chez la pauvre victime.

Ce que Memento nous dit ici, c'est qu'une fois qu'une fuite de secret s'est produite, comme les clés d'accès AWS dans l'exemple, vous devez révoquer le secret (faire pivoter les clés ci-dessus) immédiatement . Il y a toujours un fenêtre d'exposition entre la fuite commit et l'invalidation secrète ; réécrire l'histoire de Git est difficile (même l'État autoritaire le plus dur a tenté une telle réécriture de l'histoire, en vain) et probablement inefficace (nos amis auraient pu cloner avant le référentiel avec la fuite secrète commit). Faites pivoter les clés immédiatement et priez tout en lisant les journaux d'activité du compte ciblé pendant la fenêtre d'exposition !

Les organisations devraient probablement interdiction d'utiliser des secrets à long terme dans CI/CD pipelines, et remplacez-les par des informations d'identification temporelles. Dans l'exemple précédent avec les clés AWS dans les actions GitHub, il est plus sûr d'utiliser un Fournisseur OpenID Connect (OIDC) pour obtenir les informations d'identification de courte durée nécessaires aux actions.

Rage des marais: Vous avez eu tellement de chance ! Autrefois, la fuite de scripts avec des clés codées en dur était une pratique courante, même sur les compartiments S3 accessibles au public. Tout ce que vous aviez à faire est de parcourir les objets dans le compartiment et de faire quelques recherches pour trouver des choses intéressantes.

Parfois, la zone utilisée pour le déploiement (un compartiment AWS S3 dans cet exemple) était ouverte à la lecture par des tiers, en raison d'un défaut de configuration (qui n'a pas été détecté). Quoi Rage des marais utilisé ressemblait à ceci :

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

Le compartiment a probablement été créé dans un modèle de provisionnement qui pourrait être automatiquement analysé à la recherche de failles de sécurité.

La configuration par défaut de l'outil était un jouet pour nous

Pour donner des exemples concrets parlons de Jenkins, l'un des outils CI les plus populaires.

Rage des marais: Vous souvenez-vous de la case à cocher « Activer la sécurité » dans Jenkins, et du nombre d'organisations qui ont choisi de ne pas l'activer pour des raisons de commodité ? Et celles "N'importe qui peut faire n'importe quoi" Combinaisons d'autorisations par défaut ? Et ces satanés plugins Jenkins, comme le Plugin GitHub OAuth? La personne qui l'a configuré a sélectionné à la fois « Accorder les autorisations READ à tous les utilisateurs authentifiés » et « Utiliser les autorisations du référentiel GitHub », nous donnant accès à tous leurs projets.

(Désolé, Jenkins, de t'avoir donné l'exemple 😉

Restez adepte (voire accro) des principes de sécurité. L'un est le Sécurisé par défaut principe : les contrôles doivent être paramétrés par défaut avec les paramètres les plus sécurisés possibles. La sécurité doit être intégrée CI/CD outils et pipelines à partir de la base, plutôt que d'être une réflexion après coup. Mais la convivialité et la commodité entrent souvent en conflit avec la sécurité.

Pour le cas Jenkins, l'authentification intégrée est trop fragile : n'utilisez jamais les mécanismes d'authentification intégrés dans Jenkins. Mieux vaut opter pour un mécanisme tiers (SAML, LDAP, Google…), avec le plugin Role-based Authorization Strategy (« RBAC »). Et soyez extrêmement prudent avec le admin compte.

Prenez soin de la façon dont le travail et pipeline les fichiers dans Jenkins sont gérés. De même Plugin de configuration en tant que code et ses fichiers de configuration, qui s'appliquent à la configuration Jenkins.

Passer d'un hébergement auto-hébergé CI/CD Le passage des systèmes SaaS basés sur le cloud élimine certains risques potentiels permettant un mouvement latéral au sein du réseau de l'organisation, mais en ajoute d'autres, comme la nécessité d'ouvrir des connexions externes entre les systèmes internes existants et les systèmes externalisés. CI/CD outil.

Les organisations devraient s'efforcercise soin dû au durcissement du CI/CD système, en commençant par les paramètres les plus restrictifs et en s'ouvrant progressivement avec les autorisations minimales requises pour le pipeline pas.

Configuration de la sécurité dans CI/CD Les outils peuvent s'avérer complexes. Nombre d'entre eux disposent de plugins ou d'extensions présentant la plupart des vulnérabilités et nécessitant une mise à jour.

Des scanners de mauvaise configuration de sécurité pour des outils aussi complexes ou des tests de référence peuvent être utiles.

Injecter du code dans pipeline commandes pour le plaisir et le profit

M3M3N70: Avez-vous déjà utilisé des extractions de code non fiables, des actions et des scripts vulnérables à l'injection de commandes ?

Cette section montre que le pipeline lui-même pourrait comporter des erreurs de codage permettant à de mauvais acteurs d'injecter l'exécution de code arbitraire dans le pipeline sans changer le pipeline source elle-même. Par exemple en utilisant un PR

Un premier exemple de malheureux workflow GitHub:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

La combinaison pull_request_target Le déclenchement de workflow avec une extraction explicite d'un PR non fiable est une pratique dangereuse qui peut conduire à une compromission du référentiel. Dans l'exemple, la malheureuse combinaison de :

• pull_request_target événement, qui par défaut ont une autorisation d'écriture sur le référentiel cible et les secrets du référentiel cible, même à partir de forks externes, et s'exécutent dans le contexte du référentiel cible du PR,
• consultez le code PR de la source, dépôt non fiable,
• déclencher tout script susceptible d'opérer sur des contenus contrôlés par PR, comme dans le cas de npm install et
• ne pas utiliser de condition pour le déclenchement pull_request_target l'événement ne s'exécutera que si une sorte d'étiquette « ce PR a été vérifié » est attribuée au PR (les utilisateurs externes ne peuvent pas attribuer d'étiquettes au PR).

Un deuxième exemple prend une entrée non fiable (provenant d'un problème, d'un commentaire ou pull request) comme source pour les arguments passés à un pipeline commande via des expressions. C'est le pipeline version de la vulnérabilité d’injection de commande du système d’exploitation.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

L'opération d'exécution génère un script shell temporaire basé sur le modèle, avec $ remplacé, le rendant vulnérable à l'injection de commandes shell. Un attaquant disposant d'un faux compte GitHub pourrait créer un problème avec un titre a"; bad_code_goes_here;#, et boum ! 

Rage des marais: Oh, ces gars ouvraient la porte à l'injection de commandes en ouvrant simplement un problème…

Il y avait des vulnérabilités d'exécution de code dans les actions GitHub, comme Gajira-commentaire, maintenant corrigé. Lisez s'il vous plaît « Entrée non fiable dans les workflows GitHub » pour plus de détails.

La morale de l'histoire: Ne commandez et ne créez jamais de PR à partir de sources non fiables sans d'abord examiner le PR. « Non fiable » ici, à moins d'une authentification draconienne de la provenance, pourrait signifier tout compte de développeur potentiellement piraté.

 

Déploiement involontaire de logiciels malveillants ici !

Déploiement continu est le point culminant de l’automatisation, mais ce point culminant pourrait être contrecarré par le manque de contrôles d’approbation appropriés sur le pipeline débit.

Les risques d’un déploiement entièrement automatisé depuis la source commit aux systèmes de production incluent la possibilité que du code malveillant soit déployé dans les environnements de production sans être détecté, ainsi que la possibilité que des erreurs dans le processus de déploiement provoquent des perturbations ou des pannes.

Afin d'atténuer ces risques, il est souvent recommandé aux organisations de mettre en œuvre une « pause brutale » dans leur processus de déploiement, ce qui nécessite approbation humaine avant que les versions ne soient déployées dans les environnements finaux.

Ils ferment les portes

Rage des marais:Ces joyeux mots de passe par défaut dans CI/CD outils sont en train d'être effacés. Accéder au /var/lib/jenkins/secrets/initialAdminPassword est maintenant une piste morte. De nombreux outils proposent désormais le 2FA, que Covid a rendu populaire, et même le singe codeur le plus paresseux l'utilise !

M3M3N70: Nous luttons contre la 2FA, mais ce n'est pas si simple. Il est difficile de harceler ces types, car "Scatter Swine" réalisé avec Twilio. Avec les clés WebAuthn, c'est beaucoup plus difficile. Au moins, nous pouvons essayer de voler des cookies pour contourner MFA, mais il faut entrer dans la boîte du développeur.

L'authentification multifacteur est un bon pas dans la bonne direction pour limiter le risque de fuite de secrets d'authentification. La plupart des outils DevOps modernes prennent en charge MFA. Et les clés d'authentification sous WebAuthn/U2F (voir Projet FIDO2) sont peut-être la meilleure option pour la MFA dans DevOps, si elle est correctement gérée.

Rage des marais: Les gars du DevOps se réveillent. Ils ont ce foutu « moindre privilège » dans le sang. Et ce ne sont plus des singes codés. Nous sommes désormais pris en flagrant délit par les critiques.

Ainsi, pipelineLes s sont maintenant un peu plus robustes qu'il y a quelques années, avec des actions et des scripts faibles supprimés, et avec des étapes de tests de sécurité supplémentaires qui ont même détecté nos compte-gouttes cachés furtivement. commits et paquets que nous avons détournés.

Question pour le lecteur : le processus de création du logiciel à partir des sources et de déploiement en production est-il une activité risquée ? Pouvez-vous voir votre DevOps au stade de vieux, de bons moments pour les méchants ?

Recommandations finales

Par où commencer CI/CD pipelines ?

La première recommandation est simple ici : Soigneusement évaluation pipelines (ils sont critique ressources) pour les questions de sécurité. Les examens sont coûteux mais nécessaires et doivent être effectués correctement. Les évaluateurs doivent savoir ce qu’ils doivent examiner. Chaque étape doit être vérifiée pour détecter les défauts.

Peut-être qu’une combinaison d’examinateurs experts armés de scanners automatisés de codes malveillants pourrait aider.

La deuxième recommandation est de former des développeurs qui écrivent pipelines et les maintenir en sécurité. Choses à considérer:

• Comment gérer correctement l'authentification avec les services internes et cloud, en évitant la nuisance liée à la gestion des informations d'identification à long terme.
• Comment limiter pipelines à l’ensemble exact de ressources auquel il a besoin d’accéder. Le principe du moindre privilège brille à nouveau.
• Comment écrire les étapes à réaliser pipelineest reproductible comme l’épinglage de version et évite les vulnérabilités d’injection de commandes.
• Comment approuver les déploiements du point de vue de la sécurité (ce sont d'autres !) : quelle sécurité standards doivent être mis en correspondance et comment ajouter les contrôles/portes correspondants dans le pipelines.

Une troisième recommandation est de configurer le CI/CD système avec le soin nécessaire. Authentification forte, pas de mots de passe par défaut ni de paramètres non sécurisés, privilèges minimaux… Prenez soin des vulnérabilités des plugins et extensions installés. Cela pourrait être le sujet des articles suivants, restez à l’écoute.

La quatrième recommandation est de exploiter le CI/CD pipelines pour l'automatisation de la sécurité. Analyse du code source (SAST), analyse de la composition de la source (SCA), l'analyse des fuites de secrets, les outils anti-malware, les scanners de sécurité des conteneurs ou les détecteurs d'exécution automatisés (DAST et malware) peuvent être exécutés régulièrement sur le pipeline. Et votre organisation peut appliquer standards à propos de la couverture des analyses de sécurité dans CI/CD.

Rappelez-vous que ces outils ne suppriment pas encore l’avis d’experts de l’équation, sinon vous pourriez avoir un faux sentiment de sécurité.

Si vous êtes adepte du top 10 OWASP, un joli projet récent est le OWASP Top 10 CI/CD Risque de sécurité.

Avis de non-responsabilité

(1) Les exemples dans cet article utilisent GitHub comme SCM, AWS comme fournisseur de cloud et GitHub Actions ou Jenkins comme CI/CD Outil. Ils ne sont ni plus faibles ni plus sûrs que leurs alternatives. Aucune mauvaise intention médiatique ! Ces outils sont puissants et doivent être utilisés à bon escient.

(2) M3M3N70 et Rage des marais sont des personnages fictifs. Toute ressemblance avec des personnes ou des groupes, vivants ou morts, n’est qu’une coïncidence… ou l’est-ce ?

Pour en savoir plus

• Haymore, A. et coll. « 10 histoires réelles sur la façon dont nous avons fait des compromis CI/CD pipelines ”. Groupe NCC, janvier 2022.
• configure-aws-credentials Action GitHub et Configuration d'OpenID Connect dans Amazon Web Services pour plus de détails sur la façon d'exécuter les commandes AWS pour le déploiement dans les workflows GitHub.
• Lobacevski J. « Garder la sécurité de vos actions et flux de travail GitHub Partie 1 : Prévenir les requêtes pwn ». Laboratoire de sécurité GitLab, décembre 2020.
• Lobacevski J. « Garder vos actions et flux de travail GitHub sécurisés, partie 2 : entrée non fiable ». Laboratoire de sécurité GitLab, janvier 2021.
• OWASP. « Top 10 de l'OWASP CI/CD « Risques de sécurité ». Juillet 2022.
• Saltzer J. & Schroeder M. « La protection des informations dans les systèmes informatiques ». Avril 1975. Les principes de sécurité ont évolué avec la technologie, mais 47 ans plus tard, la plupart des idées S&S restent en vigueur.
• NCSC britannique. « Sécuriser la construction et le déploiement pipeline ». Centre national de cybersécurité du Royaume-Uni, février 2019.