Skip to main content

Vulnérabilité de hachage faible découverte dans crypto-js et crypto-es (CVE-2023-46233 et CVE-2023-46133)

Écrit par
feature crypto vuln

25 octobre 2023

0 minutes de lecture

Le 18 octobre, le chercheur en sécurité Zemnmez a entamé la procédure de divulgation responsable d’une vulnérabilité « Utilisation d’un hachage faible » découverte dans crypto-js, une bibliothèque JavaScript open source de normes cryptographiques dont la maintenance a été interrompue. La vulnérabilité affecte également le package crypto-es (pour ES6 et TypeScript), et le chercheur a ouvert un ticket similaire demandant aux responsables du projet d’activer les signalements privés. Les dépôts crypto-js et crypto-es ont tous deux activé les fonctionnalités « avis de sécurité » et « signalement privé des vulnérabilités » demandées par Zemnmez. Nous avons depuis appris que la vulnérabilité affecte toutes les versions antérieures des bibliothèques. Rien n’indique que ces vulnérabilités affectent les bibliothèques de chiffrement du cœur de Node.js. 

Liens rapides

Explication des vulnérabilités de crypto-js et crypto-es

Snyk a créé deux avis concernant la vulnérabilité :

De nouvelles versions des bibliothèques crypto-es (2.1.0) et crypto-js (4.2.0) ont été publiées pour corriger la vulnérabilité signalée par Zemnmez. Le commit de crypto-es indique qu’il s’agit d’une modification des « paramètres par défaut pour renforcer la sécurité ». La bibliothèque crypto-js a également été corrigée. Toutefois, même si elle n’est pas marquée comme deprecated, elle n’est généralement pas mise à jour et vous devriez envisager d’autres options (voir ci-dessous).

Les avis associés décrivent le problème de façon similaire :

« Les versions concernées de ce package sont vulnérables à l’“utilisation d’un hachage faible” en raison de paramètres de sécurité insuffisants dans la classe PBKDF2 (Algo), qui utilise SHA1, un algorithme non sécurisé, et un nombre d’itérations faible, égal à 1. Ces paramètres non sécurisés permettent aux attaquants de lancer des attaques par force brute lorsque PBKDF2 (Algo) est utilisé avec les paramètres par défaut (l’avis concernant crypto-js rappelle également que la bibliothèque n’est plus maintenue). »

Les correctifs ont modifié la valeur par défaut du paramètre iterations, qui est passée de 1 à 250000. Le principal risque lié à cette vulnérabilité est l’exposition aux attaques par force brute des données hachées à l’aide de cette fonctionnalité (comme les mots de passe stockés). Dans le cas de pbkdf2, les cas d’usage courants sont le stockage des mots de passe et des signatures (par exemple, pour vérifier des fichiers). Lorsque pbkdf2 est utilisé pour valider des signatures, il peut également être possible (mais potentiellement coûteux) de mener une attaque à texte en clair choisi afin d’obtenir une signature cryptographique identique. L’attaquant peut ainsi concevoir une entrée qui passe la validation cryptographique.

Comment se préparer à la correction

Évaluez votre exposition

Vous pouvez utiliser Snyk pour trouver rapidement les projets open source et les images de conteneur concernés, même avant la publication des versions corrigées de crypto-js et crypto-es. 

Dans la barre latérale de l’interface de l’application Snyk, accédez à Dependencies. Dans la vue Dependencies, développez le filtre Dependencies et saisissez « crypto-js ». Vous pouvez sélectionner des versions individuelles ou cocher le raccourci Select all, puis cliquer en dehors du filtre pour afficher les résultats. Répétez ensuite l’opération pour « crypto-es ». Vous verrez alors tous les projets qui utilisent les versions de crypto-es sélectionnées. Parcourez les projets et leurs dépendances pour évaluer votre exposition et déterminer les correctifs à appliquer en priorité. 

Page Dépendances Snyk répertoriant les projets qui utilisent crypto-js@3.3.0, avec leurs sources et le nombre de problèmes.
J’ai 33 projets qui utilisent crypto-js@3.3.0, dont l’un est une image Docker

Évaluez l’état de santé de vos packages avec Snyk Advisor 

Snyk Advisor vous aide à trouver le package le mieux adapté à votre prochain projet. Une recherche rapide de crypto-js montre que, malgré une communauté active, la maintenance de la bibliothèque de chiffrement est inactive, et suggère des packages similaires (notez que cette capture d’écran date d’avant la divulgation et l’attribution des vulnérabilités. Comme le développeur a publié une nouvelle version, le niveau de maintenance est désormais considéré comme sustainable). 

Page Snyk Advisor du package JavaScript crypto-js, affichant un score de santé de 79/100 et un statut de maintenance inactive.

Suivez les améliorations du projet principal ou de l’écosystème

Les anciens responsables de la bibliothèque crypto-js, dont la maintenance a été interrompue, attribuent en partie son abandon au fait que « toute évolution de CryptoJS reviendrait à en faire un simple wrapper de Crypto natif ». Suivre le score de santé des bibliothèques que vous utilisez peut vous aider à prévenir les vulnérabilités, mais il est également important de vous tenir au courant des améliorations de l’écosystème lui-même. Pour certaines équipes, la meilleure solution dans une situation comme celle-ci consiste à vérifier si les fonctionnalités natives de l’écosystème peuvent remplacer les bibliothèques tierces.

Détecter les vulnérabilités avec Snyk

Il existe plusieurs façons de détecter les vulnérabilités de crypto-js et crypto-es avec Snyk. Avec la Snyk CLI, vous pouvez tester vos projets en local, les importer dans Snyk au moyen de nos intégrations SCM, ou lancer rapidement une recherche de crypto-js et crypto-es dans tous les projets déjà importés dans Snyk à l’aide des rapports Snyk. 

Tester vos projets avec la Snyk CLI

Snyk Container et Snyk Open Source peuvent vous signaler les packages du système d’exploitation ou les bibliothèques open source qui dépendent de versions vulnérables de crypto-js ou crypto-es, grâce aux commandes snyk container test et snyk test, respectivement. Snyk peut surveiller vos images de conteneur et vos projets open source et vous avertir de l’apparition de nouvelles vulnérabilités, comme celles de crypto-js ou crypto-es. Pour cela, enregistrez vos images de conteneur avec snyk container monitor ou vos dépendances aux bibliothèques open source avec snyk monitor.

L’exemple suivant montre la Snyk CLI en train d’analyser un projet Node.js. Dans ce cas, le projet utilise la version 4.0.0 de crypto-js et doit être mis à jour vers la version 4.2.0.

$ > snyk test

Testing /Users/jamie/Projects/GitRepo/gatsby-demo...

Tested 1367 dependencies for known issues, found 29 issues, 1008 vulnerable paths.

Issues to fix by upgrading:

  Upgrade crypto-js@4.0.0 to crypto-js@4.2.0 to fix
  ✗ Use of Weak Hash (new) [High Severity][https://security.snyk.io/vuln/SNYK-JS-CRYPTOJS-6028119] in crypto-js@4.0.0
    introduced by crypto-js@4.0.0

Tester vos projets avec l’intégration SCM

L’importation de votre projet dans Snyk au moyen de nos intégrations SCM prises en charge (GitHub, Bitbucket, GitLab, Azure Repos) déclenche automatiquement un test. Vous pouvez ensuite utiliser l’interface Snyk pour détecter, prioriser et corriger les vulnérabilités de crypto-js et crypto-es dans vos projets. 

Détecter les vulnérabilités dans vos projets avec Snyk Reporting ou Snyk Insights

Les clients Snyk ayant accès aux rapports Snyk (offre Enterprise) et à Snyk Insights peuvent rapidement repérer crypto-js ou crypto-es dans les projets qu’ils ont déjà importés et qu’ils surveillent avec Snyk. Les deux variantes de la vulnérabilité crypto- partagent un CWE. Dans la page Insights, filtrez selon ce CWE commun, CWE-328, comme indiqué ci-dessous.

Tableau de bord Snyk Insights présentant les problèmes ouverts filtrés par vulnérabilités CWE-328 liées à l’utilisation de fonctions de hachage faibles, avec les facteurs de risque et les projets concernés.

Si vous détectez le problème, vous pourrez voir précisément où il est utilisé. Cliquez ensuite sur le projet pour obtenir davantage d’informations sur le problème et savoir comment le corriger.

Prioriser les correctifs avec le score de risque de Snyk 

Vous détecterez probablement plusieurs problèmes liés à crypto-js ou crypto-es dans vos projets, et il peut être difficile de savoir par où commencer. Snyk propose plusieurs mécanismes pour vous aider à prioriser les correctifs, mais nous vous recommandons d’utiliser notre score de risque.

Le score de risque de Snyk calcule de nombreux facteurs de risque pour vous aider à repérer rapidement les problèmes à traiter en priorité. Il prend en compte plusieurs indicateurs, comme EPSS, la maturité des exploits, le score CVSS, les tendances sur les réseaux sociaux, et bien plus encore. Vous pouvez ainsi parcourir rapidement la liste des vulnérabilités et prioriser les correctifs en conséquence. Pour crypto-js et crypto-es, le score varie selon le contexte. 

Tableau de bord des projets Snyk présentant une vulnérabilité liée à l’utilisation d’un hachage faible dans crypto-js, avec un score de risque de 139 et des détails sur l’impact et la probabilité.

Le score de chaque problème lié à crypto-js et crypto-es apparaît sur la page Projects et est également disponible dans les rapports Snyk.

Comment corriger les vulnérabilités crypto- dans les projets open source ou les images de base de conteneur

Mettez à jour votre image de base vers une balise plus récente qui inclut le correctif de la vulnérabilité. Pour les écosystèmes pris en charge, vous pouvez déclencher directement depuis Snyk des demandes de tirage contenant le correctif nécessaire.

Par exemple, Snyk recommande d’autres images de base de conteneur dans l’interface ou la CLI. Lorsque vous importez votre dépôt de code source via un SCM comme GitHub, vous pouvez automatiser la correction de l’image de conteneur en créant une demande de tirage qui met à jour l’entrée FROM du Dockerfile. 

Tableau de bord des projets Snyk présentant les vulnérabilités d’une image de conteneur et des recommandations pour mettre à niveau l’image de base, avec un bouton « Ouvrir une PR de correction »

Vous pourriez également éviter l’impact de la vulnérabilité en spécifiant le paramètre iterations lors de l’utilisation de PBKDF2. Il est tout aussi important de vérifier que vous ne spécifiez pas non plus une valeur trop faible pour iterations :

{ 
    keySize: 256/32, 
    iterations: 1 
}

… car cela reproduirait la vulnérabilité précédente.

Prochaines étapes pour répondre aux vulnérabilités de crypto-js et crypto-es

  1. Testez vos projets avec Snyk en suivant les méthodes présentées dans cet article. Pour commencer, créez gratuitement un compte Snyk, puis importez et analysez tous les projets potentiellement concernés à l’aide de l’assistant d’importation.

  2. Identifiez les correctifs prioritaires pour les vulnérabilités de crypto-js et crypto-es grâce au score de priorité ou à Insights (pour les clients de l’offre Snyk Enterprise).

  3. Appliquez les correctifs en mettant à jour les dépendances de vos projets open source ou vos images de conteneur pour utiliser crypto-js en version 4.2.0 ou ultérieure, et crypto-es en version 2.1.0 ou ultérieure.

  4. Continuez à suivre l’évolution de la situation et consultez le Snyk Blog pour connaître les dernières nouvelles. Les équipes de sécurité de Snyk mettront régulièrement à jour nos ressources.

  5. Si vous utilisez crypto-js, qui n’est plus maintenu, envisagez de passer à crypto-es ou d’utiliser les fonctions intégrées.

Lancez-vous dans les compétitions Capture The Flag

Apprenez à résoudre des défis de capture du drapeau en regardant à la demande notre atelier virtuel d’initiation.

Lire la suite

Blog

Les modèles de pointe ont trouvé les vulnérabilités. Seul l’attaquant a trouvé les chaînes d’exploitation.

L’analyse statique a détecté les failles, mais seuls des tests d’attaque en conditions réelles ont prouvé comment elles pouvaient être enchaînées pour provoquer des compromissions. Comparaison d’Evo COS, de Claude Security et de Claude Code Security.

feature insights context
Blog

Les attaques autonomes sont déjà là. La défense doit suivre leur rythme.

Les attaquants autonomes réduisent la fenêtre de défense. Découvrez comment la découverte, la correction, la validation et la prévention continues peuvent aider les équipes de sécurité à suivre le rythme.

Blog

Votre backlog de vulnérabilités n’est plus une dette technique, c’est une surface d’attaque

Un backlog de vulnérabilités qui s’allonge est plus qu’une dette technique : c’est une surface d’attaque. Découvrez pourquoi les anciennes hypothèses de risque, les attaquants automatisés et les vulnérabilités en chaîne exigent une nouvelle approche.