La vulnérabilité Log4j, ou «Log4Shell", est considérée comme l'une des failles logicielles les plus catastrophiques jamais vues. Apache a corrigé la faille en décembre 2021, mais elle reste une préoccupation pour les équipes de sécurité. En fait, il fait toujours partie des failles de sécurité les plus exploitées.

Log4Shell persiste car le progiciel Apache Log4j 2 qu'il affecte est l'une des bibliothèques de journalisation les plus utilisées au monde. Trouver et réparer chaque instance de Log4Shell devrait prendre une décennie, selon le Le Département Américain de la Sécurité Intérieure.

En attendant, les équipes de sécurité peuvent prendre certaines mesures pour accélérer l’atténuation et la correction de Log4Shell dans leurs réseaux. 

Comprendre les vulnérabilités de Log4j  

Avant d'examiner comment détecter et corriger Log4Shell, il est important de comprendre la nature de la vulnérabilité.

log4j est un enregistreur open source (maintenu par Apache Software Foundation) qui enregistre les informations et les événements dans un programme. Log4j n'est pas un logiciel autonome mais un package de code que les développeurs peuvent intégrer à leurs propres applications Java. Le framework Apache Log4j est utilisé dans certains des plus grands services du Web, allant de l'infrastructure réseau comme Amazon Web Services (AWS) et les solutions Cisco aux applications populaires comme Twitter et Minecraft.

Certaines versions de Log4j, en particulier Log4j 2.17.0 et versions antérieures, souffrent de graves vulnérabilités. Le plus dangereux d'entre eux est Log4Shell (CVE-2021-44228 ; note CVSS : 10), une exécution de code à distance (RCE) vulnérabilité zéro jour trouvé dans les versions 4 et antérieures de Log2.14.1j. 

Log4Shell est le résultat de la façon dont les versions vulnérables de Log4j gèrent l'interface Java Naming and Directory (JNDI), un API que les applications Java utilisent pour accéder aux ressources hébergées sur des serveurs externes. Les acteurs malveillants peuvent prendre le contrôle presque total des systèmes vulnérables en envoyant des commandes de recherche JNDI malveillantes via Log4j. Ces commandes incitent l'application à exécuter du code arbitraire qui peut faire presque tout : voler des données, installez ransomware, mettez les appareils hors ligne, et bien plus encore.

Attaques Log4Shell

Un Log4Shell typique cyberattaque fonctionne comme ceci: 

1. Un pirate informatique configure un serveur à l'aide d'un protocole commun, tel que LDAP (Lightweight Directory Access Protocol) ou DNS (Domain Name System). 
2. Le pirate informatique stocke des logiciels malveillants ou d’autres charges utiles malveillantes sur le serveur.
3. Le pirate informatique envoie une recherche JNDI à une application exécutant Log4j, dirigeant l'application vers le serveur du pirate informatique. 
4. La recherche JNDI amène l'application à se connecter au serveur du pirate informatique, à télécharger la charge utile malveillante et à exécuter le code malveillant. 

Vulnérabilités Log4j associées et comment elles sont exploitées

Alors qu'Apache travaillait à la mise à jour de Log4Shell, les chercheurs en sécurité ont identifié une poignée de failles associées dans certaines versions de Log4j. Ceux-ci inclus: 

• CVE-2021-45046 permet aux pirates d'envoyer des recherches JNDI malveillantes aux systèmes qui utilisent certains paramètres autres que ceux par défaut, même si ces systèmes ont corrigé Log4Shell. Présent dans les versions Log4j 2.15 et inférieures.  
• CVE-2021-45105 permet aux pirates de lancer attaques par déni de service en envoyant des messages malveillants à Log4j. Présent dans les versions 4 et inférieures de Log2.16j. 
• CVE-2021-44832 est une vulnérabilité d'exécution de code à distance. Cette faille est moins critique que Log4Shell car les pirates doivent obtenir des autorisations élevées avant de pouvoir l'exploiter. Présent dans les versions 4 et inférieures de Log2.17j.  

Comment détecter les vulnérabilités Log4j   

Trouver chaque instance vulnérable de Log4j dans un réseau peut être difficile. Log4j apparaît dans une estimation des millions d'applications, ce qui signifie que les équipes de sécurité ont de nombreux actifs à inspecter. 

De plus, Log4j est souvent présent comme dépendance indirecte. Cela signifie qu'il n'est pas directement contenu dans le code source d'un actif, mais qu'il apparaît comme une dépendance d'un progiciel ou d'une intégration sur lequel repose l'actif. Rapports de Google que les instances Log4j les plus vulnérables se trouvent à plus d'un niveau dans la chaîne de dépendances, et certaines ont jusqu'à neuf niveaux de profondeur.

Cela dit, les équipes de sécurité peuvent détecter les vulnérabilités de Log4j avec les bonnes tactiques et outils.  

Ce qu'il faut chercher

Chaque version de Log4j 2 de 2.0-beta9 à 2.17 est vulnérable à Log4Shell ou à une faille associée. En d’autres termes, les équipes de sécurité doivent rechercher et traiter toute version de Log4j antérieure à 2.17.1.

Log4Shell et ses failles associées ne sont présentes que dans les fichiers « Log4j-core », qui fournissent les fonctionnalités de base de Log4j. Les failles ne sont pas présentes dans les fichiers « Log4j-api », qui contrôlent l'interface entre les applications et les enregistreurs Log4j.

Log4j peut apparaître dans les actifs contrôlés par l'entreprise, les actifs tiers que l'entreprise utilise (par exemple, les services cloud) et les actifs utilisés par les fournisseurs de services ayant accès au réseau de l'entreprise. Bien que Log4j soit plus susceptible d'apparaître dans les applications basées sur Java, il peut également être présent dans les applications non Java via des dépendances et des intégrations.

Dans les applications Java, les bibliothèques comme 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 des fichiers JAR, et pas seulement les fichiers de niveau supérieur.

Comment le trouver 

Les experts recommandent d'utiliser une combinaison de techniques pour trouver les vulnérabilités de Log4j.

Recherches manuelles. Les équipes de sécurité peuvent rechercher manuellement les failles Log4j. Ils peuvent utiliser des outils de développement comme Apache Maven pour générer des arborescences de dépendances qui mappent toutes les dépendances d'une application, ou ils peuvent utiliser des outils de développement externes. renseignements sur les menaces pour identifier les actifs concernés. Par exemple, la Cybersecurity and Infrastructure Security Agency (CISA) a dressé une liste de logiciels connus pour souffrir de Log4Shell. La liste est disponible sur GitHub.

Sur les systèmes d'exploitation Linux, Microsoft Windows et macOS, les équipes de sécurité peuvent rechercher dans les répertoires de fichiers des instances de Log4j à l'aide de l'interface de ligne de commande.

Outils d'analyse des vulnérabilités. Suite à la découverte de Log4Shell, certaines organisations ont publié des outils gratuits conçus pour détecter les vulnérabilités de Log4j. Les exemples comprennent Le renifleur Log4j de Palantir ainsi que  le scanner du Centre de Coordination du CERT, parmi beaucoup d'autres.

Bien que des scanners spécialisés soient toujours disponibles, de nombreuses solutions de sécurité standard telles que scanners de vulnérabilité, gestion de la surface d'attaque (ASM) et détection et réponse des points de terminaison (EDR) peuvent désormais détecter les vulnérabilités Log4j.

Étant donné que Log4Shell peut se cacher profondément dans les chaînes de dépendance, les équipes de sécurité peuvent compléter les analyses automatisées avec des méthodes plus pratiques, comme tests de pénétration.

Chasse aux menaces. Selon CISA, il est connu que des attaquants utilisent Log4Shell pour pénétrer dans un réseau, puis patcher l'actif qu'ils ont compromis pour brouiller les pistes. Pour cette raison, il est recommandé aux équipes de sécurité de supposer qu'une violation s'est déjà produite et chasser activement pour des signes d’exploitation de Log4Shell.

Des outils de cybersécurité comme gestion des informations de sécurité et des événementst (SIEM) et détection et réponse étendues (XDR) peuvent aider à détecter les activités anormales associées à Log4Shell, comme des entrées de journal étranges ou des modèles de trafic suspects. Les équipes de sécurité devraient lancer pleinement réponse à l'incident et des procédures d'enquête pour toute trace possible de Log4Shell, compte tenu de la gravité des conséquences d'une attaque.

Comment corriger les vulnérabilités de Log4j

Les équipes de sécurité disposent de quelques options pour remédier aux vulnérabilités de Log4j.

Le meilleur des cas : corriger les systèmes vulnérables  

Pour une correction complète de Log4Shell et des failles associées, les organisations 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 comme LDAP.

Il n'existe pas de correctif unique à l'échelle du système et la mise à jour de Java elle-même ne résout pas le problème. Les équipes de sécurité doivent mettre à jour chaque instance de Log4j dans chaque actif concerné. 

Autres mesures d'atténuation

Les chercheurs en sécurité conviennent que patcher est la solution idéale. Si l'application de correctifs n'est pas réalisable, les organisations peuvent utiliser d'autres mesures d'atténuation pour minimiser les risques d'attaque.

Interdire les recherches de messages dans les applications vulnérables. Les attaquants utilisent une fonctionnalité de Log4j appelée « substitutions de recherche de messages » pour envoyer des commandes malveillantes aux applications vulnérables. Les équipes de sécurité peuvent interdire manuellement cette fonction en modifiant 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 ».  

Même si la suppression de la fonction de substitution de recherche de messages rend les attaques plus difficiles pour les attaquants, elle n’est pas infaillible. Les acteurs malveillants peuvent toujours utiliser CVE-2021-45046 pour envoyer des recherches JNDI malveillantes à des 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 manière dont le consignateur gère les recherches JNDI. Si cette classe est supprimée du répertoire des classes de Log4j, les recherches JNDI ne peuvent plus être effectuées.

Apache note 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 d'interdire les recherches de messages, elle n'empêche pas les attaquants de lancer d'autres tentatives d'exploitation, comme déclencher des attaques par déni de service via des recherches récursives.

Bloquer le trafic d'attaque potentiel de Log4Shell. Les équipes de sécurité peuvent utiliser pare-feu d'applications Web (WAF), systèmes de détection et de prévention des intrusions (IDPS), EDR et autres outils de cybersécurité pour intercepter le trafic vers et depuis les 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 Adresses IP associées aux attaques ou les chaînes que les attaquants 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 obscurcissant les chaînes malveillantes.

Mise en quarantaine des actifs concernés. Si tout le reste échoue, les équipes de sécurité peuvent mettre en quarantaine les actifs concernés en attendant un correctif. Une façon d’y parvenir consiste à placer les actifs vulnérables dans un segment de réseau isolé auquel on ne peut pas accéder directement depuis Internet. Un WAF peut être placé autour de ce segment de réseau pour une protection supplémentaire.

Garder Log4Shell à distance

L'une des difficultés liées à la correction de Log4Shell est qu'il ne reste pas toujours corrigé. En novembre 2022, Tenable signalé que 29 % des actifs encore vulnérables à Log4Shell étaient des « récidives », c'est-à-dire qu'ils ont été corrigés, mais la faille est réapparue. Des récidives se produisent lorsque les développeurs utilisent accidentellement des bibliothèques de logiciels contenant des versions non corrigées de Log4j pour créer ou mettre à jour des applications.

Bien que les développeurs puissent examiner de plus près les frameworks qu'ils utilisent, il est facile de manquer les versions vulnérables de Log4j lorsqu'elles se trouvent à plusieurs niveaux dans les fichiers JAR.

Mise en œuvre formelle gestion des vulnérabilités ainsi que gestion des correctifs les programmes peuvent offrir aux équipes de sécurité un moyen plus efficace de surveiller les actifs pour détecter le retour des vulnérabilités Log4j. Une analyse régulière des vulnérabilités et des tests d'intrusion peuvent aider à détecter rapidement de nouvelles vulnérabilités, Log4Shell ou autre. La gestion des correctifs garantit que les nouvelles vulnérabilités sont corrigées dès que les fournisseurs publient des correctifs.   

Plus d'aide pour lutter contre Log4Shell et d'autres vulnérabilités du jour zéro

De plus en plus, les pirates informatiques utilisent des outils automatisés pour exploiter facilement les vulnérabilités du jour zéro telles que Log4Shell et pour lancer un barrage d'attaques de ransomwares et d'autres cybermenaces. Les équipes de sécurité travaillant avec des approches traditionnelles de sécurité des points finaux sont confrontées à une lassitude face aux alertes, à des outils complexes et à de longues enquêtes, et ont du mal à suivre le rythme.

IBM Security® QRadar® EDR, anciennement ReaQta, corrige les menaces connues et inconnues des points finaux en temps quasi réel grâce à une automatisation intelligente facile à utiliser qui nécessite peu ou pas d'interaction humaine. Avec QRadar EDR, les analystes peuvent prendre des décisions rapides et éclairées et utiliser la gestion automatisée des alertes pour se concentrer sur les menaces les plus importantes. Des capacités avancées d’apprentissage continu en IA et une interface conviviale redonnent le contrôle au personnel de sécurité et contribuent à garantir la continuité des activités.

Explorez IBM Security QRadar EDR