Une vulnérabilité découverte dans Log4j - qui est un code source ouvert largement utilisé - a affecté des millions d'ordinateurs dans le monde, y compris des infrastructures critiques et des systèmes fédéraux. Cela a conduit les plus grands experts en cybersécurité à parler de l'une des vulnérabilités les plus graves et les plus répandues jamais vues en matière de cybersécurité.
Le 9 décembre, 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.
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).
James Wetter et Nicky Ringland, membres de l'équipe Google Open Source Insights, ont déclaré dans un rapport que, bien souvent, lorsqu'une faille de sécurité Java majeure est détectée, elle n'affecte généralement que 2% de l'index Maven Central. Cependant, les 35 000 packages Java vulnérables à Log4Shell représentent environ 8 % du total de Maven Central d'environ 440 000, un pourcentage que les deux ont décrit en utilisant un seul mot : « énorme ».
Log4j inclut un mécanisme de recherche qui pourrait être utilisé pour effectuer des requêtes via une syntaxe spéciale dans une chaîne de format. Par exemple, il peut être utilisé pour demander divers paramètres comme la version de l'environnement Java via ${java:version}, etc. Ensuite, en spécifiant la clé jndi dans la chaîne, le mécanisme de recherche utilise l'API JNDI. Par défaut, toutes les requêtes sont effectuées en utilisant le préfixe java:comp/env/*; cependant, les auteurs ont implémenté l'option d'utiliser un préfixe personnalisé au moyen d'un symbole deux-points dans la clé. C'est là que réside la vulnérabilité : si jndi:ldap:// est utilisé comme clé, la requête va au serveur LDAP spécifié. D'autres protocoles de communication, tels que LDAPS, DNS et RMI, peuvent également être utilisés.
Ainsi, un serveur distant contrôlé par un attaquant pourrait renvoyer un objet à un serveur vulnérable, entraînant potentiellement l'exécution de code arbitraire dans le système ou la fuite de données confidentielles. Tout ce qu'un attaquant doit faire est d'envoyer une chaîne spéciale via le mécanisme qui écrit cette chaîne dans un fichier journal et est donc gérée par la bibliothèque Log4j. Cela peut être fait avec de simples requêtes HTTP, par exemple, celles envoyées via des formulaires Web, des champs de données, etc., ou avec tout autre type d'interactions utilisant la journalisation côté serveur.
La vulnérabilité a été caractérisé par Tenable comme « la vulnérabilité la plus importante et la plus critique de la dernière décennie ».
Des preuves de concept ont déjà été publiées. Cette vulnérabilité fait désormais l'objet d'une exploitation active.
La sévérité de la brèche est maximale 10 sur l’échelle CVSS.
Voici, ci-dessous, la liste des systèmes affectés :
- Apache Log4j versions 2.0 à 2.14.1 ;
- Apache Log4j versions 1.x (versions obsolètes) sous réserve d'une configuration particulière ;
- Les produits utilisant une version vulnérable de Apache Log4j : les CERT nationaux européens tiennent à jour une liste complète des produits et de leur statut vis-à-vis de la vulnérabilité.
« Les logiciels libres constituent le socle du monde numérique et la vulnérabilité de Log4j a démontré à quel point nous en dépendons. Cet incident a présenté une menace sérieuse pour les systèmes fédéraux et les entreprises d'infrastructures critiques - notamment les banques, les hôpitaux et les services publics - sur lesquels les Américains comptent chaque jour pour obtenir des services essentiels », a déclaré le sénateur Peters. « Cette législation de bon sens et bipartisane contribuera à sécuriser les logiciels libres et à renforcer davantage nos défenses de cybersécurité contre les cybercriminels et les adversaires étrangers qui lancent des attaques incessantes sur les réseaux à travers la nation. »
« Comme nous l'avons vu avec la vulnérabilité de log4shell, les ordinateurs, les téléphones et les sites Web que nous utilisons tous chaque jour contiennent des logiciels libres qui sont vulnérables aux cyberattaques », a déclaré le sénateur Portman. « La loi bipartisane Securing Open Source Software Act garantira que le gouvernement américain anticipe et atténue les vulnérabilités de sécurité dans les logiciels open source afin de protéger les données les plus sensibles des Américains. »
« Cette importante législation codifiera, pour la toute première fois, les logiciels libres en tant qu'infrastructure publique », a déclaré Trey Herr, directeur de l'initiative Cyber Statecraft, Centre Scowcroft pour la stratégie et la sécurité, Conseil atlantique. « Si cette loi est signée, elle constituera une étape historique pour un soutien fédéral plus large à la santé et à la sécurité des logiciels libres. Je suis encouragé par le leadership des sénateurs Peters et Portman sur cette question. »
L'écrasante majorité des ordinateurs dans le monde s'appuie sur le code source ouvert - un code librement disponible que chacun peut contribuer, développer et utiliser pour créer des sites web, des applications et bien plus encore. Il est maintenu par une communauté de personnes et d'organisations. Le gouvernement fédéral, qui est l'un des plus grands utilisateurs de logiciels libres au monde, doit être en mesure de gérer ses propres risques et de contribuer à la sécurité des logiciels libres dans le secteur privé et le reste du secteur public.
En début d’année, Daniel Stenberg, le créateur de cURL, a reçu un courriel en provenance d'une entreprise appartenant au Fortune 500, le classement des 500 premières entreprises américaines classées selon l'importance de leur chiffre d'affaires. Ladite entreprise (ou ses clients) utilisait probablement cURL et, dans le contexte de la vulnérabilité dans la bibliothèque de journalisation Apache log4j, lui a posé une série de questions pour savoir entre autres si cURL s'appuyait sur log4j. « Si vous êtes une entreprise de plusieurs milliards de dollars et que vous êtes préoccupé par log4j, pourquoi ne pas simplement envoyer un e-mail aux auteurs OSS à qui vous n'avez jamais rien payé et exiger une réponse gratuite dans les 24 heures avec beaucoup d'informations ? » a-t-il demandé en présentant le courriel qu'il a reçu.
cURL (abréviation de client URL request library : « bibliothèque de requêtes aux URL pour les clients » ou see URL : littéralement « voir URL ») est une interface en ligne de commande, destinée à récupérer le contenu d'une ressource accessible par un réseau informatique. La ressource est désignée à l'aide d'une URL et doit être d'un type supporté par le logiciel. Le logiciel permet de créer ou modifier une ressource (contrairement à wget), il peut ainsi être utilisé en tant que client REST.
Le programme cURL implémente l'interface utilisateur et repose sur la bibliothèque logicielle libcurl, développée en langage C. Celle-ci est ainsi accessible aux développeurs qui veulent disposer des fonctionnalités d'accès au réseau dans leurs programmes. Des interfaces ont été créées dans de nombreux langages (C++, Java, .NET, Perl, PHP, Ruby...).
La loi sur la sécurisation des logiciels libres demanderait à la CISA de développer un cadre de risque pour évaluer la manière dont le code source ouvert est utilisé par le gouvernement fédéral. La CISA évaluera également comment ce même cadre pourrait être utilisé volontairement par les propriétaires et les exploitants d'infrastructures critiques. Cela permettra d'identifier les moyens d'atténuer les risques dans les systèmes qui utilisent des logiciels open source. La législation exige également que la CISA engage des professionnels ayant de l'expérience dans le développement de logiciels open source afin de s'assurer que le gouvernement et la communauté travaillent main dans la main et soient préparés à faire face à des incidents tels que la vulnérabilité de Log4j.
En outre, la législation exige que l'Office of Management and Budget (OMB) émette des directives à l'intention des agences fédérales sur l'utilisation sécurisée des logiciels libres et crée un sous-comité de sécurité logicielle au sein du comité consultatif sur la cybersécurité de la CISA.
Peters et Portman ont mené plusieurs efforts pour renforcer la cybersécurité de notre nation. Leur disposition historique et bipartisane visant à obliger les propriétaires et les exploitants d'infrastructures critiques à faire rapport à la CISA s'ils subissent une cyberattaque importante ou s'ils effectuent un paiement par ransomware a été promulguée. La législation des sénateurs visant à renforcer la cybersécurité des gouvernements des États et des collectivités locales a également été promulguée. Les projets de loi de Peters et Portman visant à protéger les réseaux fédéraux et à garantir que le gouvernement puisse adopter en toute sécurité la technologie du cloud ont également été adoptés à l'unanimité par le Sénat.
Source : Homeland Security & Governmental Affairs
Et vous ?
Que pensez-vous de la démarche des sénateurs ?
Pensez-vous que la sécurité des logiciels libres nécessitent plus de renforcement que les logiciels propriétaires ?
Voir aussi :
GitHub restaure le compte du dev qui a intentionnellement corrompu ses bibliothèques, certains développeurs estiment que la suspension était déraisonnable puisqu'il s'agissait de son propre code
Log4j : la directrice du CISA s'attend à des retombées de la faille qui vont s'étendre sur des années et servir à des intrusions futures dans les systèmes des entreprises
Des cybercriminels exploitent activement la faille critique dans Log4J : plus de 840 000 attaques ont été détectées. Le spectre d'un scénario rappelant Heartbleed fait surface