Skip to main content

Détectez et corrigez l’exploit Log4Shell rapidement avec Snyk

Écrit par:
Ariel Ornstein

Ariel Ornstein

wordpress-sync/blog-feature-log4j-vulnerability-red

13 décembre 2021

0 minutes de lecture

Note de la rédaction(28 décembre 2021 à 19 h 35 GMT) :l’équipe de Log4j a publié un nouvel avis de sécurité expliquant que la version 2.17.0 était vulnérable à une exécution de code à distance, faille décrite dans la CVE-2021-44832. Nous vous recommandons de passer sur la version la plus récente, à savoir la 2.17.1 à l’heure où nous écrivons ces lignes. Cliquez ici pour en savoir plus.

Note de la rédaction(18 décembre 2021 à 18 h 55 GMT) :la situation autour de Log4j évolue rapidement, et nous mettons à jour nos articles à mesure que de nouvelles informations sont révélées. Il est recommandé de passer sur la version 2.17.1 ou une version ultérieure. Cette version contient des correctifs de sécurité pour deux vulnérabilités permettant l’exécution de code à distance déjà corrigées dans les versions 2.15.0 (CVE-2021-44228) et 2.16.0 (CVE-2021-45046), ainsi qu’un correctif contre la dernière vulnérabilité DoS détectée (CVE-2021-45105). Cliquez ici pour en savoir plus.

Même si vous faites de votre mieux pour profiter de votre week-end tranquillement, il est probable que ce beau projet ait été interrompu au moins une fois par la nouvelle vulnérabilité zero-day touchant Log4Shell qui a été divulguée ce vendredi 10 décembre 2021.

Cette nouvelle vulnérabilité a été identifiée dans la bibliothèque Java open source log4j-core, un composant de l’un des frameworks de journalisation Java les plus populaires, Log4J. Elle est associée à la CVE-2021-44228, catégorisée Critique. Son score CVSS est de 10 et son niveau d’exploit est mature, car il est clair qu’elle était déjà activement exploitée.

Toutes les versions de la 2.0-beta9 up à la 2.14.1 sont touchées. Seule la dernière version disponible (2.16.0), publiée le jour de la divulgation de la vulnérabilité, est sécurisée. 

Snyk a rapidement ajouté la nouvelle vulnérabilité à sa base de données afin que ses clients, ses partenaires et la communauté dans son ensemble puissent l’utiliser pour scanner leurs applications et conteneurs JVM et appliquer un correctif en urgence avec Snyk Open Source et Snyk Container.

Comment la plateforme Snyk peut vous aider à détecter et corriger la vulnérabilité Log4Shell

Une des premières choses que vous allez vous demander, c’est dans quelle mesure vous êtes exposé à cette vulnérabilité.

Snyk peut vous donner une réponse en vous montrant si et où vous utilisez les versions vulnérables du paquet. Snyk vous aide également à les corriger dans l’ensemble de votre SDLC.

Nous allons vous montrer comment utiliser Snyk pour déterminer si vous êtes exposé à la vulnérabilité Log4Shell pendant l’écriture du code, via nos intégrations SCM ou avec notre service de surveillance continue. Nous allons également vous expliquer comment utiliser notre service de création de rapports et notre API pour assurer cette surveillance à grande échelle.

Commande de Snyk CLI pour le code non géré et non déclaré : snyk log4shell

Snyk CLI dispose d’une nouvelle commande pensée spécifiquement pour trouver des traces de la bibliothèque Log4j touchée par la vulnérabilité Log4Shell. snyk log4shell teste vos projets Java générés et détecte les traces de la bibliothèque vulnérable même si elle n’est pas déclarée dans les fichiers de manifeste. En savoir plus sur snyk log4shell et son utilisation dans vos projets.

Localisation de la vulnérabilité Log4shell au moment du codage

Pour détecter la vulnérabilité au plus tôt, les développeurs peuvent s’appuyer sur nos plugins pour les IDE et notre CLI, qui sont gratuits pour une utilisation de base. Les résultats de l’analyse incluent l’ensemble des vulnérabilités détectées par Snyk. Pour chacune, Snyk indique comment elle a été introduite dans l’application (dépendance directe ou transitive) et comment la corriger.

wordpress-sync/blog-log4shell-intellij
Capture d’écran du plugin de Snyk pour l’IDE IntelliJ, avec des instructions dans le code expliquant comment corriger la vulnérabilité.

Snyk CLI (dans sa dernière version, la v1.792.0) affiche un avertissement spécifique pour garantir que la vulnérabilité, si elle est détectée, soit particulièrement visible. Pour en savoir plus sur l’installation et la mise à jour de Snyk CLI, consultez notre documentation :

wordpress-sync/image-4-4
Détection de vulnérabilités avec Snyk CLI et obtention d’instructions de correction.

Recherche de log4j-core au format jar

Si vous n’utilisez pas de gestionnaire de paquets, comme Maven, sachez que Snyk peut aussi identifier la vulnérabilité dans les fichiers jar. Dans ce cas de figure, exécutez simplement la commande snyk test --scan-all-unmanaged. Tous les fichiers jar du dossier en cours seront alors analysés. Cette option fonctionne aussi avec la commande snyk monitor, qui permet une surveillance continue du projet.

wordpress-sync/image6-13

Recherche des vulnérabilités de Log4j dans vos projets avec les intégrations SCM de Snyk

En quelques clics, vous pouvez importer l’ensemble des projets pris en charge par Snyk, vérifier s’ils contiennent des vulnérabilités open source et obtenir des informations immédiates les concernant, notamment leur nature, la façon dont elles ont été introduites et le correctif à apporter :

wordpress-sync/blog-log4shell-import
wordpress-sync/blog-log4shell-vuln

Snyk fournit de nombreuses informations sur les vulnérabilités identifiées, un point essentiel pour comprendre comment corriger chacune d’elles et les hiérarchiser en fonction de leur gravité.

Le score de priorité de Snyk tient compte de divers signaux, comme l’exploitation de la vulnérabilité, la disponibilité d’un correctif ou même sa popularité sur Twitter. Ce score permet de trier rapidement les vulnérabilités pour prioriser les correctifs à apporter. Dans le cas de Log4Shell, sans surprise, le score de priorité est élevé, comme l’explique l’infobulle de Snyk.

L’arborescence des dépendances du projet vous aide à comprendre avec précision comment une vulnérabilité a pu s’introduire dans votre application, que ce soit directement ou sous forme de dépendance indirecte :

wordpress-sync/blog-log4shell-dependency-tree

Surveillance continue pour éviter de futures occurrences des vulnérabilités de Log4j

Si vous aviez déjà importé vos projets avant la divulgation de la nouvelle vulnérabilité, ils ont déjà été testés automatiquement lors de nos cycles quotidiens (sauf modification de la configuration par défaut). Si nos notifications sont activées, vous en avez probablement déjà reçu une pour vous indiquer si la vulnérabilité a été détectée dans l’un de vos projets.

PR/MR de correction automatique pour log4shell

Si votre dépôt était déjà surveillé par Snyk avant la divulgation de la nouvelle vulnérabilité, Snyk a déjà automatiquement déclenché une requête d’extraction/de fusion permettant de mettre à jour log4j-core vers une version sûre.

wordpress-sync/blog-log4shell-fix-pr

Si vous venez de faire l’importation ou que vous n’avez pas activé les PR de correction automatique, vous pouvez créer la PR manuellement sur la page du projet. 

wordpress-sync/blog-log4shell-manual-fix

Détection et correction de Log4Shell dans l’ensemble des services de votre entreprise

Si vous disposez d’un accès à notre API et à notre service de création de rapports, ces outils vous aideront à déterminer où la dépendance log4j-core est utilisée dans l’ensemble des projets open source que vous surveillez.

Utilisation des rapports de Snyk pour identifier les projets qui utilisent log4j-core

Vous pouvez vous appuyer sur la nomenclature de Snyk (accessible depuis l’onglet Dependencies des rapports des niveaux de votre groupe et de votre organisation) pour rechercher les projets dans lesquels log4j-core est utilisé. Ouvrez le filtre Dependencies et commencez à saisir le nom de la dépendance (log4j-core), puis sélectionnez-la pour afficher uniquement les résultats correspondant à ce paquet. Si vous ne voyez aucun résultat, cela signifie que vous n’utilisez cette dépendance dans aucun des projets surveillés par Snyk.

wordpress-sync/blog-log4shell-search
Capture d’écran de la recherche de `log4j-core` dans l’onglet Dependencies des rapports de Snyk.

Si des résultats s’affichent, vous saurez exactement où la trouver. Cliquez sur le lien Projects. Une liste de tous les projets dont log4j-core est une dépendance s’affiche. Vous pouvez ensuite cliquer sur le projet à proprement parler. Vous trouverez alors des instructions de correction, et si une mise à jour est possible, vous pourrez ouvrir une requête d’extraction/de fusion.

wordpress-sync/blog-log4shell-projects

Utilisation de l’API de Snyk pour identifier les projets qui utilisent log4j-core

Vous pouvez aussi utiliser notre API pour déterminer où vous utilisez la dépendance log4j-core. Notre point de terminaison des dépendances par organisation vous permet de générer la liste de toutes les dépendances utilisées et de leurs emplacements. Vous pouvez appliquer divers filtres, notamment de langage (Java est intéressant dans le cas présent) et de gravité, pour affiner les résultats. Utilisez le point de terminaison permettant de lister toutes les organisations d’un groupe si vous représentez un groupe de plusieurs entités et que vous souhaitez toutes les passer en revue.

wordpress-sync/blog-log4shell-api

Dans la réponse, vous verrez une liste de tous les projets contenant le paquet demandé. De là, vous pouvez passer par l’interface pour consulter les projets et corriger les vulnérabilités ou obtenir des instructions de correction avec d’autres API.

Laissez Snyk vous aider !

Vos premiers pas avec Snyk sont gratuits, rapides et simples. Rejoignez-nous sans plus attendre ! Nous vous aiderons à déterminer où vous utilisez la version vulnérable du paquet log4j-core et de bien d’autres, et vous permettrons de le corriger facilement pour que vous puissiez pleinement profiter de votre week-end !

wordpress-sync/blog-feature-log4j-vulnerability-red

Vous voulez l’essayer par vous-même ?

500 devs to 1 security professional is the reality of today. The security pro’s role must transform into an aware, knowledgeable, supportive partner capable of empowering developers to make security decisions.