La vulnérabilité Log4j, ou « Log4Shell », est considérée comme l’une des failles logicielles les plus catastrophiques de tous les temps. Bien qu’Apache ait corrigé la faille en décembre 2021, elle reste source de préoccupation pour les équipes de sécurité. En effet, elle fait partie des failles de sécurité les plus exploitées.
Log4Shell persiste parce que le progiciel Apache Log4j 2 qu’il affecte est l’une des bibliothèques de journalisation les plus utilisées au monde. Selon le Département de la sécurité intérieure des États-Unis, trouver et corriger chaque instance de Log4Shell prendrait une décennie.
En attendant, les équipes de sécurité peuvent prendre certaines mesures pour accélérer l’atténuation et la résolution de Log4Shell dans leurs réseaux.
Avant de découvrir comment détecter et corriger Log4Shell, il est important de comprendre la nature de cette vulnérabilité.
Log4j est un outil de journalisation open source (géré par l’Apache Software Foundation) qui enregistre les informations et les événements d’un programme. Log4j n’est pas un logiciel autonome, mais un ensemble de code que les développeurs peuvent intégrer à leurs applications Java. Le cadre Apache Log4j est utilisé dans certains des services Web les plus importants, comme l’infrastructure réseau Amazon Web Services (AWS), les solutions Cisco ou encore des applications populaires comme Twitter et Minecraft.
Certaines versions de Log4j, en particulier Log4j 2.17.0 et les versions antérieures, souffrent de vulnérabilités graves. La plus dangereuse est Log4Shell (CVE-2021-44228 ; score CVSS : 10), une vulnérabilité zero-day d’exécution de code à distance (RCE) présente dans Log4j 2.14.1 et les versions antérieures.
Log4Shell est une conséquence de la façon dont les versions vulnérables de Log4j gèrent l’interface Java Naming and Directory Interface (JNDI), une API que les applications Java utilisent pour accéder aux ressources hébergées sur des serveurs externes. Les acteurs de la menace peuvent prendre le contrôle quasi total des systèmes vulnérables en envoyant des commandes de recherche JNDI malveillantes via Log4j. Ces commandes poussent l’application à exécuter un code arbitraire capable de tout, ou presque : voler des données, installer un rançongiciel, mettre les appareils hors ligne, etc.
Les cyberattaques Log4Shell se déroulent généralement comme suit :
Alors qu’Apache s’employait à corriger Log4Shell, les chercheurs en sécurité ont identifié une série de failles connexes dans certaines versions de Log4j, et notamment :
Il peut être difficile de trouver chaque instance vulnérable de Log4j dans un réseau. Log4j apparaît dans des millions d’applications, ce qui signifie que les équipes de sécurité ont beaucoup d’actifs à inspecter.
En outre, Log4j se présente souvent comme une dépendance indirecte. Cela signifie qu’il n’est pas directement contenu dans le code source de l’actif, mais qu’il apparaît comme la dépendance d’un progiciel ou d’une intégration sur lesquels l’actif s’appuie. Selon Google, les instances Log4J les plus vulnérables sont situées au-delà du premier niveau de profondeur dans la chaîne de dépendances, et certaines sont situées jusqu’au neuvième niveau de profondeur.
Cela dit, les équipes de sécurité peuvent détecter les vulnérabilités Log4j avec les bonnes tactiques et les bons outils.
Chaque version de Log4j 2, de la version 2.0-beta9 à la version 2.17, est vulnérable à Log4Shell ou à une faille associée. En d’autres termes, les équipes de sécurité doivent trouver et traiter toute version de Log4j antérieure à 2.17.1.
Log4Shell et les failles associées ne sont présentes que dans les fichiers « Log4j-core », qui fournissent les fonctionnalités de base de Log4j. Ces failles ne sont pas présentes dans les fichiers « Log4j-api », qui contrôlent l’interface entre les applications et les outils de journalisation Log4j.
Log4j peut apparaître dans les actifs contrôlés par l’entreprise, dans les actifs tiers utilisés par cette dernière (par exemple, les services cloud), et dans les actifs utilisés par les fournisseurs de services ayant accès au réseau de l’entreprise. Bien que Log4j soit le plus susceptible d’apparaître dans les applications basées sur Java, il peut également être présent dans les applications non Java par le biais de dépendances et d’intégrations.
Dans les applications Java, les bibliothèques telles que Log4j sont souvent regroupées dans des fichiers Java Archive, ou « fichiers JAR ». Les fichiers JAR peuvent contenir d’autres fichiers JAR, qui à leur tour peuvent contenir leurs propres fichiers JAR, et ainsi de suite. Pour trouver toutes les versions vulnérables de Log4j, les équipes de sécurité doivent inspecter tous les niveaux de fichiers JAR, et non seulement les fichiers de premier niveau.
Les experts recommandent de combiner plusieurs techniques pour trouver les vulnérabilités Log4j.
Recherches manuelles. Les équipes de sécurité peuvent rechercher manuellement les failles Log4j. Elles peuvent utiliser des outils de développement comme Apache Maven pour générer des arbres de dépendance qui cartographient toutes les dépendances dans une application, ou elles peuvent utiliser le renseignement externe sur les menaces pour identifier les actifs affectés. Par exemple, la Cybersecurity and Infrastructure Security Agency (CISA) a compilé une liste de logiciels connus pour être affectés par Log4Shell. La liste est disponible sur GitHub.
Dans les systèmes d’exploitation Linux, Microsoft Windows et macOS, les équipes de sécurité peuvent rechercher les instances Log4j dans les répertoires de fichiers à l’aide de l’interface de ligne de commande.
Outils d’analyse des vulnérabilités. À la suite de la découverte de Log4Shell, certaines entreprises ont publié des outils gratuits conçus pour trouver les vulnérabilités Log4j. Parmi les nombreux exemples, citons Log4j-sniffer de Palantir et le scanner du centre de coordination CERT.
Bien que des scanners spécialisés soient toujours disponibles, de nombreuses solutions de sécurité standard telles que les scanners de vulnérabilités, les plateformes de gestion de la surface d’attaque (ASM) et les solutions EDR (détection et réponse aux menaces sur les terminaux) peuvent désormais détecter les vulnérabilités Log4j.
Étant donné que Log4Shell peut se dissimuler profondément dans les chaînes de dépendances, les équipes de sécurité peuvent compléter les analyses automatisées par des méthodes plus pratiques, comme les tests d’intrusion.
Traque des menaces. Selon la CISA, certains attaquants ont utilisé Log4Shell pour s’introduire dans un réseau, puis ils ont corrigé l’actif compromis pour couvrir leurs traces. C’est pourquoi il est recommandé aux équipes de sécurité de supposer qu’une violation s’est déjà produite et de rechercher activement les signes d’exploitation de Log4Shell.
Les outils de cybersécurité tels que les solutions de gestion des informations et des événements de sécurité(SIEM) et les plateformes de détection et de réponse étendues (XDR) permettent de détecter les activités anormales associées à Log4Shell, comme les entrées de journaux étranges ou les schémas de trafic suspects. Les équipes de sécurité doivent lancer des procédures de réponse aux incidents et d’investigation complètes au moindre soupçon de Log4Shell, vu la gravité des conséquences en cas d’attaque.
Les équipes de sécurité disposent de plusieurs options pour corriger les vulnérabilités Log4j.
Pour une résolution complète de Log4Shell et des failles associées, les entreprises doivent mettre à jour toutes les instances de Log4j dans leurs réseaux vers la dernière version (ou au moins vers la version 2.17.1). Les dernières versions de Log4j suppriment les fonctions que les attaquants peuvent exploiter, ainsi que la prise en charge des protocoles couramment utilisés à mauvais escient comme LDAP.
Il n’existe pas de correctif universel à l’échelle du système, et la mise à jour de Java à elle seule ne résout pas le problème. Les équipes de sécurité doivent mettre à jour chaque instance de Log4j dans chaque actif affecté.
Les chercheurs en sécurité s’accordent à dire que l’application de correctifs est la solution idéale. Si l’application de correctifs n’est pas possible, les entreprises peuvent prendre d’autres mesures d’atténuation pour réduire le risque d’attaque.
Désactiver la recherche de messages dans les applications vulnérables. Les attaquants utilisent une fonctionnalité Log4j appelée « substitutions de recherche de messages » pour envoyer des commandes malveillantes aux applications vulnérables. Les équipes de sécurité peuvent désactiver manuellement cette fonction en définissant la propriété système «Log4j2.formatMsgNoLookups » sur « true » ou en définissant la valeur de la variable d’environnement « LOG4J_FORMAT_MSG_NO_LOOKUPS » sur « true ».
Bien que la suppression de la fonction de substitution de recherche de messages complique la tâche des attaquants, elle n’est pas infaillible. Les acteurs malveillants peuvent toujours utiliser CVE-2021-45046 pour envoyer des requêtes JNDI malveillantes aux applications avec des paramètres autres que ceux par défaut.
Suppression de la classe JNDIlookup des applications vulnérables. Dans Log4j, la classe JNDIlookup régit la façon dont l’outil de journalisation gère les requêtes JNDI. Si cette classe est supprimée du répertoire des classes Log4j, les requêtes JNDI ne peuvent plus être effectuées.
Apache indique que la commande suivante peut être utilisée pour supprimer la classe JNDIlookup des applications vulnérables :
zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class
Bien que cette méthode soit plus efficace que l’interdiction des recherches de messages, elle n’empêche pas les pirates de préparer d’autres tentatives d’exploitation, comme le déclenchement d’attaques par déni de service grâce aux recherches récursives.
Bloquer le trafic potentiellement lié à une attaque Log4Shell. Les équipes de sécurité peuvent utiliser des pare-feux d’applications web (WAF), des systèmes de détection et de prévention des intrusions (IDPS), des EDR et d’autres outils de cybersécurité pour intercepter le trafic à destination ou en provenance des serveurs contrôlés par les attaquants en bloquant les protocoles couramment utilisés comme LDAP ou RMI. Les équipes de sécurité peuvent également bloquer les adresses IP associées aux attaques ou les chaînes que les pirates utilisent couramment dans les requêtes malveillantes, telles que « jndi », « ldap » et « rmi ».
Cependant, les attaquants peuvent contourner ces défenses en utilisant de nouveaux protocoles et adresses IP ou en dissimulant les chaînes malveillantes.
Mettre en quarantaine les actifs affectés. En dernier recours, les équipes de sécurité peuvent mettre en quarantaine les actifs affectés en attendant qu’un correctif soit disponible. L’une des méthodes consiste à placer les actifs vulnérables dans un segment de réseau isolé, qui n’est pas accessible directement à partir d’Internet. Un WAF peut être placé autour de ce segment de réseau pour une protection supplémentaire.
L’un des défis liés à la correction de Log4Shell, c’est qu’elle ne persiste pas toujours. En novembre 2022, Tenable indiquait que 29 % des actifs toujours vulnérables à Log4Shell étaient des « récurrences », ce qui signifie qu’ils avaient été corrigés, mais que la faille était réapparue. Les récurrences se produisent lorsque les développeurs utilisent accidentellement des bibliothèques logicielles contenant des versions non corrigées de Log4j pour créer ou mettre à jour les applications.
Bien que les développeurs puissent examiner de plus près les cadres qu’ils utilisent, il est facile de passer à côté des versions vulnérables de Log4j lorsqu’elles se trouvent à plusieurs niveaux dans les fichiers JAR.
Mettre en œuvre de programmes formels de gestion des vulnérabilités et de gestion des correctifs permet aux équipes de sécurité de surveiller plus efficacement les actifs afin de détecter le retour des vulnérabilités Log4j. Procéder régulièrement à des analyses de vulnérabilités et des tests d’intrusion permet de détecter rapidement les nouvelles vulnérabilités, Log4Shell ou autres. La gestion des correctifs garantit que les nouvelles vulnérabilités sont corrigées dès que les fournisseurs publient les correctifs.