Questions et Réponses sur la Vulnérabilité Log4j Log4Shell

Dans notre récent webinaire, Explications sur la vulnérabilité Log4j Log4Shell : Tout ce que vous devez savoir, notre expert en recherche de sécurité, Shachar Menashe, a partagé des informations sur ce problème de sécurité ainsi que sur la façon de le détecter et d’y remédier.

Nous sommes heureux de partager des informations supplémentaires dans les questions et réponses suivantes, basées sur les questions soulevées lors du webinaire.

Le problème de sécurité Log4j

Comment l’exploit log4j s'exécute-t-il ?

JFrog a publié un billet de blog complet qui explique la vulnérabilité dans le détail. Veuillez consulter la section : « Quelles sont les causes de la vulnérabilité Log4j Log4Shell ? »

J’ai entendu dire que l’appel d’API log4j était vulnérable lui aussi. Pourquoi vous concentrez-vous uniquement sur le noyau ?

L’API log4j n’est pas vulnérable, seul le noyau log4j-core l’est.

Quelle est la différence entre la vulnérabilité log4j log4shell et Shellshock en termes d’impact global ?

Log4shell et Shellshock sont des vulnérabilités d’exécution de code à distance qui ont un impact sur un vaste éventail de systèmes. Shellshock est une vulnérabilité dans bash (un shell Linux très commun), qui est une application, tandis que log4shell est une vulnérabilité dans la bibliothèque log4j. Pour plusieurs raisons, le problème de sécurité log4j présente plus de difficultés en termes d’atténuation de la menace.

Pour détecter Shellshock, il suffisait de vérifier dans le système local si une version vulnérable de bash était installée ; bash lui-même n’est généralement pas livré avec des dépendances tierces.

Le problème de sécurité log4shell est beaucoup plus difficile à détecter, car log4j est une bibliothèque. La détection nécessite donc de vérifier toutes les dépendances directes et indirectes (transitives/récursives). De plus, le vecteur d’attaque de log4shell est plus courant (journalisation des entrées non nettoyées) que celui de Shellshock (transmission des entrées non nettoyées à l’environnement bash).

Log4shell est également plus difficile à corriger : étant donné qu'il s’agit d’une bibliothèque, plusieurs API ont été modifiées dans des versions plus récentes. Un fournisseur de logiciel peut donc avoir à modifier le code propriétaire interagissant directement avec log4j, et non se contenter de mettre à niveau log4j lui-même.

Enfin, les nouvelles versions de log4j nécessitent une version plus récente de Java (Java 8 par rapport à l’ancien Java 6/7). Le fournisseur du logiciel peut donc devoir lui aussi mettre à niveau le composant Java, ce qui peut entraîner des incompatibilités avec d’autres logiciels Java sur le système.

Qu’en est-il de log4j version 1, qui n’est pas vulnérable ? Sera-t-il affecté par la vague d’attention sur log4j version 2 ?

L’exploit actuel ne met pas la version 1 en danger. Cependant, les attaquants pourraient maintenant consacrer plus d’efforts aux recherches sur le composant log4j, afin d’essayer de trouver d'autres vulnérabilités.

Solutions pour trouver et corriger Log4j

Avez-vous des outils spécifiques qui peuvent m’aider à identifier si j’ai des paquets log4j dans mes dépôts ?

Oui ! Pour commencer, nos clients qui utilisent la plateforme DevOps JFrog comme élément central de leur processus de cycle de vie du développement logiciel (SDLC) critique disposent déjà de tout le nécessaire pour remédier rapidement à la vulnérabilité Log4j.

Avec vos packages, fichiers binaires, images et métadonnées accumulés sous la gestion du dépôt de binaires d’Artifactory, vous pouvez rechercher des artefacts et des builds pour découvrir chaque utilisation du package log4j, y compris en tant que dépendances transitives, dans l’ensemble de votre chaîne d’approvisionnement logicielle. Vous pouvez également créer des stratégies Xray et des watches pour bloquer tous les builds ultérieurs qui utilisent des versions vulnérables du package log4j à partir de la production.

Pour la communauté des développeurs dans son ensemble, JFrog a également publié un ensemble utile d’outils open source pour identifier l’utilisation de log4j dans le code source et les fichiers binaires dans les annuaires locaux.

Supposons que nous utilisions un composant tiers qui a une dépendance de temps de compilation de log4j. Existe-t-il un moyen de se débarrasser de log4j tout en utilisant ce composant ?

Cela ne pose problème que si le package utilise une version vulnérable de log4j. Si tel est le cas, vous devrez obtenir une version corrigée du composant tiers. Si vous avez le code source, vous pouvez le compiler vous-même avec la version réparée de log4j.

Toute dépendance qui fait référence à log4j est-elle vulnérable à cette attaque, même lorsqu’elle utilise une bibliothèque d’API telle que Spring Framework qui fait référence à la bibliothèque log4j en tant que dépendance ?

Tout dépend de chaque cas spécifique et des parties de la bibliothèque log4j utilisées. Le noyau log4j-core est vulnérable, mais l'API log4j-ne l'est PAS.

Pour obtenir les résultats les plus complets, nous vous recommandons d’utiliser un outil d’analyse de la composition logicielle (SCA) tel que JFrog Xray pour identifier les vulnérabilités de toutes vos dépendances logicielles, y compris celles liées à log4j, mais aussi bien d'autres.

Si vous n'en avez pas, vous pouvez utiliser les outils OSS JFrog créés pour la communauté afin d’identifier spécifiquement l’utilisation de log4j dans le code source et les fichiers binaires (voir ci-dessus).

Une fois que Xray détecte qu’un artefact est vulnérable à log4shell, existe-t-il un moyen de déterminer quels sont les consommateurs de cet artefact, c’est-à-dire d’utiliser Artifactory pour suivre quels services/utilisateurs ont accédé à/téléchargé l’artefact vulnérable, afin que ces services spécifiques puissent être analysés ?

Absolument ! C’est pour cela que la Plateforme JFrog a été conçue. Vous pouvez utiliser Xray et Artifactory pour identifier les consommateurs d’artefacts vulnérables et contrôler leur utilisation à l’aide des méthodes suivantes :

Recherche dans vos dépôts de l’utilisation de packages log4j
Recherche de CVE-2021-44228
Exécution d’une requête build-info dans Artifactory pour répertorier tous les builds qui utilisent la bibliothèque log4j-core comme dépendance
Définition d’une stratégie Xray pour alerter en cas de violation ou bloquer le téléchargement du package vulnérable

Pour plus d’informations, consultez notre article de blog, Votre Carnet de Remédiation Log4shell Avec la Plateforme JFrog, qui traite de plusieurs méthodes pour découvrir, bloquer et corriger la vulnérabilité log4shell.

Puis-je voir une démonstration de Xray pour l’identification de dépendance statique et transitive ?

Nous en serons ravis ! Veuillez nous contacter pour obtenir une démonstration de Xray et nous vous appellerons pour vous montrer comment vous pouvez voir à travers toutes les couches des dépendances d’un artefact.