Log4Shell : la menace n'a pas disparu et pourrait refaire surface si l'industrie ne fait pas attention
Log4Shell : la menace n'a pas disparu et pourrait refaire surface si l'industrie ne fait pas attention,
72 % des entreprises restent sensibles à Log4Shell, selon Tenable
Les projets de vacances de décembre des informaticiens ont été bouleversés l'année dernière par la divulgation d'un bogue majeur dans l'outil Log4j, largement utilisé. Cette découverte a entraîné des mois d'activité fébrile pour corriger la vulnérabilité, mais un an plus tard, elle a disparu du radar. Selon les experts en sécurité, la menace n'a pas disparu pour autant et pourrait refaire surface si l'industrie ne fait pas attention.
Log4j est une bibliothèque de journalisation open source basée sur Java utilisée dans des millions d'applications. Il y a quelques jours, une vulnérabilité dans Log4J a été découverte. Elle permet à un cybercriminel de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement.
Grâce à Log4j, les entreprises technologiques peuvent vérifier si leurs applications fonctionnent correctement. S'il y a un défaut quelque part dans une application, un message d'erreur est envoyé via Log4j au fabricant, qui peut alors déterminer si une réparation est nécessaire. Amazon, Apple, Cloudflare, Tesla, Minecraft et Twitter, entre autres, utilisent également Log4j.
Lorsqu'il a été révélé pour la première fois au début du mois de décembre 2021, le bogue Log4Shell a été décrit comme l'une des vulnérabilités de sécurité les plus graves jamais rencontrées. Il visait un outil populaire de journalisation de l'activité dans les logiciels Java, conçu pour aider à garder une trace des erreurs et à diagnostiquer les problèmes de performance. Grâce à sa grande utilité, Log4j a été intégré dans des milliers de logiciels et a été trouvé dans une grande variété de services commerciaux, y compris Amazon Web Services et le jeu vidéo Minecraft. Qui plus est, le bogue a permis aux attaquants de prendre le contrôle total des systèmes vulnérables en toute simplicité.
Cela a entraîné une course effrénée pour combler les lacunes. La fondation Apache Software, qui gère l'outil open source, a rapidement publié un correctif, et les organisations ont passé des mois à analyser leurs systèmes et à mettre à jour leurs logiciels. Mais plus d'un an plus tard, la société de cybersécurité Tenable affirme que 72 % des entreprises restent sensibles à Log4Shell. Et, fait inquiétant, un grand nombre d'organisations qui avaient corrigé le bogue l'ont depuis réintroduit dans leurs systèmes en installant des logiciels vulnérables, déclare Bernard Montel, directeur technique et stratège en sécurité chez Tenable.
Le 9 décembre 2021, une vulnérabilité a été découverte dans la bibliothèque de journalisation Apache log4j. Cette bibliothèque est très souvent utilisée dans les projets de développement d'application Java/J2EE ainsi que par les éditeurs de solutions logicielles sur étagère basées sur Java/J2EE. La vulnérabilité dans Log4J permet à un cybercriminel de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement. Cette attaque peut être réalisée sans être authentifié, par exemple en tirant parti d'une page d'authentification qui journalise les erreurs d'authentification.
Comme dit précedement, Log4Shell est une vulnérabilité logicielle dans Apache Log4j 2, une bibliothèque Java populaire permettant de consigner les messages d'erreur dans les applications. La vulnérabilité, publiée sous le nom de CVE-2021-44228, permet à un attaquant distant de prendre le contrôle d'un appareil sur Internet si l'appareil exécute certaines versions de Log4j 2.
Apache a publié un correctif pour CVE-2021-44228, version 2.15, le 6 décembre 2021. Cependant, ce correctif laissait une partie de la vulnérabilité non corrigée, ce qui a donné lieu à CVE-2021-45046 et à un deuxième correctif, version 2.16, publié le 13 décembre. Apache a publié un troisième correctif, la version 2.17, le 17 décembre pour corriger une autre vulnérabilité connexe, CVE-2021-45105. Un quatrième correctif, 2.17.1, a été publié le 28 décembre pour corriger une autre vulnérabilité, CVE-2021-44832.
Les attaquants peuvent exploiter cette vulnérabilité en utilisant des messages texte pour contrôler un ordinateur à distance. L'Apache Software Foundation, qui publie la bibliothèque Log4j 2, a attribué à la vulnérabilité un score CVSS de 10, le score de gravité le plus élevé, en raison de son potentiel d'exploitation à grande échelle et de la facilité avec laquelle les attaquants malveillants peuvent l'exploiter. Alors que les mesures d'atténuation évoluent et que les dégâts se déploient, les principes fondamentaux de la vulnérabilité Log4j ne changeront pas.
Le chercheur en sécurité Chen Zhaojun d'Alibaba, la plus grande société de commerce électronique de Chine, a signalé pour la première fois la vulnérabilité à la Fondation Apache (un projet open-source) le 24 novembre. Ils ont découvert l'attaque le 9 décembre sur des serveurs qui hébergent le jeu Minecraft. Après une analyse forensique plus poussée, ils ont réalisé que les cybercriminels avaient découvert la faille plus tôt, et l'exploitaient depuis au moins le 1er décembre 2021.
L'équipe open source de Google a déclaré avoir analysé Maven Central, le plus grand référentiel de packages Java, et a découvert que 35 863 packages Java utilisent des versions vulnérables de la bibliothèque Apache Log4j. Cela inclut les packages Java qui utilisent des versions Log4j vulnérables à l'exploit Log4Shell d'origine (CVE-2021-44228) et un deuxième bogue d'exécution de code à distance découvert dans le correctif Log4Shell (CVE-2021-45046).
« Lorsqu'ils ont mis en place un plan pour le réparer il y a environ un an, ils pensaient l'avoir fait », dit-il. « Ils ont nettoyé, ils ont identifié, ils ont scanné, ils ont patché leurs logiciels et pour eux, ils ont fait ce qu'ils avaient à faire. Ils ont juste oublié le fait que la surface d'attaque se déplace. »
Tenable estime que la proportion de machines vulnérables à l'exploit est passée d'une sur dix en décembre dernier à seulement 2,5 % en octobre dernier. Mais jusqu'à un tiers de ces machines avaient déjà été entièrement corrigées et ont depuis été réinfectées par Log4Shell. Selon Montel, une partie du problème réside dans le fait que Log4j est profondément enfoui dans un grand nombre de bibliothèques logicielles courantes.
Il n'est souvent pas évident de savoir si l'utilitaire est inclus dans un outil particulier, et même lorsqu'il l'est, la plupart des développeurs ne sont pas suffisamment sensibilisés à la sécurité pour vérifier s'il s'agit de la version la plus récente, compte tenu notamment de la pression qu'ils subissent pour produire du code rapidement, ajoute-t-il. Des recherches menées par la société de sécurité Sonatype il y a un an ont révélé que 65 % des téléchargements de Log4j concernaient des versions vulnérables de l'outil.
Au niveau organisationnel, Montel pense également qu'après l'énorme pression exercée pour traiter la vulnérabilité au cours des premiers mois, il était presque inévitable que les gens se déconcentrent une fois qu'ils avaient l'impression d'avoir remédié au problème. Il pense qu'il existe des analogies évidentes avec la pandémie de Covid-19, au cours de laquelle des mesures rigoureuses telles que les fermetures ont rapidement permis de maîtriser le virus, avant qu'il ne réapparaisse lorsque les choses se sont à nouveau détendues. « Il [Log4j] revient », affirme Montel. « Il est toujours là quelque part, il suffit d'observer les vagues ».
Un rapport de juillet du Cyber Safety Review Board du ministère de la Sécurité intérieure indique que le bug était devenu « endémique » et qu'il était susceptible de rester un problème pendant des années, voire des décennies. Et les données recueillies par la société de sécurité Imperva ont montré que si les attaques exploitant le bug ont considérablement diminué depuis les deux premiers mois de 2022, on observe une augmentation constante depuis novembre, le 3 décembre de cette année ayant vu les attaques quotidiennes les plus élevées depuis la découverte de la vulnérabilité.
Imperva estime qu'environ 7 % de ces attaques sont couronnées de succès. Mais bien qu'il y ait eu quelques piratages très médiatisés - dont ceux menés par des pirates chinois parrainés par l'État en mars et une attaque iranienne contre une agence fédérale américaine en novembre - jusqu'à présent, le bug n'a pas été à la hauteur des prédictions terribles faites l'année dernière. « Bien que de nombreuses entreprises aient été touchées, le nombre d'attaques a été largement inférieur à ce qui avait été prévu », explique Gabi Stapel, analyste de la recherche sur les menaces chez Imperva.
Il a cependant mis en lumière la dépendance de nombreuses entreprises à l'égard de codes tiers et open source sur lesquels elles n'ont que peu de contrôle ou de visibilité. « Historiquement, les entreprises se sont concentrées sur le risque introduit par leurs fournisseurs immédiats et les logiciels critiques dont elles dépendent », explique Stapel. « Les organisations doivent adopter un modèle de menace qui inclut toutes les parties de la chaîne d'approvisionnement. »
Le coût et la complexité de la réponse à Log4Shell ont certainement incité à mettre de plus en plus l'accent sur la sécurisation de la chaîne d'approvisionnement des logiciels et à stimuler la transparence, déclare Eric Goldstein, directeur adjoint exécutif pour la cybersécurité à la Cybersecurity and Infrastructure Security Agency (CISA). « Une multitude de nouveaux outils, entreprises et produits ont vu le jour l'année dernière pour aider à mieux comprendre les dépendances logicielles, et Log4j est souvent utilisé comme motivation principale pour l'innovation et l'adoption », explique-t-il.
L'un des remèdes potentiels promus par la CISA est le Software Bill of Materials (SBOM). Il s'agit d'un inventaire de tous les composants d'une application logicielle, conçu pour permettre aux développeurs de repérer plus facilement toute dépendance à l'égard de parties de code potentiellement dangereuses. Le gouvernement américain a indiqué qu'ils pourraient bientôt devenir une exigence pour les logiciels fournis aux agences fédérales.
Pour que cette approche ait réellement un impact, elle doit cependant se déplacer plus en amont, déclare Brian Behlendorf, directeur général de l'Open Source Security Foundation (OSSF), afin que même les paquets ou bibliothèques de logiciels libres originaux que les développeurs assemblent pour créer des applications soient accompagnés de leurs propres SBOM. Pour y parvenir, il faudra probablement créer de nouveaux outils qui simplifient ce processus et les intégrer aux outils de création de logiciels existants, explique Behlendorf, car « il peut être difficile d'inciter les développeurs à fournir un effort supplémentaire ».
L'industrie dans son ensemble doit également mieux se coordonner et être plus proactive en matière de sécurisation des outils open source sur lesquels elle s'appuie, dit-il. Selon Behlendorf, les projets individuels ne disposent tout simplement pas des ressources financières ou humaines nécessaires pour effectuer des tâches telles que la révision du code. « Il y a tout simplement un décalage entre la valeur que doit recevoir l'écosystème et la capacité à rassembler ce type de ressources », dit-il. « Ce dont nous avons besoin, c'est d'institutions capables d'agréger la demande d'un meilleur examen de ces choses et de canaliser les ressources vers des objectifs ciblés et faciles à atteindre. »
Source : IEEE
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi :
Répondre avec citation
Partager