Qu'est-ce qu'une attaque de l'homme du milieu et comment cible-t-elle ? Pipelines
Si vous vous demandez ce qu'est une attaque de l'homme du milieu en DevOps, sachez qu'il ne s'agit pas simplement d'une technique générique de reniflage réseau. Il s'agit d'une attaque ciblée. façon de compromettre votre CI/CD pipelines en interceptant et en manipulant des données en transit, des dépendances, des scripts ou des artefacts, lorsque le cryptage est faible ou absent.
Prenons un scénario réel : un exécuteur d'intégration continue récupère des dépendances depuis un dépôt tiers via HTTP. Si TLS est mal configuré, ou pire, absent, des attaquants peuvent intercepter cette requête et injecter des paquets malveillants apparemment légitimes. pipelineCes artefacts pourraient être créés et déployés sans que personne ne s'en aperçoive. C'est une attaque de l'homme du milieu classique, mais avec CI/CD conséquences.
L'attaque n'a pas besoin de briser le chiffrement ; elle exploite des configurations faibles. Prenons l'exemple d'un conteneur qui télécharge une image de base ou un script depuis un dépôt interne sans authentification. C'est une occasion pour une attaque de type « MITM » si le trafic interne n'est ni chiffré ni segmenté. Si vous ne savez toujours pas ce qu'est une attaque de l'homme du milieu, considérez-la comme un acteur invisible modifiant silencieusement ce que vous faites. pipeline consomme, sans laisser de traces évidentes.
Où le Pipeline Pauses : véritables points d'entrée MITM dans CI/CD
Il existe plusieurs points faibles où une attaque de l'homme du milieu peut prendre le contrôle des flux DevOps :
- Récupération de paquets via HTTP: Courant dans les versions héritées ou les registres auto-hébergés. Si vous extrayez Paquets Python, NPM modules, ou Images Docker sans HTTPS, vous êtes exposé.
- Sources non vérifiées: PipelineLes utilisateurs utilisent souvent des outils communautaires ou open source sans en valider l'intégrité. Les attaquants de type « MITM » peuvent altérer ces téléchargements.
- Référentiels d'artefacts sans authentification:Les buckets S3, les serveurs Git LFS ou les magasins d'artefacts internes accessibles via HTTP simple sont des cibles faciles.
- Services internes non sécurisés:De nombreux internes CI/CD Les outils (exécuteurs, agents, scripts de déploiement) supposent la sécurité du périmètre réseau. MITM peut exploiter cette hypothèse.
Exemple :
dependencies: - wget http://internal.repo.local/package.tar.gz ⚠️ Exemple non sécurisé : ne pas utiliser en production
Si ce trafic est intercepté, l'attaquant n'a plus qu'à servir un message manipulé. .tar.gz avec une charge utile. Celle-ci est décompressée et exécutée pendant la phase de construction. C'est précisQu'est-ce que l'attaque de l'homme du milieu fait dans les systèmes modernes ? pipelines : il exploite les hypothèses de confiance.
Builds malveillants : injection de code pendant l'exécution et la génération
Les attaques de l'homme du milieu vont au-delà de l'interception ; elles conduisent à l'injection de code. Une fois qu'une dépendance ou un artefact malveillant pénètre dans le pipeline, l'attaquant contrôle la construction.
- Injection de temps de constructionLes compilateurs ou scripts de build exécutant des dépendances non vérifiées peuvent contenir du code trojanisé. Imaginez une ligne obscurcie dans un Makefile exécutée avec des autorisations élevées.
- Injection d'exécution: Les variables d'environnement ou les secrets exposés en clair peuvent être capturés et réutilisés. Si votre runner enregistre exporter AWS_SECRET_KEY=…, vous avez une fuite qui risque de se produire.
- Manipulation dynamique des étapes: CI défini par YAML pipelineLes scripts dynamiques s'appuient souvent sur curl/wget. Si ceux-ci ne sont pas protégés, les attaquants peuvent les remplacer à la volée.
curl http://setup.ci/init.sh | bash # Dangerous without TLS and verification ⚠️ Exemple non sécurisé : ne pas utiliser en production
Savoir ce qu’est une attaque de l’homme du milieu permet de mieux comprendre comment ces injections se produisent : l’attaquant fait partie du processus de livraison, injectant des instructions malveillantes sans accès direct à votre code source.
Sécuriser les DevOps Pipelines Contre les risques d'attaque de l'homme du milieu
Vous ne pouvez pas éliminer les menaces d'attaque de l'homme du milieu, mais vous pouvez faire pipelineIl est beaucoup plus difficile de faire des compromis.
Mesures concrètes à prendre :
- Appliquez toujours TLS:Chaque artefact, dépendance et script doit être récupéré via HTTPS.
- Vérifier les sommes de contrôle/hachages:Utilisez SHA256 ou des digests plus forts et validez avant l'exécution.
- Signer et vérifier les artefacts:Utilisez Sigstore ou in-toto pour garantir la provenance.
- Exécuteurs CI sécurisés: Isolez les environnements, évitez les exécuteurs partagés et désactivez l'accès au shell lorsque cela est possible.
- Isoler les secretsInjectez les secrets uniquement aux étapes qui en ont besoin. Ne les imprimez jamais et ne les stockez jamais dans les journaux.
étapes:
- name: Fetch run: | curl -fsSL https://secure-repo.com/tool.sh -o tool.sh echo "<sha256> tool.sh" | sha256sum -c - ✅ Vérifie l'intégrité du script avant l'exécution
Ce sont ces types de mesures de renforcement qui font de l’attaque de l’homme du milieu une question théorique et non un incident de production.
Pourquoi cela est important : impact sur la chaîne d'approvisionnement et amplification des risques
Une attaque de l'homme du milieu dans un CI/CD pipeline ce n'est pas seulement un problème local ; cela corrompt tout votre chaîne d'approvisionnement de logiciels. Chaque consommateur de votre build est en danger.
Lorsqu'un artefact malveillant pénètre dans une build, il est distribué en aval :
- Les conteneurs compromis sont envoyés en production.
- Les bibliothèques empoisonnées sont publiées dans des registres publics.
- Les clients installent des logiciels de porte dérobée.
C’est ce type d’amplification qui explique pourquoi les attaques contre la chaîne d’approvisionnement sont si dommageables. MITM c'est souvent la première étape, pas le but final. Si vous vous demandez ce qu'est une attaque de l'homme du milieu, vous le savez maintenant : c'est un point de départ pour une compromission de la chaîne complète.
Conclusion : Décalage vers la gauche sur Pipeline Security
Une attaque de type « man-in-the-middle » dans DevOps ne consiste pas en une écoute passive ; il s'agit d'un détournement actif de flux non sécurisés dans votre environnement. CI/CD. TLS mal configuré, des sources non authentifiées et des artefacts non vérifiés ouvrent la porte. Les développeurs doivent traiter pipelineC'est comme du code de production : testé, validé et sécurisé. Cela signifie aucun téléchargement non authentifié, aucune source HTTP et aucune exécution dynamique sans vérification.
Des outils comme Xygéni aider les équipes à renforcer leurs pipelineen détectant les points faibles, en vérifiant l'intégrité des artefacts et détecter les altérations de dépendances avant qu'elles ne se propagent. Le déplacement vers la gauche n'est pas facultatif ; c'est ainsi que vous gardez une longueur d'avance sur les menaces AppSec du monde réel. Comprendre ce qu'est une attaque de l'homme du milieu ne suffit pas. Il faut la détecter, la prévenir et cesser de la traiter. pipeline en tant que citoyen de seconde classe dans votre modèle de sécurité.
