Attention danger : démonstration en direct du fonctionnement d’un exploit Log4Shell

La vulnérabilité Log4Shell a pris la communauté Java par surprise fin 2021, et de nombreuses organisations s’efforcent encore d’en atténuer les effets. Pour aider les équipes de développement à rester informées de l’évolution de la situation, Snyk a créé et continue de mettre à jour son centre de ressources sur la vulnérabilité Log4j.

Lors d’une récente démonstration en direct de Stranger Danger, Simon Maple, Field CTO chez Snyk, Eric Smalling, Senior Developer Advocate chez Snyk, et Micah Silverman, directeur de l’accélération DevSecOps, ont présenté la vulnérabilité Log4Shell et montré comment un exploit pouvait fonctionner.

Log4Shell en bref

Log4Shell est une vulnérabilité très répandue, critique et facile à exploiter dans le framework de journalisation Java Log4j2. Elle a touché un grand nombre d’applications Java, car Log4j2 est très souvent utilisé par de nombreuses bibliothèques open source.

« Comme le montre le fait que cette vulnérabilité soit restée latente depuis 2013, des effets secondaires inattendus peuvent parfois se produire », a déclaré Micah. « C’est un peu dans la nature des projets open source. »

Pour corriger cette vulnérabilité, les développeurs doivent identifier les endroits où leurs applications utilisent la bibliothèque Log4j2, en tant que dépendance directe ou indirecte, puis effectuer une mise à niveau vers la version 2.17.1. Cette opération permet non seulement d’atténuer la vulnérabilité Log4Shell, mais aussi de corriger une autre vulnérabilité de déni de service divulguée peu après.

Vous souhaitez en savoir plus ? Nous avons préparé un guide complet pour corriger Log4Shell.

Anatomie de Log4Shell

En 2013, la bibliothèque Log4j a été modifiée pour permettre l’utilisation de références Java Naming and Directory Interface (JNDI) dans des chaînes interpolées au sein des messages de journal. Ces chaînes interpolées peuvent contenir des variables, des appels de fonction ou d’autres expressions résolubles. Le problème, c’est que JNDI peut rechercher des URL dans ces chaînes et déclencher un appel réseau vers un point de terminaison malveillant.

De plus, un serveur LDAP non autorisé peut répondre à la requête JNDI en envoyant une référence malveillante à une classe Java distante ou à un autre code indésirable. Cette classe peut alors être désérialisée, même si elle ne figure pas dans le chemin de classes de l’application, ce qui entraîne une attaque par exécution de code à distance (RCE).

Démonstration d’un exploit Log4Shell

Pour notre démonstration de piratage en direct, nous allons utiliser un exemple d’exploit Log4Shell (disponible sur GitHub) que nous avons développé en Java et que nous exécuterons sur un serveur Tomcat. Lorsque nous saisissons un mot de passe incorrect sur la page de connexion, l’application nous indique que nos informations seront consignées dans les journaux.

« Il est courant de journaliser les événements dans les frameworks Java et dans votre application lorsque des erreurs ou des exceptions surviennent, et parfois même lors d’une transaction ordinaire », explique Simon. « Cela vous aide à comprendre les différents flux et la manière dont les utilisateurs se servent de votre site. »

En examinant le code de notre application, nous constatons que lorsque le nom d’utilisateur est incorrect, Log4j journalise ce nom. Les situations où les utilisateurs peuvent saisir des données qui sont ensuite consignées dans les journaux constituent le moyen le plus courant d’exploiter la vulnérabilité Log4Shell.

Par exemple, nous pouvons utiliser le champ de connexion pour injecter une chaîne malveillante qui nous permettra de lancer une attaque RCE. Mais commençons par examiner notre script d’exploit Python. Le point essentiel à comprendre est que ce script génère une classe Java qui crée une nouvelle socket à son initialisation, puis se connecte à notre propre serveur.

« Cette classe fera essentiellement partie d’un proxy distant que nous allons mettre en place », explique Simon. « Elle s’exécutera en boucle, recevra des commandes, les exécutera et les renverra à notre service connecté. »

Nous allons créer et compiler le fichier Java sur notre serveur malveillant, puis le rendre accessible via un service HTTP. Nous allons ensuite créer notre serveur LDAP, qui renverra une chaîne indiquant au JNDI de l’application cible où trouver notre classe Java malveillante.

Une fois les serveurs LDAP et HTTP opérationnels, nous sommes presque prêts à lancer l’exploit. Pour exécuter la partie « shell » de Log4Shell, nous allons également configurer un serveur proxy inversé à l’aide de netcat, un utilitaire réseau. Ce proxy inversé nous permettra d’exécuter des commandes à distance sur le serveur Tomcat, exposant ainsi l’application et le serveur à d’autres attaques.

Nous lançons l’exploit en saisissant notre chaîne malveillante dans le champ de connexion de la page de l’application cible. Une fois cette chaîne consignée par Log4j, la bibliothèque tente également de la résoudre. L’application utilise alors le service JNDI pour contacter le serveur LDAP, récupérer la référence à notre classe Java malveillante sur le serveur HTTP et l’exécuter localement. Cette classe Java se connecte ensuite à netcat, créant ainsi notre proxy inversé.

Atténuer Log4Shell avec Snyk

Comme nous l’avons déjà indiqué, la meilleure façon d’atténuer Log4Shell consiste à identifier et à mettre à niveau toutes les instances de Log4j présentes dans vos dépendances directes et indirectes. Snyk Open Source peut analyser automatiquement vos dépendances afin de détecter les packages contenant des vulnérabilités telles que Log4Shell.

La plateforme Snyk commence par identifier et classer tous les artefacts de votre projet afin de déterminer comment les analyser. Par exemple, Snyk effectue des analyses de composition logicielle (SCA) sur les fichiers pom.xml et des tests statiques de sécurité des applications (SAST) sur les fichiers Java. Snyk peut également analyser les configurations d’infrastructure en tant que code (IaC) et les fichiers Docker des applications conteneurisées.

Après avoir analysé l’application vulnérable ci-dessus, nous pouvons ouvrir les résultats de l’analyse de notre fichier pom.xml, le fichier de configuration Maven qui contient nos dépendances. L’interface Snyk affiche également notre arbre de dépendances et montre que notre application utilise Log4j comme dépendance directe et indirecte. En cliquant sur l’option Corriger cette vulnérabilité, Snyk peut automatiquement ouvrir une pull request (PR) pour mettre à niveau toutes les instances de Log4j vers la version 2.17.1. Si nous relançons l’exploit précédent, nous constatons qu’il ne fonctionne plus.

De même, les développeurs peuvent utiliser le plugin Snyk pour IntelliJ (ou un autre IDE) ou l’interface de ligne de commande Snyk pour détecter les problèmes de sécurité et les corriger directement pendant le développement. Snyk s’intègre à toutes les étapes du processus de développement afin de simplifier la gestion des vulnérabilités des applications.

Dans certains cas, les organisations ne pourront pas mettre immédiatement à niveau les packages vulnérables et devront donc envisager d’autres solutions pour atténuer les risques liés à Log4Shell. Les développeurs peuvent supprimer la classe de recherche JNDI ou appliquer d’autres correctifs rapides, mais ces solutions sont moins efficaces que le correctif officiel disponible dans les versions plus récentes de la bibliothèque.

Quelle que soit la méthode choisie par les développeurs pour atténuer la vulnérabilité Log4Shell, Snyk peut aider à identifier les instances de Log4j et des milliers d’autres vulnérabilités potentielles en analysant les dépendances open source ou les conteneurs d’un projet. Les organisations disposent ainsi de la visibilité nécessaire pour comprendre le profil de risque de leurs applications.