La vulnérabilité Log4j, aussi connue sous le nom de « Log4Shell », est une vulnérabilité critique découverte dans la bibliothèque de journalisation Apache Log4j en novembre 2021. Concrètement, Log4Shell accorde aux pirates le contrôle total des appareils exécutant des versions non corrigées de Log4j. Les acteurs malveillants peuvent profiter d’une faille pour exécuter n’importe quel code, ou presque, sur les systèmes vulnérables.
Les chercheurs considèrent Log4Shell comme une vulnérabilité « catastrophique » en matière de sécurité, car elle est extrêmement répandue et facile à exploiter. En effet, Log4j est l’un des programmes open source les plus largement déployés au monde. Jen Easterly, directrice de l’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA), a déclaré qu’il s’agissait de « l’un des problèmes les plus graves que j’ai vus de toute ma carrière, voire le plus grave ».
Log4Shell a provoqué une augmentation des cyberattaques en décembre 2021. L’Index X-Force Threat Intelligence d’IBM a enregistré une augmentation de 34 % des exploitations de vulnérabilités entre 2020 et 2021, attribuée principalement à Log4Shell.
Peu de temps après cette découverte, Log4Shell a été corrigée, mais elle présentera un risque pendant des années, car Log4j est profondément intégrée à la chaîne d’approvisionnement logicielle. Le département de la Sécurité intérieure des États-Unis (PDF ; lien externe à ibm.com) estime qu’il faudra au moins une décennie pour trouver et corriger chacune des instances vulnérables.
Log4j est un framework de journalisation développé par l’Apache Software Foundation. Comme son nom l’indique, Log4j est un journal d’événements. Il enregistre des informations importantes telles que les messages d’erreur et les entrées utilisateur dans un programme.
Log4j est une bibliothèque de logiciels open source, un ensemble de codes préécrits que les développeurs peuvent utiliser librement. Au lieu d’écrire leurs propres journaux d’événements, les développeurs peuvent connecter la bibliothèque Log4j à leurs applications. C’est la raison pour laquelle Log4j est si répandue, intégrée dans des produits de grandes entreprises comme Microsoft et Amazon, pour n’en citer que quelques-unes.
Log4Shell (Identifiant de vulnérabilités et d’expositions communes CVE-2021-44228) est une vulnérabilité d’exécution de code à distance (RCE) présente dans certaines versions de Log4j. La faille affecte Apache Log4j 2, les versions 2.14.1 et antérieures. Log4j 2.15 et les versions ultérieures, ainsi que toutes les versions d’Apache Log4j 1, ne sont pas affectées.
Log4Shell découle de la manière dont les anciennes versions de Log4j 2 gèrent les recherches JNDI (Java Naming and Directory Interface). JNDI est une interface de programmation d’applications (API) que les applications Java utilisent pour accéder aux ressources hébergées sur des serveurs externes. Une recherche JNDI est une commande qui indique à l’application de se rendre sur 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.
Les utilisateurs peuvent envoyer des recherches JNDI vers des versions vulnérables de Log4j en les incluant dans les messages de journal. Il s’agit d’un processus très simple. Par exemple, dans les anciennes versions de Minecraft Java Edition, qui utilisent Log4j pour enregistrer des messages d’utilisateurs, un internaute peut saisir la recherche JNDI dans la fenêtre de chat publique.
Les pirates peuvent utiliser cette fonctionnalité JNDI pour exécuter à distance du code arbitraire malveillant. Tout d’abord, le pirate configure un serveur à l’aide d’un protocole commun, tel que le protocole Light Directory Access (LDAP) pour éviter d’attirer l’attention. Ensuite, il y stocke du contenu malveillant, comme un fichier malware. Enfin, il envoie une recherche JNDI à un programme, lui indiquant d’accéder au serveur LDAP de l’attaquant, de télécharger le contenu et d’exécuter le code.
Des chercheurs en sécurité du géant de la technologie Alibaba ont découvert Log4Shell le 24 novembre 2021. Elle a immédiatement reçu le score CVSS (Common Vulnerability Scoring System) le plus élevé possible : 10 sur 10. Plusieurs facteurs ont contribué à cette note.
- Log4Shell était une vulnérabilité zero-day, ce qui signifie qu’aucun correctif n’était disponible lors de sa découverte. Les acteurs malveillants pouvaient donc exploiter Log4Shell pendant qu’Apache travaillait sur une solution.
- Log4j est également l’une des bibliothèques de journalisation les plus utilisées, intégrée aux terminaux grand public, aux applications Web et aux services cloud des entreprises. Selon Wiz et EY, 93 % de tous les environnements cloud étaient exposés à des risques (lien externe à ibm.com) lorsque Log4Shell a été découverte.
- Il est difficile pour les entreprises de savoir immédiatement si elles sont vulnérables. Log4j est souvent présente dans les réseaux en tant que dépendance indirecte, ce qui signifie que les actifs de l’entreprise n’utilisent pas forcément Log4j, mais peuvent s’appuyer sur d’autres applications et services qui le font.
- Enfin, Log4Shell est très facile à exploiter. Les pirates n’ont pas besoin d’obtenir des autorisations ou authentifications spéciales. Ils peuvent faire des ravages en tapant des commandes malveillantes dans des formulaires publics tels que des fenêtres de discussion et des pages de connexion. Et comme Log4j peut communiquer avec d’autres services sur le même système, les pirates peuvent l’utiliser pour transmettre du contenu utile à d’autres parties du système.
D’ici le 9 décembre 2021, le code de faisabilité sur la façon d’exploiter Log4Shell a été publié sur GitHub et les pirates étaient en train de préparer des attaques. De grandes entreprises et services comme Minecraft, Twitter et Cisco ont été exposées. À la pointe de l’activité de Log4Shell, Check Point a observé plus de 100 attaques par minute, affectant plus de 40 % de tous les réseaux métier dans le monde (lien externe à ibm.com).
Les premières attaques ont propagé des malwares de type botnet et de cryptominage. Certains pirates ont profité de la faille pour lancer des attaques sans fichier, en envoyant des scripts malveillants aux ordinateurs Windows et Linux pour les faire divulguer des mots de passe et d’autres informations sensibles.
Plusieurs ransomware se sont emparés de Log4Shell. Les pirates ont notamment propagé la souche du ransomware Khonsari via Minecraft. Le ransomware Night Sky ciblait les systèmes exécutant VMware Horizon.
Même les acteurs des États-nations ont rejoint le mouvement. Des pirates informatiques associés à la Chine, à l’Iran, à la Corée du Nord et à la Turquie ont exploité cette vulnérabilité.
Apache a déployé le premier correctif (Log4j version 2.15.0) le 10 décembre 2021. Cependant, ce correctif a révélé une autre vulnérabilité, CVE-2021-45046, qui permettait aux pirates d’envoyer des commandes malveillantes aux journaux à l’aide de paramètres non définis par défaut.
Apache a publié un deuxième correctif (Log4j version 2.16.0) le 14 décembre 2021. Il présentait lui aussi une faille, CVE-2021-45105, grâce à laquelle les pirates pouvaient lancer des attaques par déni de service (DoS).
Le troisième correctif, Log4j version 2.17, a corrigé la faille DoS mais en laissant une dernière vulnérabilité, CVE-2021-44832, qui permettait aux pirates de prendre le contrôle d’un composant Log4j appelé « appender » pour exécuter du code à distance. Apache a résolu ce problème avec un quatrième et dernier correctif, Log4j version 2.17.1.
Bien que Log4j 2.17.1 ait fermé Log4Shell et toutes les vulnérabilités associées du côté d’Apache, les cybermenaces utilisent toujours cette faille. Pas plus tard qu’en mai 2023, Log4Shell restait l’une des vulnérabilités les plus souvent exploitées (lien externe à ibm.com).
Plusieurs raisons expliquent la persistance de Log4Shell.
Tout d’abord, Log4j est profondément enfouie dans les chaînes d’approvisionnement logicielles de nombreuses entreprises. Aujourd’hui, de nombreuses applications sont créées en assemblant des bibliothèques de logiciels open source préexistantes. Ce processus est pratique, mais cela signifie également que les organisations disposent d’une visibilité limitée sur tous les composants qui constituent leurs applications. Il est donc aisé de manquer d’anciennes versions de Log4j.
Une fois qu’une version vulnérable de Log4j est corrigée, elle ne le reste pas toujours. En novembre 2022, Tenable a indiqué (lien externe à ibm.com) que 29 % des actifs toujours vulnérables à Log4Shell étaient des « récurrences ». Bien qu’elles aient été corrigées dans le passé, la faille a réapparu. Ce scénario se produit parce que lorsque des utilisateurs créent ou mettent à jour des applications, ils utilisent parfois accidentellement des bibliothèques de logiciels qui contiennent encore des versions non corrigées de Log4j.
Enfin, les pirates ont développé un moyen astucieux de couvrir leurs traces. Selon CISA (lien externe à ibm.com), certains pirates utilisent Log4Shell pour pénétrer dans un réseau, puis corriger l’actif. L’entreprise pense alors que celui-ci est sécurisé, alors que les pirates s’y sont déjà introduit.
Les dernières versions de Log4j sont exemptes de Log4Shell. Les spécialistes de la cybersécurité recommandent aux équipes de sécurité de s’assurer que toutes les instances de Log4j dans leurs systèmes sont à jour.
La mise à jour de Log4j peut être un processus lent, car les entreprises doivent souvent fouiller dans leurs actifs pour la trouver. En attendant, les équipes de sécurité peuvent utiliser des outils d’analyse continue des vulnérabilités et de détection des menaces comme la gestion des surfaces d’attaque (ASM) et la détection et la réponse des terminaux (EDR) pour surveiller les actifs connectés à Internet. Les spécialistes recommandent aux équipes de réponse aux incidents d’enquêter de manière approfondie sur tout soupçon d’activité Log4Shell.
Après le lancement de Log4Shell, de nombreux pare-feux, systèmes de détection des intrusions et systèmes de prévention des intrusions ont ajouté des règles pour repérer l’exploitation de Log4Shell. Ces outils peuvent aider les équipes de sécurité à détecter et à bloquer le trafic des serveurs contrôlés par des attaquants.
18 juillet 2013 : Apache publie Log4j 2.0-beta9, la première version prenant en charge le plug-in JNDI. Bien que la vulnérabilité ne soit découverte que quelques années plus tard, Log4Shell est présente à partir de ce moment-là.
24 novembre 2021 : les chercheurs en sécurité d’Alibaba découvrent Log4Shell et la signalent à Apache. Apache commence à travailler sur un correctif mais ne publie pas de recommandation de sécurité publique.
9 décembre 2021 : Des chercheurs en sécurité d’Alibaba trouvent des preuves que Log4Shell fait l’objet de discussions et le code d’exploitation de la preuve de concept est publié sur GitHub.
10 décembre 2021 : Apache émet le premier correctif et les développeurs Minecraft découvrent Log4Shell dans Minecraft Java Edition. La communauté de cybersécurité se rend rapidement compte de la gravité de la situation et les organisations commencent verrouiller leurs systèmes.
11 décembre 2021 : Cloudflare trouve des preuves que les acteurs de la menace ont commencé à exploiter Log4Shell plus tôt qu’on ne le pensait, dès le 1er décembre.
14 décembre 2021 : CVE-2021-45046 est découvert et Apache publie un correctif pour y remédier.
17 décembre 2021 : CVE-2021-45105 est découvert et Apache publie un correctif pour y remédier.
28 décembre 2021 : CVE-2021-44832 est découvert et Apache publie un correctif final. Depuis Log4j version 2.17.1, Log4Shell est entièrement corrigée.
4 janvier 2022 : la Federal Trade Commission (FTC) américaine (link externe à ibm.com) annonce qu’elle a l’intention de poursuivre toute entreprise exposant les données des consommateurs aux pirates car elle n’a pas résolu Log4Shell.
Mai 2023 : Check Point constate que Log4Shell est toujours la deuxième vulnérabilité la plus couramment exploitée.
Déjouez les cyberattaques grâce à une Suite sécurité connectée et modernisée. Le portefeuille QRadar est intégré à l’IA de niveau entreprise et propose des produits intégrés pour la sécurité des terminaux, la gestion des logs, les SIEM et SOAR avec une interface utilisateur commune, des informations partagées et des workflows 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é. Le fait de disposer d’une équipe de réponse aux incidents de confiance peut réduire votre temps de réponse, minimiser l’impact d’une cyberattaque et vous aider à vous rétablir plus rapidement.
Découvrez tout ce que vous devez savoir sur les exploits zero-day et le rôle crucial qu’ils jouent dans la sécurité. Conçu par Randori, une société IBM.
Les cyberattaques désignent les tentatives de vol, d’exposition, d’altération, de désactivation ou de destruction des biens d’autrui via un accès non autorisé à des systèmes informatiques.
La gestion des vulnérabilités est la découverte et la résolution continues des failles de sécurité dans l’infrastructure et les logiciels informatiques d’une organisation.