Google a introduit le cadre SLSA (Supply-chain Levels for Software Artifacts), qui résume l'expérience existante en matière de protection des infrastructures de développement contre les attaques menées au stade de l'écriture du code, des tests, de l'assemblage et de la distribution d'un produit.
Les processus de développement deviennent de plus en plus complexes et dépendants d'outils tiers, ce qui crée des conditions favorables à la progression d'attaques liées non pas à l'identification et à l'exploitation des vulnérabilités du produit final, mais à la compromission du processus de développement lui-même (attaques de la chaîne d'approvisionnement, généralement destinées à introduction de modifications malveillantes dans le processus d'écriture du code, substitution de composants distribués et de dépendances).
Le framework prend en compte 8 types d'attaques liées à la menace d'apporter des modifications malveillantes au stade du développement du code, de l'assemblage, des tests et de la distribution du produit.
- A. Y compris les modifications dans le code source qui contiennent des portes dérobées ou des erreurs cachées conduisant à des vulnérabilités.
Exemple d'attaque : « Hypocrite Commits » - une tentative de promotion de correctifs présentant des vulnérabilités dans le noyau Linux.
Méthode de sécurité suggérée : examen indépendant de chaque modification par deux développeurs.
- B. Compromission de la plateforme de contrôle du code source.
Exemple d'attaque : injection de commits malveillants avec une porte dérobée dans le dépôt Git d'un projet PHP après fuite des mots de passe des développeurs.
Méthode de protection suggérée : Sécurité accrue de la plateforme de gestion de code (dans le cas de PHP, l'attaque a été réalisée via une interface HTTPS peu utilisée, qui permettait d'envoyer des modifications lors de la connexion avec un mot de passe sans vérifier la clé SSH, malgré le fait que MD5, peu fiable, a été utilisé pour hacher les mots de passe).
- C. Apporter des modifications au stade du transfert du code vers le système de build ou d'intégration continue (le code qui ne correspond pas au code du référentiel est construit).
Exemple d'attaque : injection d'une porte dérobée dans Webmin en apportant des modifications à l'infrastructure de build, entraînant l'utilisation de fichiers de code différents des fichiers du référentiel.
Méthode de protection proposée : Vérification de l'intégrité et identification de la source du code sur le serveur d'assemblage.
- D. Compromission de la plateforme d'assemblage.
Exemple d'attaque : l'attaque SolarWinds, au cours de laquelle l'installation d'une porte dérobée dans le produit SolarWinds Orion a été assurée lors de la phase d'assemblage.
Méthode de protection proposée : mise en place de mesures de sécurité avancées pour la plateforme d'assemblage.
- E. Promotion de code malveillant via des dépendances de mauvaise qualité.
Un exemple d'attaque : l'introduction d'une porte dérobée dans la bibliothèque de flux d'événements populaire en ajoutant une dépendance inoffensive, puis en incluant du code malveillant dans l'une des mises à jour de cette dépendance (la modification malveillante n'a pas été reflétée dans le référentiel git, mais a été présent uniquement dans le package MNP fini).
Méthode de protection suggérée : appliquer de manière récursive les exigences SLSA à toutes les dépendances (dans le cas d'un flux d'événements, la vérification révélerait l'assemblage de code qui ne correspond pas au contenu du référentiel Git principal).
- F. Téléchargement d'artefacts non créés dans le système CI/CD.
Exemple d'attaque : ajout de code malveillant au script CodeCov, qui a permis aux attaquants d'extraire des informations stockées dans les environnements du système d'intégration continue des clients.
Méthode de protection proposée : contrôle de la source et de l'intégrité des artefacts (dans le cas de CodeCov, il pourrait être révélé que le script Bash Uploader envoyé depuis le site codecov.io ne correspond pas au code du référentiel du projet).
- G. Compromission du référentiel de packages.
Exemple d'attaque : les chercheurs ont pu déployer des miroirs de certains référentiels de packages populaires afin de distribuer des packages malveillants via eux.
Méthode de protection suggérée : Vérification que les artefacts distribués sont compilés à partir des codes sources déclarés.
- H. Confondre l'utilisateur pour installer le mauvais package.
Exemple d'attaque : utilisation du typosquatting (NPM, RubyGems, PyPI) pour placer des packages dans des référentiels dont l'écriture est similaire à celle d'applications populaires (par exemple, coffe-script au lieu de coffee-script).
Pour bloquer les menaces signalées, SLSA propose un ensemble de recommandations, ainsi que des outils pour automatiser la création de métadonnées d'audit. SLSA résume les méthodes d'attaque courantes et introduit le concept de couches de sécurité. Chaque niveau impose certaines exigences d'infrastructure pour garantir l'intégrité des artefacts utilisés dans le développement. Plus le niveau SLSA pris en charge est élevé, plus les protections sont mises en œuvre et mieux l'infrastructure est protégée contre les attaques courantes.
- SLSA 1 exige que le processus de construction soit entièrement automatisé et génère des métadonnées (« provenance ») sur la façon dont les artefacts sont construits, y compris des informations sur les sources, les dépendances et le processus de construction (un exemple de générateur de métadonnées pour l'audit est fourni pour les actions GitHub). SLSA 1 n'inclut pas d'éléments de protection contre les modifications malveillantes, mais identifie simplement le code et fournit des métadonnées pour la gestion des vulnérabilités et l'analyse des risques.
- SLSA 2 - étend le premier niveau en exigeant l'utilisation de services de contrôle de version et d'assemblage qui génèrent des métadonnées authentifiées. L'utilisation de SLSA 2 vous permet de retracer l'origine du code et empêche les modifications non autorisées du code dans le cas de services de build fiables.
- SLSA 3 - confirme que le code source et la plateforme de build répondent aux exigences des normes qui garantissent la capacité d'auditer le code et garantissent l'intégrité des métadonnées fournies. On suppose que les auditeurs peuvent certifier les plateformes par rapport aux exigences des normes.
- SLSA 4 est le niveau le plus élevé, complétant les niveaux précédents avec les exigences suivantes :
- Examen obligatoire de toutes les modifications par deux développeurs différents.
- Toutes les étapes de construction, le code et les dépendances doivent être entièrement déclarés, toutes les dépendances doivent être extraites et vérifiées séparément, et le processus de construction doit être effectué hors ligne.
- L'utilisation d'un processus de build répétable vous permet de répéter le processus de build vous-même et de vous assurer que l'exécutable est construit à partir du code source fourni.
Source: opennet.ru