Prévenir les packages malveillants et les attaques de la chaîne logistique logicielle avec Snyk

Les packages open source jouent un rôle essentiel dans le développement logiciel moderne et alimentent le rythme rapide des avancées que nous observons partout autour de nous. Pour un développeur qui souhaite intégrer de nouvelles fonctionnalités à son application, réinventer la roue n’a tout simplement aucun sens. Pourquoi ne pas installer un package que quelqu’un a déjà pris le temps de créer et qui fournit exactement les mêmes fonctionnalités ?

Mais en réalité, les packages open source constituent également un vecteur idéal pour diffuser du code malveillant dans les applications et compromettre la sécurité de la chaîne logistique. La raison est simple : ils sont une cible facile et intéressante pour les attaquants. Des packages sont publiés dans des registres sans contrôle de sécurité, puis téléchargés — des millions de fois par semaine dans le cas des projets populaires — et intégrés à des bases de code avec presque autant peu de vérifications.

Les registres comme npm, PyPI et RubyGems ont tous connu leur lot de packages malveillants ces dernières années. Le problème ne tient donc pas à une plus grande vulnérabilité d’un écosystème par rapport à un autre. Il s’agit d’une faille de sécurité inhérente à la façon dont les logiciels modernes sont conçus, une faille que les équipes de sécurité — et surtout les développeurs — doivent reconnaître et corriger.

Dans cet article, nous allons voir rapidement comment les packages malveillants sont utilisés dans les attaques de la chaîne logistique logicielle, puis comment Snyk peut aider à les prévenir.

Les packages malveillants dans les attaques de la chaîne logistique logicielle

Les attaques de la chaîne logistique logicielle visent à injecter du code malveillant dans un produit logiciel afin de compromettre les systèmes qui en dépendent en aval. Mais ces attaques prennent des formes diverses et varient selon leur cible et la méthode employée.

Dans l’attaque SolarWinds, par exemple, les processus de compilation logicielle et le code source étaient visés. Lors de la récente attaque contre Kaseya, la cible était un logiciel existant. Et les packages open source sont de plus en plus souvent pris pour cible. Dans ce type d’attaque de la chaîne logistique logicielle, du code malveillant est injecté dans un package publié sur un dépôt de packages (par exemple, npm, PyPI ou Ruby Gems). Les développeurs qui font aveuglément confiance à l’authenticité et à l’intégrité de ces packages les téléchargent et les installent sans le savoir, manuellement ou dans le cadre d’un processus de compilation automatisé.

Du point de vue de l’attaquant, cette méthode peut s’avérer très efficace. Les packages open source sont téléchargés des millions de fois par jour et constituent donc un vecteur de diffusion idéal. L’attaque de 2018 visant event-stream illustre bien la portée potentielle d’une attaque de la chaîne logistique logicielle utilisant des packages malveillants. Dans ce cas, l’attaquant a d’abord pris le contrôle du très populaire package event-stream, puis l’a modifié pour qu’il dépende d’un package malveillant, flatmap-stream. À l’époque, event-stream était utilisé par 1 600 packages et téléchargé 1,5 million de fois par semaine.

Comment du code malveillant est-il injecté dans les packages ?

Une méthode d’attaque consiste à créer un nouveau package contenant du code malveillant. Ces packages peuvent avoir un nom similaire à celui d’un package existant (typosquattage) ou reprendre le nom ou l’identifiant d’un package existant retiré par son mainteneur d’origine (exploitation d’une « utilisation après libération »). Une deuxième méthode consiste à infecter un package existant en injectant du code malveillant dans son code source, pendant la compilation ou dans le dépôt du package. Il suffit qu’une pull request apparemment anodine contenant le code malveillant soit fusionnée par le mainteneur du projet. Une troisième méthode consiste à téléverser des packages malveillants sur des dépôts alternatifs ou des miroirs de dépôts.

Lorsqu’un package malveillant se retrouve dans l’arbre des dépendances d’un projet, le code malveillant peut être exécuté de différentes façons. Dans de nombreux cas, des scripts d’installation sont exécutés lors de l’installation du package. Dans d’autres cas, le code malveillant doit être invoqué à l’exécution.

Atténuer les risques liés aux packages malveillants avec Snyk

Alors, comment vous protéger des packages malveillants ?

Chaque écosystème a ses propres stratégies pour empêcher les packages malveillants de s’infiltrer dans votre base de code. Pour JavaScript, par exemple, nous avons détaillé quelques bonnes pratiques dans cette antisèche. En tant que solution de sécurité des applications, Snyk propose également plusieurs fonctionnalités intégrées pour détecter les packages malveillants dès les premières étapes du développement, mais aussi plus tard dans le processus.

Intégrer la vérification préalable dès le début

Le principe de déplacer la sécurité des applications vers la gauche est depuis longtemps devenu la norme. Les équipes les plus efficaces automatisent les tests de sécurité le plus tôt possible, dès les environnements de développement locaux et dans leurs IDE. Mais la sécurité et la détection des packages malveillants peuvent aussi intervenir avant même que vous n’écriviez la première ligne de code, pendant la phase de planification et de recherche.

Faire preuve de diligence raisonnable est toujours une bonne pratique lorsqu’on recherche un logiciel à intégrer à son projet, mais il n’est pas toujours facile d’étudier un package donné. Dans un monde idéal, les registres de packages fourniraient toutes les informations nécessaires pour décider d’installer ou non un package, notamment s’il est sûr et sécurisé. Mais en réalité, il leur manque beaucoup d’informations sur l’état et la sécurité des packages.

Snyk Advisor est un outil de recherche gratuit en ligne qui peut vous aider à choisir les packages à utiliser dans vos projets. Snyk Advisor affiche un score de santé calculé à partir de plusieurs facteurs importants à prendre en compte lors du choix d’un package. Il analyse, par exemple, le niveau de maintenance d’un package, en fonction de la fréquence des nouvelles versions et de l’activité du dépôt. Snyk Advisor analyse également la popularité du package ainsi que la solidité de la communauté qui soutient le projet.

Bien entendu, Snyk Advisor tient également compte de l’état de sécurité d’un package. Les données de sécurité proviennent de la base de données des vulnérabilités Snyk Intel et indiquent notamment si le package est malveillant. Dans l’exemple ci-dessous, le package npm lyft-dataset-sdk est signalé par Snyk Advisor comme un package malveillant pouvant servir à une attaque par confusion de dépendances : il porte le même nom qu’un package Python créé par Lyft et peut donc facilement s’infiltrer dans une base de code où cette dépendance est déclarée.

La Snyk Vulnerability Database signale également les packages malveillants et peut être utilisée dans le cadre de vos recherches.

Dans l’exemple de typosquattage ci-dessous, un gem nommé auth-client est signalé comme malveillant. L’auteur ou les auteurs de ce gem ont délibérément choisi un nom très proche de ceux de packages Ruby existants et sécurisés (par exemple, auth_client et authclient), dans l’espoir qu’un développeur fasse une faute de frappe en indiquant le nom de la dépendance et télécharge le package piégé.

Détecter les packages malveillants tout au long du cycle de vie du développement logiciel

Même après des recherches approfondies, des packages malveillants peuvent passer inaperçus. Les tests de sécurité de Snyk sont effectués à différentes étapes du cycle de vie du développement logiciel pour détecter ces packages le plus rapidement possible.

Pour les projets Git surveillés par Snyk, toute nouvelle pull request créée par un développeur contributeur est vérifiée par rapport à la Snyk Vulnerability Database. Si un package malveillant est détecté, le test de sécurité échoue et indique de quel package il s’agit et pourquoi le test a échoué.

Et qu’en est-il des packages malveillants déjà présents dans votre backlog ? Lorsque vous devez examiner des centaines, voire des milliers de vulnérabilités, repérer un problème introduit par un package malveillant peut s’avérer décourageant, même pour l’équipe la plus expérimentée.

Snyk signale également les packages malveillants dans l’interface Snyk. Pour les projets surveillés par Snyk, cette information entre dans le calcul du score de priorité d’une vulnérabilité, avec d’autres facteurs tels que son score CVSS, la disponibilité d’un correctif, le fait qu’elle soit ou non en vogue sur les réseaux sociaux, les exploits connus, son ancienneté et son caractère exploitable. Vous pouvez ainsi repérer, hiérarchiser et corriger rapidement ces problèmes spécifiques :

Agir dès le début

Du point de vue de l’attaquant, la facilité avec laquelle les packages sont publiés dans les registres, sans aucune vérification de sécurité, combinée à la dépendance toujours plus forte à ces packages pour maintenir un rythme de développement soutenu, rend cette attaque particulièrement intéressante.

Il s’agit d’une faille de sécurité inhérente à la façon dont les applications sont conçues aujourd’hui. Les professionnels du développement et de la sécurité doivent pouvoir détecter les packages malveillants dès les premières étapes de recherche, lorsqu’ils choisissent les packages à utiliser, mais aussi plus tard au cours du développement.

Pour en savoir plus sur la sécurité de la chaîne logistique logicielle, cliquez ici.