La vulnérabilité Log4j et son impact sur la sécurité de la chaîne d’approvisionnement logicielle

Note de la rédaction (28 décembre 2021 à 19 h 35 GMT) : L’équipe Log4j a publié une nouvelle mise à jour de sécurité révélant que la version 2.17.0 était vulnérable à l’exécution de code à distance, sous l’identifiant CVE-2021-44832. Nous vous recommandons de passer à la dernière version, qui est actuellement la 2.17.1. Pour en savoir plus, cliquez ici.

Note de la rédaction (18 décembre 2021 à 18 h 55 GMT) : La situation concernant Log4j évolue rapidement et nous mettons nos articles à jour au fur et à mesure que de nouvelles informations sont disponibles. Nous vous recommandons de passer à la version 2.17.1 ou ultérieure. Cette version corrige deux vulnérabilités d’exécution de code à distance, corrigées dans les versions 2.15.0 (CVE-2021-44228) et 2.16.0 (CVE-2021-45046), ainsi que la dernière vulnérabilité de déni de service, corrigée dans la version 2.17.1 (CVE-2021-45105). Pour en savoir plus, cliquez ici.

Vous connaissez désormais la vulnérabilité baptisée Log4Shell et identifiée sous le nom de CVE-2021-44228 — et vous êtes probablement déjà en train d’y remédier. Des chercheurs en sécurité l’ont divulguée le vendredi 10 décembre 2021 pour le framework de journalisation Log4j d’Apache.

Dans cet article, nous allons examiner quelques faits importants sur Log4j et les mesures que vous pouvez prendre pour vous protéger et protéger votre entreprise :

• Log4j présente une vulnérabilité critique qui exige une intervention urgente

• Log4j est très largement utilisé et aura un impact considérable

• Log4j a un impact majeur sur la sécurité de la chaîne d’approvisionnement et sera difficile à corriger

• Il est essentiel de prioriser la correction de la vulnérabilité Log4j dans un backlog de sécurité déjà bien rempli

• Réagir rapidement aux problèmes critiques comme Log4j est essentiel pour l’entreprise

Log4j présente une vulnérabilité critique qui exige une intervention urgente

Nous ne saurions trop insister sur la gravité de cette vulnérabilité Log4j. Il s’agit d’une vulnérabilité de sécurité critique, avec un score CVSS de 10 (le score maximal), qui permet aux attaquants d’exécuter du code à distance dans tout environnement vulnérable. C’est un problème majeur qui nécessite une correction urgente.

Veuillez lire les sections ci-dessous pour savoir quelles mesures immédiates prendre en fonction des versions de Log4j que vous utilisez actuellement dans vos applications.

J’utilise Log4j v1 : que dois-je faire ?

Le risque est nettement moindre que celui de la vulnérabilité touchant la version 2.x. Toutefois, dans des circonstances très précises, Log4j v1 autorise les recherches, comme celles observées dans Log4j 2, qui ne protègent pas contre LDAP ni contre d’autres points de terminaison résolus via JNDI. Ces vecteurs d’attaque (et potentiellement d’autres) peuvent entraîner des attaques par exécution de code à distance (RCE). Si vous utilisez une version de Log4j v1 dans laquelle JMSAppender est activé, vous pourriez être vulnérable. Il convient de noter que JMSAppender est désactivé par défaut et qu’il est donc peu probable qu’il soit activé dans la plupart des instances de Log4j v1 utilisées dans les applications.

Il s’agit d’une mise à jour critique et récente, déployée tout récemment (le 13 décembre 2021 vers 17 h UTC) et suivie par Snyk sous l’identifiant de vulnérabilité SNYK-JAVA-LOG4J-2316893.

Nous vous recommandons donc, si possible, de passer à la dernière version v2 de Log4j, qui intègre le correctif de la vulnérabilité récemment découverte. Consultez le document officiel d’Apache sur la migration depuis Log4j v1. Si vous ne pouvez pas effectuer la mise à niveau, désactivez JMSAppender ou empêchez toute entrée utilisateur d’accéder à sa configuration.

J’utilise Log4j v2 : que dois-je faire ?

Si vous utilisez Log4j version 2.x, passez à la dernière version de Log4j v2 (actuellement la 2.16.0), qui corrige la vulnérabilité.

J’utilise Log4j v1 ou v2, mais je ne peux pas effectuer rapidement la mise à niveau. Existe-t-il une solution de contournement immédiate ?

Si vous ne pouvez pas effectuer la mise à niveau dans l’immédiat, consultez notre article sur Log4j, qui explique comment remédier à la vulnérabilité en définissant des propriétés système et des paramètres Java.

Log4j est très largement utilisé et aura un impact considérable

La journalisation est omniprésente

Lorsqu’ils développent des applications, les développeurs consignent presque toujours des données afin de disposer d’informations à des fins de débogage, d’analyse et d’audit. En plus de son utilité au quotidien pour le développement, la journalisation est également exigée par de nombreuses équipes de sécurité afin de disposer de pistes d’audit permettant de suivre et de corréler les activités potentiellement suspectes.

La journalisation est une pratique essentielle au développement

Le caractère omniprésent de la journalisation, combiné au fait que la vulnérabilité Log4j peut être déclenchée par la journalisation de données saisies par les utilisateurs, accroît considérablement la gravité de l’attaque et élargit les vecteurs d’attaque potentiels. Par exemple, des utilisateurs ont publiquement signalé sur les réseaux sociaux que des personnes avaient commencé à utiliser des charges utiles d’exploitation Log4j comme adresses e-mail et noms d’utilisateur dans des formulaires Web.

Nous ne connaîtrons pas avant un certain temps l’ampleur réelle de l’impact de la vulnérabilité Log4j. Toutefois, depuis sa divulgation, des rapports font déjà état de centaines de tentatives d’exploitation de cette vulnérabilité dans la nature, menées par des attaques opportunistes en apparence, mais aussi par des botnets plus sophistiqués.

La bibliothèque open source Log4j est très largement utilisée

Comme on peut s’y attendre au vu de la popularité de cette vulnérabilité, Log4j est largement utilisé par des fournisseurs, des projets open source, des frameworks et des projets de fondation de premier plan.

Outre les millions d’applications Java qui utilisent Log4j, de nombreux projets de l’Apache Software Foundation utilisent également Log4j, notamment Apache Solr, Apache Struts2, Apache Kafka, Apache Druid, Apache Flink, Apache Swift et bien d’autres.

Cette bibliothèque est également largement utilisée dans de nombreux autres projets populaires, tels que Redis, Elasticsearch, Spring Framework, Netty et bien d’autres.

Même Ghidra, l’outil de rétro-ingénierie de la National Security Agency (NSA), publié en open source, s’est révélé vulnérable à ce problème de sécurité lié à Log4j.

Les fournisseurs sont eux aussi largement touchés par cette vulnérabilité, notamment avec AWS CloudHSM, Amazon OpenSearch et potentiellement d’autres services d’AWS. Cela concerne également les produits Red Hat, tels que Red Hat JBoss Fuse 7, Red Hat CodeReady Studio 12, Red Hat OpenShift Logging et bien d’autres. Comme vous pouvez l’imaginer, de nombreux autres fournisseurs, dont VMware et Cisco, sont également concernés.

Nous avons constaté un impact important parmi les utilisateurs de Snyk. Environ un tiers des clients de Snyk sont touchés par la vulnérabilité Log4j, qui représente des dizaines de milliers de vulnérabilités détectées dans les projets importés ou surveillés par Snyk.

La crise provoquée par la bibliothèque Java Log4j, un composant open source tiers, souligne encore davantage la nécessité de suivre les nomenclatures logicielles (SBOM) à l’échelle de l’organisation et d’intégrer un outil d’analyse de la composition logicielle permettant à vos équipes de développement et de sécurité de réagir rapidement.

Log4j a un impact majeur sur la sécurité de la chaîne d’approvisionnement et sera difficile à corriger

En exploitant les données des projets importés, surveillés et analysés par Snyk, nous avons pu mieux comprendre les habitudes d’utilisation de la bibliothèque Log4j dans les projets.

À ce jour, nous avons constaté que 60 % des projets Java surveillés par Snyk et utilisant la bibliothèque Log4j y ont recours comme dépendance indirecte. Une dépendance indirecte est une dépendance utilisée par un projet de manière indirecte (autrement dit, l’une des dépendances de votre projet utilise Log4j, ce qui vous rend vulnérable même si vous n’utilisez pas Log4j vous-même). Par conséquent, une simple recherche visant à déterminer si vous utilisez une version vulnérable de Log4j ne détectera pas nécessairement toutes les occurrences de la bibliothèque dans vos projets. Vous aurez besoin d’un outil d’analyse de la composition logicielle (SCA), comme Snyk, capable de parcourir un graphe de dépendances profondément imbriqué et de comparer les versions à une base de données de vulnérabilités pour repérer les risques liés à la sécurité de la chaîne d’approvisionnement.

En effet, dans le rapport 2020 de Snyk sur l’état de la sécurité de l’open source, nous avons découvert — et confirmé — que la plupart des vulnérabilités proviennent de dépendances indirectes dans les écosystèmes Java, Ruby et JavaScript :

C’est l’une des nombreuses raisons pour lesquelles, en tant que développeur, vous devez utiliser des outils de sécurité comme Snyk pour détecter les vulnérabilités dans vos projets (comme log4j). Savoir si vous utilisez ou non une dépendance vulnérable ne suffit pas : vous devez également vérifier récursivement si vos dépendances sont elles aussi vulnérables.

En résumé, corriger la nouvelle vulnérabilité Log4j sera compliqué, car de nombreuses bibliothèques open source devront être mises à niveau afin de résoudre le problème et de protéger les projets qui en dépendent. Cela prendra du temps.

La vulnérabilité Log4j représente une menace imminente à l’échelle mondiale. À l’image de la pandémie de COVID-19, qui nous a contraints à collaborer avec des organismes de santé et des entreprises de recherche médicale du monde entier, nous constatons qu’une coopération similaire est actuellement en cours et qu’elle est indispensable pour faire face aux risques liés à la vulnérabilité Log4j et apporter une solution globale à la communauté.

Il est essentiel de prioriser la correction de la vulnérabilité Log4j dans un backlog de sécurité déjà bien rempli

Pour beaucoup, la vulnérabilité Log4j est un nouveau problème de sécurité urgent à traiter dans un backlog de dette de sécurité déjà bien rempli.

Face à la multiplication des vulnérabilités dans les écosystèmes de langages, aux erreurs de configuration, aux composants open source des systèmes d’exploitation et aux autres problèmes de sécurité des applications, par où les équipes de sécurité doivent-elles commencer ? Quelle est la vulnérabilité de sécurité la plus importante et la plus urgente à traiter lorsqu’elles manquent déjà de personnel ?

La priorisation est essentielle pour permettre aux équipes de sécurité de travailler efficacement, mais elle constitue également un levier important pour réduire le risque global pour l’entreprise. Pour être efficaces, les équipes de sécurité doivent pouvoir comprendre les risques liés aux vulnérabilités, non seulement pour un projet, mais aussi à l’échelle de l’ensemble de l’organisation.

Afin d’aider les développeurs et les équipes de sécurité à réagir rapidement et à évaluer les risques de sécurité à l’échelle de l’organisation, nous avons intégré dans Snyk le concept de scores de priorité.

Les pratiques de sécurité traditionnelles reposent sur le score CVSS d’une vulnérabilité, qui manque souvent de contexte. Le score de priorité de Snyk tient compte d’informations contextuelles sur la vulnérabilité, notamment du degré de maturité de l’exploitation, des tendances sur les réseaux sociaux, du niveau de gravité CVE attribué, de la disponibilité d’un correctif et de la date de divulgation.

Notre score de priorité va de 0, le score le plus bas, à 1 000, le score le plus élevé, et met en évidence les vulnérabilités de sécurité les plus urgentes à traiter pour une entreprise. La vulnérabilité Log4j illustre parfaitement comment notre score de priorité aide les équipes à bien hiérarchiser les corrections. L’image ci-dessous, extraite du tableau de bord Snyk, montre comment, dans certains cas, la CVE Log4j concernée a obtenu le score maximal de 1 000, parmi les milliers de vulnérabilités auxquelles une organisation doit faire face dans des centaines de projets couvrant différents écosystèmes et langages de programmation :

Guy Podjarny (fondateur et président de Snyk) a approfondi ce concept et expliqué la différence entre important et urgent, ainsi que son application à la priorisation de la sécurité. Nous avons d’ailleurs étendu ce concept au développement d’applications cloud native afin de donner aux équipes une meilleure visibilité grâce à la priorisation contextuelle de leurs déploiements Kubernetes.

Réagir rapidement aux problèmes critiques comme Log4j est essentiel pour l’entreprise

La vulnérabilité Log4j a contraint les équipes de réponse aux incidents à identifier rapidement les causes profondes et à analyser (puis corriger) leur parc d’applications Java déployées.

Il ne fait aucun doute que les équipes de réponse aux incidents devaient réagir rapidement aux vulnérabilités critiques comme Log4j. Mais cette responsabilité incombe aussi aux développeurs et aux équipes AppSec, chargés de la sécurité de leurs applications.

L’ADN de Snyk repose sur une sécurité pensée pour les développeurs et facile à utiliser. Permettre aux développeurs et aux équipes de sécurité de détecter et de corriger les vulnérabilités aussi rapidement et simplement que possible n’est pas seulement un objectif prioritaire pour nous : c’est notre raison d’être.

Au cœur du chaos provoqué par la vulnérabilité Log4j, nous avons été ravis et touchés de voir d’autres personnes réussir à corriger la vulnérabilité avec Snyk :

Il ne s’agit pas seulement de corriger les vulnérabilités de manière proactive et automatique pour les développeurs, mais aussi de prendre en compte les problèmes de sécurité dans l’ensemble de vos dépôts de code source, y compris ces vieux projets hérités qui prennent la poussière :

Les prochaines étapes pour corriger Log4Shell

La lumière est au bout du tunnel : il vous suffit de faire quelques pas dans sa direction !

Snyk peut vous aider de plusieurs façons : évaluer le niveau d’exposition de vos différentes applications, effectuer des tests dès les premières étapes et tout au long de votre SDLC, ou encore déclencher des demandes de pull pour appliquer automatiquement des correctifs et corriger rapidement les vulnérabilités détectées.

Nous vous recommandons vivement de découvrir comment détecter et corriger rapidement Log4Shell avec Snyk : vous y trouverez des conseils pratiques pour corriger rapidement les vulnérabilités liées à Log4j dans vos projets. Si ce n’est pas déjà fait, inscrivez-vous gratuitement à Snyk !

Alors que la situation continue d’évoluer, mieux vaut rester au fait de l’actualité. Nous continuerons à publier des mises à jour dans notre newsletter et sur ce blog. Restez à l’écoute !

Pour finir sur une note plus légère, cette vulnérabilité critique aura au moins suscité quelques rires familiers. La BD XKCD « Little Bobby Tables » nous vient à l’esprit (avec quelques modifications, comme cela a été partagé à l’origine sur les réseaux sociaux) :