Qu’est-ce que la vulnérabilité Log4j ?

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 pourraient utiliser Log4Shell pendant qu'Apache travaillait sur un correctif.
  
  
• 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 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.

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.

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é 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, 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. 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 1^er 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 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.