À mesure que le développement logiciel progresse tout au long du cycle de vie de la chaîne d'approvisionnement logicielle, l'étape du package apparaît comme un moment crucial, convertissant le code source en artefacts exécutables préparés pour la distribution. Cette étape critique n’est cependant pas à l’abri de vulnérabilités, ce qui en fait une cible privilégiée pour les acteurs malveillants cherchant à porter atteinte à l’intégrité et à la sécurité des logiciels. Cet article de blog examine les menaces courantes qui peuvent survenir au cours de cette phase et présente des stratégies efficaces pour les atténuer. Ce contenu s'inscrit dans la continuité de notre série de blogs explorant software supply chain security à travers SDLC.
L'étape du package dans le cycle de vie du développement logiciel
L'étape de conditionnement du cycle de vie de la chaîne d'approvisionnement des logiciels englobe le processus de conditionnement et de préparation des logiciels pour leur distribution aux utilisateurs. Cette étape implique la création de packages d'installation, la gestion des dépendances et la génération de métadonnées pour le logiciel.
Les menaces d'intégrité de build sont des vulnérabilités qui pourraient permettre aux attaquants d'introduire des modifications non autorisées dans le logiciel pendant le processus de packaging. Ces menaces peuvent être introduites par diverses méthodes, telles que la compromission du registre des packages, l'exploitation des vulnérabilités des outils de packaging ou la manipulation de dépendances tierces.
La dépendance totale aux composants open source dans les logiciels modernes a fait de cette étape la plus fréquenteSCA Cible. Intégrer un malware furtif dans un composant open source populaire est un rêve pour de nombreux cybercriminels. C'est pourquoi plus de 245,000 2023 packages malveillants ont été découverts en XNUMX.
Des exemples de Software Supply Chain Security Menaces au stade du package
Utiliser un package compromis
Il s'agit du fait de déployer ou d'utiliser un progiciel qui a été falsifié ou modifié par un adversaire.
Cela peut se produire une fois que le package a quitté le registre officiel des packages, soit via un accès direct au système de l'utilisateur, soit via des tactiques d'ingénierie sociale qui incitent l'utilisateur à télécharger ou à installer un package malveillant. Un exemple de ce vecteur était le Navigateur le typosquattage Attaque
Un attaquant, cherchant à compromettre les systèmes Linux et Mac, a infiltré le processus de développement d'une bibliothèque Node.js populaire appelée Browserify. L'attaquant a introduit du code malveillant dans le code source du projet, dans l'intention de le distribuer via le registre des packages NPM. Une fois le package Browserify corrompu téléchargé sur NPM, des développeurs sans méfiance le téléchargeaient et l’installaient, pensant qu’il s’agissait de la version légitime. Le code malveillant, intégré au package, s’exécuterait silencieusement, compromettant l’intégrité des systèmes infectés. Cela pourrait entraîner un vol de données, une instabilité du système ou même un accès à distance pour l'attaquant.
Registre des packages compromis
Un registre de packages compromis est un référentiel de logiciels qui a été infiltré par un adversaire qui a obtenu un accès non autorisé à l'interface ou à l'infrastructure d'administration du registre.
Cela permet à l'adversaire de modifier ou de remplacer des logiciels légitimes par des logiciels malveillants, qui peuvent ensuite être distribués à des utilisateurs installés sans méfiance. Un exemple de ce type de menace est la Attaque sur les miroirs de paquets : Un chercheur, dans le but de promouvoir des logiciels open source, a compromis plusieurs registres de packages populaires, notamment Maven Central, NPM et RubyGems. En accédant à ces registres, le chercheur a pu créer des miroirs et des répliques des référentiels d'origine, ce qui a fourni aux développeurs une alternative pratique pour télécharger des packages.
Cependant, ces miroirs avaient un objectif sinistre. Les miroirs compromis ont servi de canal au chercheur pour distribuer des packages malveillants. Ces packages ont remplacé des packages légitimes, non détectés par les registres principaux, et des développeurs sans méfiance les ont téléchargés et installés sans le savoir. Une fois installés, ces packages malveillants ont libéré leur charge utile, exécutant du code arbitraire, volant des données sensibles ou perturbant les opérations.
Télécharger le package modifié
Un adversaire télécharge un package modifié vers un référentiel ou un canal de distribution contenant du code ou des charges utiles malveillants. Cela peut être fait en modifiant le code source, l'empaquetage ou les métadonnées du package.
L'une des menaces les plus notoires de ce type était la Attaque CodeCov en 2021. Un attaquant cherchant à compromettre des projets logiciels utilisant CodeCov, une intégration continue et une livraison continue populaires (CI/CD) a utilisé des informations d'identification divulguées pour obtenir un accès non autorisé au compartiment Google Cloud Storage (GCS) d'un projet. Une fois l'attaquant accédant au compartiment GCS, il a téléchargé un artefact malveillant, une version modifiée du package CodeCov, qui a ensuite été distribuée aux utilisateurs via le service CodeCov. Des développeurs peu méfiants, s'appuyant sur la fonctionnalité de mises à jour automatiques, téléchargeaient et installaient le package malveillant, le croyant légitime. Une fois installé, le code malveillant s'exécutait silencieusement, compromettant l'intégrité des systèmes infectés. Cela pouvait entraîner un vol de données, une instabilité du système, voire un accès à distance pour l'attaquant.
Les attaques contre les registres de packages sont si courantes que certains modèles d'attaque ont reçu un nom :
In Typosquattage, le mauvais acteur télécharge dans le registre plusieurs packages malveillants avec de légères erreurs de frappe ou des noms similaires à des packages légitimes et populaires, dans l'espoir que les développeurs épelleront mal le nom du package prévu avec un nom malveillant. Souvent, le package malveillant se fait passer pour le package légitime et passe inaperçu, augmentant ainsi la probabilité d'être frappé par l'observation des étoiles.
Confusion des dépendances exploite la façon dont certains gestionnaires de packages résolvent les packages demandés à partir de plusieurs registres. Lorsqu'une organisation utilise des composants internes publiés dans un registre interne, un attaquant en connaissance de cause peut publier un composant malveillant du même nom dans un registre public. Si le nom utilisé pour le composant interne n'est pas défini, certains gestionnaires de packages récupéreront le composant malveillant au lieu du composant interne.
Avec Forfaits Troyen, le cybercriminel déguise le malware en code valide utile. Cela pourrait être utilisé par le véritable auteur, ou par un contributeur qui se propose de maintenir le package. Ceci est également connu sous le nom Détournement de colis. Les attaquants ont utilisé de nombreuses techniques pour pirater un package existant, comme Reprise de domaine où un domaine expiré abandonné a été pris par l'attaquant qui a recréé l'ancien e-mail du responsable et effectué une récupération du mot de passe pour prendre le contrôle du compte du responsable.
Remarques finales
Alors que les organisations adoptent de plus en plus de méthodologies de développement logiciel qui privilégient l’automatisation et la livraison continue, l’importance de sécuriser l’étape du progiciel n’a jamais été aussi primordiale. En mettant en œuvre des mesures de sécurité robustes tout au long de cette phase critique, les organisations peuvent considérablement atténuer le risque de succomber à des attaques malveillantes susceptibles de compromettre l'intégrité et la sécurité de leurs logiciels.
Les stratégies décrites dans cet article de blog, ainsi que les exemples fournis, rappellent brutalement que l'étape du package représente un point vulnérable au sein de la chaîne d'approvisionnement des logiciels. Les organisations doivent tenir compte de ces menaces et mettre en œuvre les mesures de sécurité nécessaires pour protéger leurs logiciels contre les attaques. Ce faisant, ils peuvent garantir l’intégrité, la sécurité et la fiabilité de leurs logiciels pour leurs utilisateurs et clients.
Rejoignez notre voyage vers un écosystème logiciel sécurisé
Ne manquez pas l'occasion d'avoir une longueur d'avance dans le domaine de software supply chain security. Abonnez-vous à notre blog dès aujourd'hui et soyez parmi les premiers à recevoir nos dernières informations, garantissant ainsi que votre organisation reste résiliente et sécurisée face à l'évolution des menaces. Ensemble, nous pouvons construire un écosystème logiciel plus robuste et plus sécurisé pour tous.
Rappelez-vous, software supply chain security est un voyage continu, pas une destination. En évaluant et en adaptant continuellement les pratiques de sécurité pour faire face aux menaces émergentes, les organisations peuvent protéger leur chaîne d'approvisionnement logicielle et fournir des logiciels fiables à leurs utilisateurs.
Regardez notre démo vidéo
