Les projets de vacances de dcembre des informaticiens ont t bouleverss l’anne dernire par la divulgation d’un bogue majeur dans l’outil Log4j, largement utilis. Cette dcouverte a entran des mois d’activit fbrile pour corriger la vulnrabilit, mais un an plus tard, elle a disparu du radar. Selon les experts en scurit, la menace n’a pas disparu pour autant et pourrait refaire surface si l’industrie ne fait pas attention.
Log4j est une bibliothque de journalisation open source base sur Java utilise dans des millions d’applications. Il y a quelques jours, une vulnrabilit dans Log4J a t dcouverte. Elle permet un cybercriminel de provoquer une excution de code arbitraire distance s’il a la capacit de soumettre une donne une application qui utilise la bibliothque log4j pour journaliser l’vnement.
Grce Log4j, les entreprises technologiques peuvent vrifier si leurs applications fonctionnent correctement. S’il y a un dfaut quelque part dans une application, un message d’erreur est envoy via Log4j au fabricant, qui peut alors dterminer si une rparation est ncessaire. Amazon, Apple, Cloudflare, Tesla, Minecraft et Twitter, entre autres, utilisent galement Log4j.
Lorsqu’il a t rvl pour la premire fois au dbut du mois de dcembre 2021, le bogue Log4Shell a t dcrit comme l’une des vulnrabilits de scurit les plus graves jamais rencontres. Il visait un outil populaire de journalisation de l’activit dans les logiciels Java, conu pour aider garder une trace des erreurs et diagnostiquer les problmes de performance. Grce sa grande utilit, Log4j a t intgr dans des milliers de logiciels et a t trouv dans une grande varit de services commerciaux, y compris Amazon Web Services et le jeu vido Minecraft. Qui plus est, le bogue a permis aux attaquants de prendre le contrle total des systmes vulnrables en toute simplicit.
Cela a entran une course effrne pour combler les lacunes. La fondation Apache Software, qui gre l’outil open source, a rapidement publi un correctif, et les organisations ont pass des mois analyser leurs systmes et mettre jour leurs logiciels. Mais plus d’un an plus tard, la socit de cyberscurit Tenable affirme que 72 % des entreprises restent sensibles Log4Shell. Et, fait inquitant, un grand nombre d’organisations qui avaient corrig le bogue l’ont depuis rintroduit dans leurs systmes en installant des logiciels vulnrables, dclare Bernard Montel, directeur technique et stratge en scurit chez Tenable.
Le 9 dcembre 2021, une vulnrabilit a t dcouverte dans la bibliothque de journalisation Apache log4j. Cette bibliothque est trs souvent utilise dans les projets de dveloppement d’application Java/J2EE ainsi que par les diteurs de solutions logicielles sur tagre bases sur Java/J2EE. La vulnrabilit dans Log4J permet un cybercriminel de provoquer une excution de code arbitraire distance s’il a la capacit de soumettre une donne une application qui utilise la bibliothque log4j pour journaliser l’vnement. Cette attaque peut tre ralise sans tre authentifi, par exemple en tirant parti d’une page d’authentification qui journalise les erreurs d’authentification.
Comme dit prcedement, Log4Shell est une vulnrabilit logicielle dans Apache Log4j 2, une bibliothque Java populaire permettant de consigner les messages d’erreur dans les applications. La vulnrabilit, publie sous le nom de CVE-2021-44228, permet un attaquant distant de prendre le contrle d’un appareil sur Internet si l’appareil excute certaines versions de Log4j 2.
Apache a publi un correctif pour CVE-2021-44228, version 2.15, le 6 dcembre 2021. Cependant, ce correctif laissait une partie de la vulnrabilit non corrige, ce qui a donn lieu CVE-2021-45046 et un deuxime correctif, version 2.16, publi le 13 dcembre. Apache a publi un troisime correctif, la version 2.17, le 17 dcembre pour corriger une autre vulnrabilit connexe, CVE-2021-45105. Un quatrime correctif, 2.17.1, a t publi le 28 dcembre pour corriger une autre vulnrabilit, CVE-2021-44832.
Les attaquants peuvent exploiter cette vulnrabilit en utilisant des messages texte pour contrler un ordinateur distance. L’Apache Software Foundation, qui publie la bibliothque Log4j 2, a attribu la vulnrabilit 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’attnuation voluent et que les dgts se dploient, les principes fondamentaux de la vulnrabilit Log4j ne changeront pas.
Le chercheur en scurit Chen Zhaojun d’Alibaba, la plus grande socit de commerce lectronique de Chine, a signal pour la premire fois la vulnrabilit la Fondation Apache (un projet open-source) le 24 novembre. Ils ont dcouvert l’attaque le 9 dcembre sur des serveurs qui hbergent le jeu Minecraft. Aprs une analyse forensique plus pousse, ils ont ralis que les cybercriminels avaient dcouvert la faille plus tt, et l’exploitaient depuis au moins le 1er dcembre 2021.
L’quipe open source de Google a dclar avoir analys Maven Central, le plus grand rfrentiel de packages Java, et a dcouvert que 35 863 packages Java utilisent des versions vulnrables de la bibliothque Apache Log4j. Cela inclut les packages Java qui utilisent des versions Log4j vulnrables l’exploit Log4Shell d’origine (CVE-2021-44228) et un deuxime bogue d’excution de code distance dcouvert dans le correctif Log4Shell (CVE-2021-45046).
Lorsqu’ils ont mis en place un plan pour le rparer 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 dplace.
Tenable estime que la proportion de machines vulnrables l’exploit est passe d’une sur dix en dcembre dernier seulement 2,5 % en octobre dernier. Mais jusqu’ un tiers de ces machines avaient dj t entirement corriges et ont depuis t rinfectes par Log4Shell. Selon Montel, une partie du problme rside dans le fait que Log4j est profondment enfoui dans un grand nombre de bibliothques logicielles courantes.
Il n’est souvent pas vident de savoir si l’utilitaire est inclus dans un outil particulier, et mme lorsqu’il l’est, la plupart des dveloppeurs ne sont pas suffisamment sensibiliss la scurit pour vrifier s’il s’agit de la version la plus rcente, compte tenu notamment de la pression qu’ils subissent pour produire du code rapidement, ajoute-t-il. Des recherches menes par la socit de scurit Sonatype il y a un an ont rvl que 65 % des tlchargements de Log4j concernaient des versions vulnrables de l’outil.
Au niveau organisationnel, Montel pense galement qu’aprs l’norme pression exerce pour traiter la vulnrabilit au cours des premiers mois, il tait presque invitable que les gens se dconcentrent une fois qu’ils avaient l’impression d’avoir remdi au problme. Il pense qu’il existe des analogies videntes avec la pandmie de Covid-19, au cours de laquelle des mesures rigoureuses telles que les fermetures ont rapidement permis de matriser le virus, avant qu’il ne rapparaisse lorsque les choses se sont nouveau dtendues. 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 ministre de la Scurit intrieure indique que le bug tait devenu endmique et qu’il tait susceptible de rester un problme pendant des annes, voire des dcennies. Et les donnes recueillies par la socit de scurit Imperva ont montr que si les attaques exploitant le bug ont considrablement diminu depuis les deux premiers mois de 2022, on observe une augmentation constante depuis novembre, le 3 dcembre de cette anne ayant vu les attaques quotidiennes les plus leves depuis la dcouverte de la vulnrabilit.
Imperva estime qu’environ 7 % de ces attaques sont couronnes de succs. Mais bien qu’il y ait eu quelques piratages trs mdiatiss – dont ceux mens par des pirates chinois parrains par l’tat en mars et une attaque iranienne contre une agence fdrale amricaine en novembre – jusqu’ prsent, le bug n’a pas t la hauteur des prdictions terribles faites l’anne dernire. Bien que de nombreuses entreprises aient t touches, le nombre d’attaques a t largement infrieur ce qui avait t prvu , explique Gabi Stapel, analyste de la recherche sur les menaces chez Imperva.
Il a cependant mis en lumire la dpendance de nombreuses entreprises l’gard de codes tiers et open source sur lesquels elles n’ont que peu de contrle ou de visibilit. Historiquement, les entreprises se sont concentres sur le risque introduit par leurs fournisseurs immdiats et les logiciels critiques dont elles dpendent , explique Stapel. Les organisations doivent adopter un modle de menace qui inclut toutes les parties de la chane d’approvisionnement.
Le cot et la complexit de la rponse Log4Shell ont certainement incit mettre de plus en plus l’accent sur la scurisation de la chane d’approvisionnement des logiciels et stimuler la transparence, dclare Eric Goldstein, directeur adjoint excutif pour la cyberscurit la Cybersecurity and Infrastructure Security Agency (CISA). Une multitude de nouveaux outils, entreprises et produits ont vu le jour l’anne dernire pour aider mieux comprendre les dpendances logicielles, et Log4j est souvent utilis comme motivation principale pour l’innovation et l’adoption , explique-t-il.
L’un des remdes 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, conu pour permettre aux dveloppeurs de reprer plus facilement toute dpendance l’gard de parties de code potentiellement dangereuses. Le gouvernement amricain a indiqu qu’ils pourraient bientt devenir une exigence pour les logiciels fournis aux agences fdrales.
Pour que cette approche ait rellement un impact, elle doit cependant se dplacer plus en amont, dclare Brian Behlendorf, directeur gnral de l’Open Source Security Foundation (OSSF), afin que mme les paquets ou bibliothques de logiciels libres originaux que les dveloppeurs assemblent pour crer des applications soient accompagns de leurs propres SBOM. Pour y parvenir, il faudra probablement crer de nouveaux outils qui simplifient ce processus et les intgrer aux outils de cration de logiciels existants, explique Behlendorf, car il peut tre difficile d’inciter les dveloppeurs fournir un effort supplmentaire .
L’industrie dans son ensemble doit galement mieux se coordonner et tre plus proactive en matire de scurisation des outils open source sur lesquels elle s’appuie, dit-il. Selon Behlendorf, les projets individuels ne disposent tout simplement pas des ressources financires ou humaines ncessaires pour effectuer des tches telles que la rvision du code. Il y a tout simplement un dcalage entre la valeur que doit recevoir l’cosystme et la capacit rassembler ce type de ressources , dit-il. Ce dont nous avons besoin, c’est d’institutions capables d’agrger la demande d’un meilleur examen de ces choses et de canaliser les ressources vers des objectifs cibls et faciles atteindre.
Source : IEEE
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi :