『Teknik - Living Off the Pipeline - From Supply Chain 0-Days to Predicting the next XZ-like attacks - Parce que... c'est l'épisode 0x602!』のカバーアート

Teknik - Living Off the Pipeline - From Supply Chain 0-Days to Predicting the next XZ-like attacks - Parce que... c'est l'épisode 0x602!

Teknik - Living Off the Pipeline - From Supply Chain 0-Days to Predicting the next XZ-like attacks - Parce que... c'est l'épisode 0x602!

無料で聴く

ポッドキャストの詳細を見る

このコンテンツについて

 Parce que… c’est l’épisode 0x602! Shameless plug 27 et 29 juin 2025 - LeHACK12 au 17 octobre 2025 - Objective by the sea v810 au 12 novembre 2025 - IAQ - Le Rendez-vous IA Québec17 au 20 novembre 2025 - European Cyber Week25 et 26 février 2026 - SéQCure 2065 Description Introduction et contexte François Proulx fait son retour pour présenter l’évolution de ses recherches sur la sécurité des chaînes d’approvisionnement (supply chain) depuis sa présentation de l’année précédente. Ses travaux portent sur la détection de vulnérabilités dans les pipelines de construction (build pipelines) des projets open source, un sujet qui avait suscité beaucoup d’intérêt suite à l’incident XZ Utils. Évolution de la méthodologie de recherche Depuis l’année dernière, l’équipe de François a considérablement amélioré ses outils et sa stratégie de détection. Plutôt que de scanner massivement tous les dépôts disponibles, ils ont adopté une approche plus ciblée en se concentrant sur des entités majeures comme Google, Red Hat, Nvidia et Microsoft. Ces organisations sont des contributeurs importants de projets open source critiques et bien maintenus. Cette nouvelle approche leur permet de découvrir des centaines d’organisations GitHub par entité, chacune contenant parfois des milliers de dépôts. L’objectif reste le même : détecter des vulnérabilités zero-day dans les build pipelines qui permettent de compiler, tester et distribuer les projets open source, notamment via GitHub Actions. La problématique fondamentale des CI/CD François présente une analogie frappante pour expliquer la dangerosité des systèmes d’intégration continue : “un CI/CD, c’est juste du RCE as a service” (Remote Code Execution as a Service). Ces systèmes sont des applications web qui attendent de recevoir des déclencheurs sur une interface publique accessible via Internet. Dans le cas de GitHub Actions, il suffit d’ouvrir une pull request pour déclencher automatiquement l’exécution de tests. Cette situation rappelle les vulnérabilités des années 1990-2000 avec les débordements de pointeurs. François utilise une formule percutante : “les build pipelines ressemblent à une application PHP moyenne de 2005 en termes de codage sécurisé”. Cette comparaison souligne que malgré les décennies d’évolution en sécurité informatique, les mêmes erreurs fondamentales se répètent dans de nouveaux contextes. Les mécanismes d’exploitation Les vulnérabilités exploitent principalement les entrées non fiables (untrusted input) provenant des pull requests. Même les brouillons de contributions peuvent déclencher automatiquement l’exécution de tests avant qu’un mainteneur soit notifié. Le problème s’aggrave quand les pipelines nécessitent des secrets pour communiquer avec des systèmes externes (notifications Slack, télémétrie, etc.). Par défaut, GitHub Actions hérite parfois d’anciennes permissions en lecture-écriture, ce qui permet aux tests d’avoir accès à un token avec des droits d’écriture sur le dépôt. Cette configuration peut permettre à un attaquant d’écrire dans le dépôt de manière non visible. Résultats impressionnants des analyses L’équipe a considérablement affiné ses outils de détection. À partir de 200 000 résultats initiaux, ils appliquent des règles plus précises pour identifier environ 10 000 cas intéressants. Ces règles valident non seulement la présence de vulnérabilités, mais aussi les critères d’exploitation et la présence de secrets exploitables. Après validation manuelle, environ 25% de ces 10 000 cas s’avèrent facilement exploitables. Ces chiffres démontrent l’ampleur du problème dans l’écosystème open source, même en reconnaissant l’existence probable de nombreux faux négatifs. Cas concrets : Google et les régressions François rapporte avoir découvert des vulnérabilités dans 22 dépôts appartenant à Google, notamment dans un projet lié à Google Cloud (probablement Data Flow). Après avoir signalé et reçu une récompense pour la correction, une régression est survenue une semaine plus tard dans le même workflow, leur valant une seconde récompense. Cette situation illustre un problème récurrent : même les grandes organisations comme Google peuvent reproduire les mêmes erreurs après correction, souvent par méconnaissance des mécanismes sous-jacents de ces nouvelles techniques d’exploitation. L’affaire Ultralytics : un cas d’école L’incident le plus marquant concerne la bibliothèque Python Ultralytics, très populaire pour la détection d’images par apprentissage automatique. En août, l’équipe avait détecté une vulnérabilité dans ce projet mais s’était concentrée sur les découvertes chez Google, négligeant de signaler cette faille. En décembre, Ultralytics a été compromis par l’injection d’un crypto-mineur, exploitant ...

Teknik - Living Off the Pipeline - From Supply Chain 0-Days to Predicting the next XZ-like attacks - Parce que... c'est l'épisode 0x602!に寄せられたリスナーの声

カスタマーレビュー：以下のタブを選択することで、他のサイトのレビューをご覧になれます。

Audible.co.jp

Amazon.co.jp
レビューはまだありません。