AccueilActualités informatiqueFaille de sécurité Log4Shell : Internet en feu

Faille de sécurité Log4Shell : Internet en feu

On ne peut pas surestimer son caractère explosif, les comparaisons avec Hafnium, Heartbleed et ShellShock sont tout à fait justifiées : la faille de sécurité Log4Shell, révélée le 10 décembre, compte parmi les plus graves et les plus étendues de ces dix dernières années, dont la portée concrète ne peut toujours pas être évaluée, même plusieurs jours ou semaines plus tard.

La faille existe depuis septembre 2013 et elle sommeille dans d’innombrables applications Java sur des serveurs du monde entier. Mais les serveurs ne sont pas les seuls concernés, des versions vulnérables de Log4j ont également été découvertes dans certains clients ainsi que dans des équipements réseau tels que des routeurs et des réseaux sans fil. Et comme la faille existe depuis si longtemps, de nombreux systèmes embarqués et IoT, notamment dans le domaine de la maison intelligente, devraient également être concernés.

Le caractère explosif de Log4Shell vient surtout du fait qu’il est extrêmement facile de l’exploiter. Il suffit généralement qu’un service serveur soit accessible depuis Internet pour obtenir un accès avec des droits d’administrateur et pouvoir exécuter du code arbitraire. Lorsque le BSI (Bundesamt für Sicherheit in der Informationstechnik) a découvert le 11 décembre que du code malveillant pouvait même être inséré directement dans la première requête, il a classé la faille au niveau d’alerte rouge et a déclenché une alerte générale.

C’est un cauchemar pour tout administrateur, car ce ne sont plus seulement les systèmes qui ont un accès direct à Internet qui sont considérés comme vulnérables – le code malveillant peut également atteindre les serveurs de base de données en backend qui, pour des raisons de sécurité, sont enfermés derrière des pare-feu et ne peuvent pas se connecter à Internet.

Sommaire

Une petite faille, mais lourde de conséquences, dans la bibliothèque Log4j est à l’origine de toute cette agitation. Log4j est le couteau suisse pour toutes les tâches de logging en Java, à peu près comparable à stderr en C ou logging en Python. En circulation depuis plus de dix ans, il a été testé et éprouvé des millions de fois et convient à tous les cas d’application, de la dizaine de lignes à l’application d’entreprise critique. Et c’est justement là que le bât blesse : alors que la version 2.0 de Log4j était presque entièrement redéveloppée en 2012 et 2013, un gestionnaire JNDI (Java Naming and Directory Interface) a été mis à jour en juillet 2013 suite à la Feature Request LOG4J2-313. Ainsi, Log4j ne pouvait plus être configuré uniquement via les paramètres système ou l’environnement, mais également via un fichier XML local. C’est précisément ce mode de fonctionnement que vérifie le test JNDI automatisé, qui a été ajouté à la version 2.0-beta9 de Log4j dans le cadre du correctif pour le gestionnaire JNDI.

Ce que les développeurs de Log4j ont apparemment négligé à l’époque, et ce que tout le monde a négligé pendant encore huit ans : JNDI est un couteau suisse encore plus grand que Log4j. Utiliser JNDI uniquement pour recharger des fichiers de configuration XML locaux, c’est un peu comme utiliser le légendaire Wenger Giant avec ses 87 outils uniquement comme lime à ongles – cela fonctionne, mais ce n’est qu’une des 141 fonctions. En effet, JNDI ne peut pas seulement accéder aux ressources locales, mais maîtrise également de nombreux protocoles réseau, afin de pouvoir, dans le cas de Log4j, obtenir des fichiers via LDAP à partir de serveurs de configuration centraux dans un centre de calcul – ou à partir d’Internet, si l’URL indiquée y renvoie.

Dans Log4j, le gestionnaire JNDI traitait toutes les données de log et les examinait pour trouver des instructions de rechargement de fichiers. Ces instructions sont par exemple de la forme ${jndi:ldap://127.0.0.1:1389/a} – où JNDI résoudrait également les noms d’hôtes via DNS et rechargerait alors les données d’un serveur externe. Ainsi, chaque fois qu’une telle chaîne de caractères devait être consignée, Log4j rechargeait un fichier externe via JNDI et exécutait son code.

Dans le cas d’iCloud d’Apple par exemple, le nom de l’appareil servait de porte d’entrée : si l’on insérait la « chaîne de caractères magique » dans le nom de l’appareil, les serveurs d’Apple téléchargeaient du code depuis l’URL indiquée. Pour de nombreux autres services, il suffisait d’insérer l’instruction JNDI dans l’en-tête HTTP ou de modifier l’agent utilisateur du navigateur en conséquence.

Les serveurs du jeu Minecraft ont été parmi les premiers à être victimes de la faille JNDI de Log4j. Il suffisait même d’envoyer la « chaîne de caractères magique » à un autre joueur sous forme de simple message de chat pour prendre le contrôle des serveurs Minecraft. Mais les serveurs n’étaient pas les seuls à être gravement menacés, les clients Java de Minecraft contenaient également la faille Log4Shell. Pour la première fois, il a été officiellement confirmé que Log4Shell ne concernait pas uniquement les serveurs, mais aussi les utilisateurs privés.

Pour les attaquants, la seule difficulté consistait à trouver un moyen d’être immortalisé dans un journal quelconque, de lancer un Bash ou un PowerShell et de prendre ensuite le contrôle de l’ordinateur – d’où le nom Log4Shell. Les serveurs de pratiquement toutes les entreprises de renom ont été touchés, d’Amazon à VMware – tout l’Internet s’est soudain embrasé.

« Internet vient de s’enflammer ».
Adam Meyers, vice-président senior du renseignement, Crowdstrike

Les administrateurs du monde entier se sont livrés à une course contre la montre avec des attaquants criminels, mais aussi gouvernementaux, pour combler la faille Log4j avant que des portes dérobées et des têtes de pont ne puissent être installées, par exemple pour de futures extorsions par ransomware. Il n’était pas du tout trivial pour les administrateurs de trouver tous les services vulnérables, et encore moins de combler la faille jusqu’à ce que les mises à jour soient disponibles et testées. En effet, il y a longtemps que les applications n’utilisent plus uniquement les bibliothèques mises à disposition par le serveur concerné pour l’ensemble du système. Il ne suffit donc pas de rechercher les anciennes versions de la bibliothèque log4j-core via le gestionnaire de paquets.

Aujourd’hui, les applications fonctionnent souvent sous forme de conteneurs Docker ou d’autres formes de virtualisation, où elles apportent leur propre jeu de bibliothèques. Afin de pouvoir détecter les versions vulnérables de Log4j dans les conteneurs, le projet Docker a livré le 11 décembre une mise à jour du plug-in « docker-scan-plugin ». Toutefois, docker scan ne détecte les installations vulnérables de Log4j que si elles ne se trouvent pas dans une archive Java (JAR) ou même si elles sont cachées en tant que JAR dans un JAR. Les flatpaks, snaps et appimages apportent également des tas de bibliothèques propres dont l’état de version est régulièrement inconnu. Si une seule version vulnérable de Log4j s’y trouve, l’ordinateur entier est vulnérable.

Certains composants réseau sont également concernés par Log4Shell. Cisco a réagi rapidement et a déjà identifié plusieurs produits vulnérables, mais certaines mises à jour ne devraient être disponibles que dans le courant de l’année. Ubiquiti a également confirmé très tôt la faille Log4Shell dans son application réseau UniFi et l’a corrigée dès le 11 décembre. Le programme est notamment responsable de l’authentification des invités WLAN et est donc également vulnérable via le WLAN sur place. On trouve des points d’accès UniFi dans d’innombrables hôtels, cabinets médicaux, agences bancaires, entreprises, coiffeurs et également chez de nombreux utilisateurs privés.

Le nombre de systèmes embarqués et IoT dans lesquels se cache Log4Shell n’a guère été étudié jusqu’à présent. Java est extrêmement répandu dans ce domaine, par exemple dans les maisons intelligentes, mais aussi dans les systèmes de fermeture électronique. Le problème principal est que la faille de Log4j remonte à huit ans – des systèmes plus anciens, vendus il y a des années et pour lesquels il n’existe plus de mises à jour depuis longtemps, pourraient donc être concernés. Il n’y a pas de code source à consulter, pas plus que de possibilité de se connecter aux systèmes et de vérifier les versions des bibliothèques.

On pourrait penser qu’il suffit d’envoyer une demande de navigateur à l’appareil concerné avec la « chaîne de caractères magique » dans l’agent utilisateur pour savoir s’il est concerné par Log4Shell. Mais cela ne permet pas de savoir ce qui est concrètement consigné et si du code a été rechargé. C’est pourquoi on utilise ce que l’on appelle des canaris.

Sur canarytokens.org par exemple, vous pouvez générer gratuitement des appels JNDI inoffensifs pour la faille Log4j et recevoir un e-mail si un système vulnérable tente de recharger du code (mais aussi si un aperçu de lien d’un navigateur ou d’un messager tente de résoudre le nom d’hôte). Mais cette méthode est insuffisante, car l’agent utilisateur n’apparaît pas toujours dans le journal, parfois même pas l’établissement de la connexion, mais seulement une tentative de connexion réussie. Il se peut donc que l’on ne puisse pas exploiter Log4Shell via l’agent utilisateur, mais uniquement via le nom d’utilisateur lors d’une connexion ou le nom d’hôte du système de test défini dans le résolveur DNS. Il n’existe pas de tests génériques permettant de détecter de l’extérieur toutes les bibliothèques Log4j vulnérables.

Log4Shell est sans aucun doute l’une des failles de sécurité les plus étendues et les plus graves de ces dix dernières années. Actuellement, les administrateurs travaillent d’arrache-pied pour corriger les serveurs vulnérables et remettre à la porte les attaquants qui ont réussi. La faille occupera encore les administrateurs et les développeurs pendant des mois et entraînera des milliers de mises à jour. Les utilisateurs privés doivent également rester vigilants et appliquer rapidement les mises à jour prévues pour les routeurs, les réseaux sans fil, les NAS et les maisons intelligentes.

Ce n’est que la partie émergée de l’iceberg : les pirates étatiques et criminels ont principalement utilisé Log4Shell pour installer des portes dérobées et des têtes de pont dans des domaines jusqu’ici hautement sécurisés, le plus silencieusement possible et sans être détectés. Les véritables attaques contre l’infrastructure informatique par le vol de données ou les chevaux de Troie de cryptage et le chantage qui s’ensuit sont encore à venir. Typiquement, les attaquants explorent longuement leur victime avant de passer à l’action – notamment parce que tous les administrateurs sont actuellement alertés et attentifs aux moindres signes. Au printemps, lorsque la vie quotidienne sera revenue et que Log4Shell aura pris de l’ampleur, la phase la plus difficile devrait commencer.

c’t édition 2/2022

Dans c’t 2/2022, nous avons composé pour vous le Windows d’urgence c’t 2022. Avec le kit pour le système fonctionnant à partir d’une clé USB, vous trouverez des virus, sauverez des données ou réinitialiserez des mots de passe. Nous mettons en lumière la manière dont l’UE veut utiliser les failles du RGPD pour les scanners de contenu, nous avons testé des smartphones haut de gamme, des moniteurs mobiles USB-C et des logiciels serveur pour la collection de médias privée. Vous trouverez le numéro 2/2022 à partir du 31 décembre dans la boutique et dans les kiosques à journaux bien achalandés.

Plus d'articles